I'm the maintainer of Babel, ask me anything!

twitter.com/left_pad/status/859789...

I think when you are learning new things, you discover how much you don't know and it may give the feeling of "imposter syndrome". I remember reading a post about it (maybe someone remembers) that a lot of us don't actually have imposter syndrome but it's something else.

There are different levels of progression: maybe it's first issue/comment, first PR, first publish, first repo, etc and the next thing always seems so overwhelming. It's helpful to remember that it just means you are learning more. I think I just have a confidence issue, starting from knowing nothing doesn't mean you are unqualified, if you are there than someone wanted you to be. Like feeling nervous about giving a talk or even attending TC39. Everyone has different things to bring to the table, we shouldn't have to live up to the stereotype of what we think a developer or whatever is, it's just an average/typical thing that doesn't describe the diversity of people and their journey to where they are today.

I try to put my efforts into getting others involved in the project: it's the part of open source I appreciate the most (the people part), it is in my interest to make sure I don't become the only person involved and to make make all of our efforts as a team better, and it brings in different ways of thinking. We've tried many kinds of efforts like participating in Rails Girls Summer of Code and Google Summer of Code, talking with various companies, joining meetups, etc. Of course I'd like to be able to spend full time doing these efforts because none of this community effort is usually what you would be paid to do at a company given it isn't as direct a benefit

Have you ever had someone explain how babel really works and what it's for before discovering who you are?

Yeah that happens haha. It's kind of like how people are mean to your online (twitter/github) because they don't understand it's a person behind the username/project. Once they know you everything changes. I think it's like how open source can be a victim of it's own success: being a popular project doesn't do anything to help the sustainability of the project and only increases the burden. The same small amount of people are helping improve it while more and more people are using/consuming it, and it creates this cycle of burnout in maintainers. People think that Babel is a company, that I work at Facebook or Google, or various other things because of their assumptions.

Great question!

Hey Haroen, good question!

It's not something that projects do a good job at in general. Making beginner-friendly (good first issue) issues is hard, takes lots of time, and scales inefficiently. And I've made a lot of those: github.com/babel/babel/labels/good first issue.

It is hard because it seems overwhelming. I was intending to make a better guide with real issue/PR examples but haven't one it yet.

It's ironic because on my side I think it's not even close to being "complete" as a project but I need to figure out how to express that in the right way 🙂. That should probably be my priority instead of trying to fix all these specific bugs/issues myself.

This is a really good question Ben! The "were ready" part of the question is funny because I don't think I ever felt I was ready? I (and everyone else on the project, and probably a lot of other open source projects) didn't really have previous knowledge about compilers or ES6. It was mostly an interest in the project and it's vision that got me involved and staying involved. I don't think there are any hard qualifications to do it.. after Sebastian got burned out he gave me and some others access to the repo/publish rights and I was like woah I guess we have to just figure it out? I had never published my own npm package before or explored much of the codebase, but slowly (sometimes really slowly) you get used to it. Sometimes you have to kind of ignore the fact everyone is using it and complaining and all that, else yeah you might get depressed on the burden that's involved. I could probably write a lot for this question 😂 since I feel like I'm just rambling now.

I speak a bit on this in one of the talks I did: maybe

I basically thought that I realized I became a maintainer like maybe a year after I was already doing the role and all that? I remember Kent saying that if you want to be a maintainer of a project, just act and do the things that maintainers do. Of course that is a difficult thing to know, but you learn as you go. There aren't really a list of things to do (I wish someone would just tell me), but you just have to find out the things a project needs and what you are willing/wanting to commit to.

Dan had a good answer on this twitter.com/dan_abramov/status/787...

Hey Jess!

Yeah it's certainly not as easy as that sentence sounds but we try to make it work. I work with my boss to determine the kinds of issues I work on in my sprint just like with other work. Sometimes it's difficult in the day to day to split time, so it's not easy to literally do 50% on both every day, but maybe it's every other day or every other week depending on what we need. In the end it averages out to 50% though. Of course personally, I do admit I have a burden that I want to work on it full time despite having this opportunity but that's something I have to deal with, whether it's trying to push for that across the team/company or something else.

