Placeholder Image

字幕表 動画を再生する

  • I have been participating and maintaining in an open source project, Mocha

  • and I'm here to share some of the things I've learned.

  • I think you all roughly know about Mocha

  • To briefly explain about Mocha,

  • Mocha is a Javascript test frame work

  • It's a framework that can be used on both Node.js and web browser.

  • It's been out for a while now, so it was developed with the early Node.

  • It's a project that grew with Node ecology.

  • This is the State of JavaScript,

  • a website that surveys about the ecosystem of Javascript every year.

  • Last year, Jest was used the most

  • and Mocha was second place.

  • In my memory, before then, Mocha was used the most

  • but Jest arose to the top last year.

  • Seen from the back, the colors may not be distinguishable.

  • Red is 'Have used

  • and is willing to use in the future.'

  • Blue is 'Have heard of it and is willing to try it in the future.'

  • Grey is 'Never heard of it.'

  • It's distinguished like that.

  • When I checked on the weekends,

  • Based on GitHub, about 870,000 projects were used.

  • There are about 18,000 stars recorded.

  • To start my talk,

  • I think I should talk about how I joined as a maintainer.

  • I think a lot of you would be curious about that.

  • It was last year, March 6th.

  • On March 6th, I first joined the Mocha organization

  • I got a call from the lead maintainer.

  • The maintainer called me to work together and I agreed.

  • When I joined,

  • This is the 2017s and the early 2018s, when I first went in,

  • this was my GitHub contribution graph.

  • As you can see, from January of 2018 and onwards, the contribution is completely different.

  • I was working hard on gardening.

  • The reason why I could do this is because I resigned at the end of 2017.

  • I resigned at the end of the year and it was hard to transfer companies at the end or the beginning of the year.

  • No one was recruiting, so I was thinking of taking some time off work for 2~3 months.

  • But I couldn't waste 2~3 months.

  • So I studied and did other things but

  • I wanted to contribute to open source

  • So that is how the graph I just showed you was made.

  • So, I was searching for issues on projects I was using, which includes Mocha,

  • I had been using Mocha for a long time and Mocha was one of the subjects.

  • Of course, before this, I was uploading PRs from time to time.

  • So before I joined,

  • from 2011 to 2018,

  • I contributed seven commits to Mocha.

  • And among them, five were done between January and February.

  • Before that, I did simple ones.

  • I made five commits in January to February and uploaded my PR.

  • And I joined after getting a call, and when I got in,

  • it was the time they increased the number of maintainers, I think.

  • That's something hard to know from the outside. Getting inside and looking at the projects,

  • I feel that that was the period, and working together,

  • Mocha is a community based, open source project

  • When I say it's based on community,

  • I mean we don't have a full time maintainer

  • We all have our own jobs and schedules.

  • The majority of people maintain Mocha after getting off work.

  • For a vendor supported project, like React

  • In this case, Facebook gives them lots of money

  • and hires full-time developers.

  • So I think the process would differ.

  • I haven't participated in that kind of thing myself.

  • And of course, just because it's community based,

  • doesn't mean there isn't a full-time open source developer.

  • I was just talking about Mocha's situation.

  • Namely, Babel, for example,

  • Henry is the full-time lead maintainer.

  • So open source development.

  • is usually done like this.

  • I said I made about five commits in a short time, during January and February.

  • I uploaded five PRs.

  • But working within a short time, becoming an insider and seeing the PRs,

  • you start to notice some people that come around often.

  • There are too many people who come once or twice.

  • So they aren't that memorable.

  • But people who come 3,4 or 4,5 times in a short time,

  • or who leave comments through PR are memorable.

  • And when the company is at a time to hire more maintainers,

  • we call those people, give out offers and they join us.

  • There were about two people who joined like that after me.

  • Since it's community based,

  • The members aren't fixed. There are about 10 people in our core team.

  • I've never met about 3 or 4 of them.

  • I haven't ever seen them since I joined.

  • There are people who were active last year but aren't as present this year.

  • That's kind of how it works.

  • And if the number of core members seems to reduce,

  • and if someone seems to be working more actively,

  • we call that person to join. That's how stuff runs.

  • So when I first joined, I had big dreams.

  • Unlike before, when I uploaded GitHub as a individual side project,

  • This is a projects that everyone knows.

  • And there are skilled developers.

  • Working with these people,

  • how much would I learn from them? Or what would I be able to do?

  • I fantasized about these questions.

  • Then a year has passed now. About a year and a half passed.

  • The thing that struck me the most is that maintainers are busy. They are so busy.

  • There is too much work for the maintainers.

  • I worked on open source projects before.

  • My side project became an open source project

  • and I got PRs and issues.

  • I talked with people and had that experience for several years.

  • So I thought I knew how this all works.

  • So last year, in the ecosystem of open source,

  • as a member of that ecosystem, I made a presentation on what developers must do

  • elsewhere.

  • At the time, of course, I talked about how busy maintainers are.

  • But after actually experiencing the life myself, I realize that's it's way more hectic.

  • It's too busy. I get the feeling that I really have to pay attention and focus on working on open source

  • So, looking at one example, there's a notification function on Github.

  • So, Github notifications will keep coming to me.

  • I don't know if you can see well from the back.

  • In the case of Mocha, I get about 2~3 each day.

  • When theres a lot, 4 or 5.

  • Mocha is not that big of a project, so it doesn't get that many.

  • If you're curious about really large projects, watch React or Node,

  • you will be able to see how many notifications are sent each day.

  • Mocha is not at that level.

  • These notifications come, 2 or 3 per day. If I take a break for a day or two or eat out,

  • then I'll miss the notifications and they will pile up.

  • It will pile up everyday, and I will have to take a look at all of them after work.

  • So, at the end of the day I think I should work on Mocha, and go in and press the notifications.

  • These are some stuff, it's just an example.

  • And I will go through them.

  • What problem this person has, why she raised this issue, and what she's saying,

  • How the code example is constructed, what the difficulty is,

  • I try to identify all the details, and then start to label them.

  • I do the labeling, and the reason for labeling is for other people, other maintainers,

  • or other people who contribute to Mocha

  • to better identify what the issue is.

  • Labeling involves categorizing, if the case is

  • a browser issue, or a node issue,

  • or it can be more detailed,

  • such as whether it needed additional information, if it confirmed a bug, and so on.

  • And for those issues that can be resolved, I leave comments.

  • For issues that I have an opinion on, I leave comments.

  • For this case, displayed here on the screen, I left a comment and closed the issue.

  • In this case, the person who raised the issue

  • wasn't familiar with Node, and thus was not aware of the appropriate usage method.

  • So he uploaded it as a Mocha issue, but it turned out that he was using Node incorrectly

  • The comment here is just one sentence, and a single line of code,

  • but when I upload this, I have to read the whole post

  • and then find out what the problem is from the example codes and stuff,

  • so I have to try and figure out the answer myself in order to post it.

  • I can answer really simple ones right away,

  • but for most of the posts, I have to execute and try them myself at least.

  • Also, because Mocha is a test framework, some people would run tests called Karma,

  • and others would use Babel or Webpack, which may get the system tangled up.

  • If things like those come up, I have to run various tests.

  • Then, it would take about 20~30 minutes minimum to look into a single issue.

  • It may take up to 1 or 2 hours, if it takes longer.

  • So, in order to save time, if maintainers don't have enough information,

  • they request MCVE.

  • Or they request additional information.

  • We cannot actually test every single thing.

  • I try to imagine what I need, and if I think something is lacking, I would request it.

  • What MCVE is,

  • there's a guide document for Stack Overflow.

  • An example which has a certain degree of completeness and is verifiable is called

  • MCVE.

  • When people ask questions, or raise issues, it's all the same thing.

  • Companies' codes are massive. Various code are intertwined.

  • So if we provide an example which can, at minimum, completely control the problem,

  • maintainers would know by executing it right after downloading it.

  • Most of the times, if that much information is provided, they would probably know without downloading it.

  • It can really save some time.