We try to have an attitude across the team that open source (and also things like technical debt, bug fixes, refactoring) should be argued for just the same as features. This means that open source shouldn't be like a "reward" for making a feature or something, but that it's vital to the success of our team/product all the same. This is kind of the attitude that Jon expresses in twitter.com/jkup/status/9098870661..., where open source is a part of the DNA of our team.

We encourage open source contributions: my coworker Kai is a core-team member on ESLint. Erin, Matt, and Yuriy have all contributed a lot to the Vue ecosystem, whether giving talks or writing docs, and coming up with testing strategies and more. Mike was a jQuery team member and recently had many multiple PRs to both npm/webpack to improve everyone's build performance significantly. I think we are willing to contribute back, make patches, and get involved if we have a problem/issue instead of just waiting around or complaining about.

So yes I talk about Babel at work a lot with my colleagues (maybe they might think too much). Not everyone is always as interested in it as me but I think they still like to listen and give feedback 🙂).

I think you mean what it's like for someone new back then vs. now?

I only started around 2 years ago which isn't too long ago. I think there are definetely some differences but not sure on the whole if it's easier/better to contribute now than before. I don't think we really have a grasp/handle on how to make it sustainable to continue to grow new contributors?

There are a lot of new things like the interest in bots like github.com/probot/probot, twitter.com/greenkeeperio to handle some of the tasks and to lessen burden. Github has done a lot like the license changes: github.com/babel/babel/blob/master..., start of a community standard/guidlines, opensource.guide/, talking with maintainers and being more active. There is more of an emphasis on getting more people involved with things like the good first issue label and other things and people caring more about having a good readme/website/etc.

In the end it's just a lot of work to get plugged in and I know that. Not sure the best way to move forward other than better mentorship and then via that better docs/guides via that process which takes a lot of time/mental effort/scheduling. I'd like to do more of that but just not always in the best situation to do so unless it becomes part of your job. And even with that, you might not be able to help more than a handful of people (which is plenty), since even having a single extra maintainer/collaborator is a huge deal.

So the effort to grow new contributors is certainly welcome and we shouldn't stop doing it, but we should be cautious to make sure we don't burn out new contributors since that is happening all the time with old ones (I will admit some level of "burnout" is ok in the sense people should take breaks and are not obligated to do any of the work, and that sense of personal commitment may/may not cause that). Would love if we had a better grasp on how to make it sustainable as a consistent, healthy thing to take part in: not about getting stars, likes, medium posts, downloads, resume building, etc (all can be fine and fun) but doesn't satisfy in the long run. If you are feeling the burden, the overwhelming sense that you have to do it, we should provide help, guidance, etc.

And hope I don't sound like it's all bad at the moment. I started without any guidance and it ended up working out but it took forever to learn a lot of it on my own (and that's ok). Having a friend, class, club, meetup to do it with would probably make it more enjoyable and maybe projects should be doing more (I hesitate to say we should do more 😂) in that direction. And for me a lot of it is providing an environment where people can express better ideas instead of just submitting a PR to someone else's issue or fixing a basic thing. Problem is people have no context, names are hard, it seems like you have to know so much up front to be able to be in a position to contribute ideas? I really don't know where it's supposed to go either and would love if someone else could tell me. Right now it's just trying to find patterns and overall issues are learning (the hard way) of trying prioritize over just answering questions on twitter/slack over and over but actually moving things forward while helping people in the now as well. And all that should be documented too but then I'm just tired 😄. Another thing I want to continue doing (I'm not sure if this even works) is make it more fun like how we have the whole "guy fieri" meme, now the Babel song, etc. Of course that has to come naturally but I think it can bring in a lot of people who otherwise would be turned off by the nature of the project itself.

Hey Tiffany!

Thanks for the question. So to clarify I don't think we have tied Babel to any particular build tool. Technically since Babel is split into various modules, you can create an integration with Babel with babel-core for various tools like testing (mocha, ava, jasmine, jest), or a bundler (webpack, browserify, etc).

It's probably since Webpack is the most popular bundler that we tend to use Babel and Webpack together a lot (and that's totally true). babel-loader is the thing most people are using for front-end development and it's used in a lot of other tools like create-react-app, etc. And yeah it's important for us to figure out how to integrate better, and I talk to Sean a lot about these kinds of things 🙂.

Hello Mac! Sorry this is kind of long 😂

Github is maintaining a nice guide on open source at opensource.guide/ if you haven't checked that out yet! Although maybe most of that is for contributing rather than maintaining.

I guess you are asking for the other side of things? I might of gone over some things in github.com/hzoo/maintainer-heal-th...?

One thing that can be helpful is responding in a positive way. At Behance, we try to start our PR reviews with a "good job" or something instead of just writing comments about what to fix or make better. "Thanks for contributing" can go a long way as my coworker Mike says. And maybe you could just pre-prend all responses automatically but you can go further and actually just say something nice about the issue/PR submitted, it will take some effort to get used to. If I don't I try to just add an emoji or two, and if you really want to go all out add some GIF 🙂.

Be humble and remember where you started from. People of all backgrounds are going to use this OSS, and learning to be nice can be difficult especially when people treat you in the wrong way. It's true that saying something nice is "easier" when there is a reason to, but doing despite of that can bring the conversation around.

We can try all we want to convince/remind people that maintainers are volunteers and deserving of respect (and they are), but people are going to continue to act the way they are. I wish people would think of the people behind the projects they use rather than just a black box or thinking it's an abstract/un-emotional/stoic/robot "project". Although I agree we should try to "detach" ourselves from our work and that it doesn't define you as a person, but sometimes it's just hard. Sometimes if you insult the project and it's only you and a few people, how is it not an insult to the person directly?

But it's difficult to really change others by asking or shouting back (some may say impossible). It takes a lot of work to understand where people are coming from, to meet them where they are at, and to bring them to an understanding of your position via their framework. Sometimes you got to remember that we can just as easily act the same way and be hypocrites. I do have that fear a lot, but I have to remember that there is grace for that as well.

And when all that just feels overwhelming, you just need to take a break. Maybe don't answer that issue when you get the notification in like 1 second and just chill a bit. Maybe wait till you've calmed down when a user posts an issue with no description and demands for help. Sometimes not responding is the best action in the moment, and learning to work on open source when you actually feel good about it is the right way to go.

I'm "trying" to do this now: twitter.com/left_pad/status/938041..., and reflecting on the kinds of things I want to work on and help out with as I try to prioritize health and other things.

I guess this is now more of a side-point about keeping OSS fun for newcomers and yourself, but it depends on the overall state of your project and the kind of culture it fosters. For Babel we are obviously a "serious"/"popular" project that a lot of companies/individuals use but we want to bring a spirit of fun/whimsy/welcoming as well. This is reflected (I hope) in our writing/actions.

Like when Jordan posted his infamous medium article about node_modules and we took it farther by actually opening/merging a PR to add an ASCII guy fieri in the codebase github.com/babel/babel/pull/3641, I documented part of the story in github.com/open-source/stories/hzo....

And it's not something we are intentionally always trying to bring in, but just trying to keep it real but enjoyable. Sometimes having some non-practical, fun activities is what it takes to bring people into a community to show it's not as difficult as it seems (or really that it's difficult in different ways than you initially believe).

This kind of idea was reflected most recently by Angus: twitter.com/angustweets/status/938.... He on his own made an awesome parody song with Babel as the subject and I thought it was pretty funny, so maybe I surprised him and thought we can just make it our "song". I just thought it was an amazing way to contribute to the project: github.com/babel/babel/#is-there-a....

Really good question as well. Most of the relationship is just that they use the project. Not everyone posts at our users page: babeljs.io/users/.

TL;DR is that they consume it but no one is really helping drive it forward. People will step up in certain areas here and there but ultimately the coordination/vision effort is all on us. It's hard to push things when we are the volunteer led effort though, although I have to be ok with that since it's been that way since the beginning, (Babel is 3 years old: babeljs.io/blog/2017/10/05/babel-t...).

And engineers that work at those companies might know who were are on the team and I might have contact with them from conferences/etc. Most people aren't always asking for feature x/y or even in the issues. They might be one-off DM's on twitter/slack but in the day to day we don't have too much contact with that many companies, and it's really mostly a volunteer thing. No one is really pushing for anything on our roadmap so it's mostly just us trying to figure out what exactly we need for the community (it can be a lot 😂, I really don't know either).

So Adobe: I work at Behance so I have somewhat of a relationship there, I think companies still aren't really putting in the resources there because they might not see the benefits given past history etc. When I gave talks earlier I had a lot of employees tell me they didn't know I worked there (and I mentioned in another thread people think Babel is a Facebook project when it's always been a community project, although Sebastian did work on it at Facebook for sure).

Google: talk to them a lot since although they might use it for their own stuff, they'll use it for OSS projects like github.com/GoogleChrome/workbox, and their users will probably be using Babel. I think browser vendors have a good incentive to make sure Babel is well supported because a lot of the code being sent to the browser is going to be compiled with Babel (so things like code output/speed should be important).

Recently github.com/jridgewell on the AMP team joined as a collaborator team and has been contributing a lot of PRs, and they also donated to the project. Justin has recently joined to represent us at TC39 as well. There's an issue with being an "invited guest" if you don't work at a "TC39" member company so that has honestly been an issue for being able to go.

Facebook: they hired Sebastian to work/make Babel 6, both Yuriy and Amjad made/worked on babel-minify (babili before), and the Flow/React teams help with JSX/Flow PRs sometimes. They recently donated $1k a month to the project which is a nice gesture: twitter.com/left_pad/status/923696... but we still don't have enough for 1 person to be full time atm.

Microsoft/LinkedIn: had some help/contact with the Ember team, like twitter.com/rwjblue, twitter.com/nathanhammond who helped with setting up Babel meetings, and a lot more. We recently collaborated with the TypeScript team to at @babel/preset-typescript after making sure they would help with the PRs and helping keep them in sync (we try to do the same with Flow).

There's a lot of other companies like Airbnb, Netflix, etc too.

Point is that I can recall times we might of talked and stuff but don't really have any sort of regular communication with that many folks or do calls/meetings.

So I don't think Babel "won't" be needed soon, and it's not because I happen to work on it 😂.

I think that is a result of thinking it is still "6to5". I'll admit that yes ES6/ES2015 was a huge change that lead to this kind of thinking/tool, but I think maybe we all need to think a bit longer-term?

github.com/babel/babel-preset-env shows the change in thinking that I had. Babel doesn't do a static thing of just turning your ES6 code to ES5, but it actually will move forward as the language progresses and browsers update. As long as we need to support old browers, and the language continues to update with new syntax, AND all of us continue to want to use that new syntax (that's key), then something like Babel seems to be necessary?

If you think ES6 is good enough and you only support evergreen browsers, then yeah Babel isn't necessary and lucky for you! Or if you are in Node and are able to update to the later versions than the same thing there.

2.

This goes well with the points above: Babel isn't just a backwards compatible tool, but actually helps inform the future of the language itself. By using the plugins that are TC39 proposals, you can help give feedback to the committee that makes JavaScript to make it better. Maybe the proposal is unintuitive, slow, etc and they can get that real feedback from developers during the Stage process (0-3) without having to implement and waste time/money in browserland to find that the idea was bad and developers don't want to use it at all.

It's a fine balance though, people don't really understand what Stage 0 means, and that's actually understandable too. There's an education problem there. As much as I try to push for better docs, codemods to remove killed proposals or to upgrade in between proposals (decorators, etc), it's just a lot of work, and a lot to manage for a few people, let alone the whole community.

We need more people/companies involved, and people thinking about these issues that will impact the future of how we write JavaScript and websites in the future - whether it's via JavaScript or interop with another language that compiles to JavaScript (via js libraries).

Definitely want to answer this one! Getting lunch now though 😁