Placeholder Image

Subtitles section Play video

  • 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.

  • And from the list of notifications,

  • if it's a PR case, I have to conduct code review.

  • Often, code reviews have issues. So, I look at the history of

  • issues, and identify what the original issues were.

  • I look at the contents of the discussion, and come back to the PR.

  • From the PR pull request,

  • I read to find out what the person intended to edit,

  • look at it along with the code, and provide an opinion.

  • Whether I agree, if something is incorrect, or if something is missing, etc.

  • I'm not just a person who writes comments, so I have to write code as well.

  • I have to write my code as well.

  • This is the most time consuming. Because I have to look for an issue, and resolve it.

  • Contributors also have discussions among themselves.

  • If there's an issue not being allocated, or road map meetings, and so on.

  • We discuss through chats about releases, or other questions we may have.

  • This happens on a daily, weekly basis.

  • In my opinion, I would have to spend 2 to 3 hours a day after work

  • in order to keep up with the pace.

  • If I miss a day, then I would have more burden later on.

  • So actually, this may be an answer to the question 'Why doesn't my PR get merged?'

  • 'Why doesn't anyone answer my issue?'

  • 'Why is nobody interested?' It's just that everyone is so busy

  • that not all issues can be looked at.

  • Not only that maintainers don't have the obligation to look at all issues,

  • but they just can't. And if they miss a notification once,

  • then it's just gone for good.

  • Also, looking more closely, maintainers don't just have one of these projects.

  • A Mocha maintainer is not just a maintainer for Mocha.

  • There are many projects like Mocha. They may have a side project of their own, aside from their day job.

  • They have really little time for a single project, among all different duties.

  • So, most of the maintainers' activities are

  • designed so that the maintainer can actually continue work for a long time.

  • The top priority is focused on operation and management.

  • But, another big consideration is to avoid burnout for maintainers,

  • and enable them to continue as maintainers for a prolonged period of time.

  • So, a lot of efforts are made to avoid giving and receiving pressure regarding the timeline.

  • Of course, calls are made to core teams to ask them to

  • look at this thing, review this, provide opinion, etc.

  • But there's no blame for not doing it,

  • and mostly they work on their own schedule.

  • When they get the chance, they would just look at it a bit more.

  • That's how the system works at the moment.

  • Because it's not something that would end in a month or two.

  • It's not like something amazing would be made

  • after a sudden, short crunch period.

  • Everyone works based on their own life pattern,

  • and if their interests in Mocha goes away,

  • they would quit and new people would come in. That's because it's open source.

  • And of course, there are impolite people in the community.

  • We give warnings to those people.

  • There weren't that many instances, but when there's someone rude,

  • maintainers would talk about it.

  • So to summarize,

  • we understand that you're in trouble due to an absence of a certain function.

  • But after all, everyone in this project is only volunteering. So please be polite, and avoid rude comments or requests.

  • we ask

  • not to be impolite,

  • or maybe

  • make unrealistic demands, we warn against those behaviors.

  • That's how we do our work, with such guidelines.

  • Also, as we maintain the project,

  • it's pretty much

  • connected what I said previously,

  • which is that it's very important to feel relaxed.

  • I think it's very important

  • to practice staying relaxed,

  • and you have to train yourself

  • to escape feelings of pressure.

  • I too experienced

  • such problems for the first time when I worked on an individual project.

  • I felt very pressured.

  • Because,

  • I thought I'd made some kind of a mistake,

  • and that fear of clients leaving pressured me to fix the problems as fast as I could.

  • I thought I was a bit more trained for such situations,

  • and I'm better now.

  • But,

  • then,

  • Quite a lot of users

  • watch such programs like Mocha

  • and that was very hard on me at the time,

  • and after about a year

  • now I feel a bit better

  • although not perfectly,

  • I do think I'm feeling a lot better.

  • Therefore, open source is for

  • those people who feel the urgency and necessity themselves

  • to upload the code.

  • It's not obligated

  • for the maintainers or contributors to fix them when asked,

  • If any individual feels that this is urgent,

  • this is so urgent for me,

  • than you upload the code

  • and persuade for us to apply that code.

  • This is not such a relation where

  • the maintainers have to figure it out

  • because they owe you something.

  • This is why there is an option called the bail option in Mocha

  • I put this in in the beginning,

  • now

  • this is one of the options, I mean PR

  • that came to existence after I became a maintainer,

  • and after six months, it was backed out.

  • It was debated after other issues and side effects

  • that this was a 'Completely wrong PR'

  • 'get it backed out'

  • that was the verdict.

  • There was a lot more discussion down below,

  • and then we ultimately deleted it.

  • We backed out.

  • Another incident like this happened to me.

  • There was another one like this,

  • which made me discouraged.

  • Because every time I uploaded a PR in Mocha,

  • it got backed out,

  • and that just made me intimidated.

  • Intimidated and,

  • I think I'm still a little intimidated right now.

  • And because of that

  • I think

  • it made me take care of more minor stuffs.

  • This is because I don't have full understanding of the core code,

  • and the legacy code is big because it's been there for a long time.

  • I can't understand it fully,

  • so it made me scared to do it,

  • there's that problem,

  • but I'm trying to increase little by little.

  • And the reason why such problem took place was,

  • I've never used other things other than the ones I've always used.

  • I've been using Mocha for a long time,

  • and have been doing tests on Mocha,

  • but I only use

  • just the pattern I always use,

  • my go-to set,

  • I only use that,

  • I don't use all the different options, different options every month.

  • Even in the case of Mocha right now,

  • there are so many options,

  • and we use these codes by mixing them,

  • but for me, other than the codes I use, I don't know the other ones.

  • To be honest, there are some options that I didn't know existed before I became a maintainer.

  • Since we can't use all of them,

  • I just contribute what I can.

  • What is the thing that I can do better than others?

  • The small things

  • like looking over the homepage

  • or taking care of things that catch my eye, little by little

  • since those things also take some time to finish.

  • I just mainly do those things

  • and I try to keep up by working on the core in my own time

  • and studying little by little.

  • And the other thing that was impressive was,

  • the competition in open source is very fierce.

  • Although I say I like open source,

  • I think I just seem to have

  • somewhat accepted

  • that competitive culture of the system,

  • fighting for 'What the people like best',

  • I've come to terms with it naturally.

  • In the beginning

  • it said that Jest came in first last year,

  • and one of our core members uploaded such a comment last year.

  • "Now,

  • Jest is getting popular these days,

  • we should put in some popular functions like Jest, such as snapshots and coverage and other stuff

  • That's the comment he left.

  • When he said

  • why don't we put in such functions as well?

  • What happened was

  • the maintainers who have been working for longer periods in open source appeared

  • and left such comment.

  • Now the text is long,

  • but to put it short,

  • 'Mocha does not effect Jest,

  • and Jest does not effect Mocha,

  • we are just

  • trying to each achieve our goal

  • of making a better environment

  • for testing in the system of Java Script,

  • so that we can create more tests.

  • We don't have any problems with each other

  • is what he left in the comments.

  • And Christopher, the creator of Jest was also summoned

  • he was brought to the comment and he left a long message here.

  • He said that such comments like this

  • really puts him off.

  • Jest and Mocha are not competing,

  • so people should not think

  • that in order for one to succeed

  • the other should suffer or have problems.

  • We each have different characteristics and each is a test framework

  • with their own territory.

  • This comment

  • left a great impression on me.

  • Like this,

  • of course I had the thought that it was

  • natural for us to feel the need to compete somewhere in our mind.

  • Although we don't necessarily have a bad relationship,

  • I still had these thoughts of wanting

  • for my side to have the better outcome,

  • but in the end we are all in the same system of open source

  • so I learned there's no need for that type of thinking.

  • And actually working in the field, I felt my limit in English.

  • I wasn't all that great with English to begin with.

  • But before,

  • I could skip some issues that I didn't understand.

  • Because I couldn't figure it out anyways.

  • Also

  • I only had to go over those things that I could solve and understand.

  • So it wasn't really a big problem for me

  • and all I had to do was take the edited code

  • and discuss and review at the PR,

  • but since I became the maintainer,

  • I had to look at almost every issue and take part in the discussions.

  • That's how I can follow the context to some extent.

  • Even if I couldn't go through it all.

  • It all takes so much time,

  • and it's really hard.

  • And I could still take part in

  • the discussions about simple code,

  • but when they continue on to complex debates,

  • people comment their opinions.

  • It was hard for me to participate when we had to say our own opinions.

  • I understood what others said, but it was hard for me to deliver my own opinion

  • with the exact nuance and tone needed.

  • So, this

  • led me to say only the most basic things.

  • Like here, I would only say LGTM.

  • I would say it just like this.

  • Although I don't completely 'agree' to it

  • I thought

  • it would be

  • better for me to say that and stop

  • than to say more in English.

  • And with this

  • we agree and move on.

  • And now,

  • I didn't know this before I became the maintainer,

  • but there are issues where the threads are really long.

  • Or some issues that are old or closed.

  • And even on those issues, people continuously leave comments.

  • People would say they've experienced such problems too.

  • I have that error too.

  • They leave those comments

  • continuously in already

  • closed issues.

  • But this is a great burden for the maintainers.

  • Because

  • old ones mostly have long threads

  • and I click on it and it has,

  • for example, 38 threads

  • and the comments below are "I also have this error"

  • "Fix this for me",

  • so I have to go all the way up and read them.

  • What is the issue?

  • What is the issue that everyone still has a problem with?

  • I have read through all of them,

  • and that becomes a real big burden.

  • And I've never actually seen

  • one reopen in Mocha even to this day.

  • So basically,

  • in these situations

  • It does not reopen no matter how much you write.

  • Yes.

  • So the one that we uploaded,

  • now,

  • we used an application called Probot

  • and said, let's close

  • all the threads that were already closed before.

  • Let's lock them.

  • Lock them so people do not leave any more comments there,

  • this was the thread to prevent such things from happening

  • And then,

  • this originated from

  • Henry, who develops Babel, who said something similar to this.

  • It takes up too much of the maintainers' time,

  • so let's have it be like, after a certain period of time passes after the threads close

  • using an automated script,

  • let's have all the threads be locked.

  • Rather than leaving any comments in the locked thread,

  • it's better for people to make a new issue, link it,

  • and then we at the headquarters can then upload the summary of that situation for the user.

  • This way is a more convenient

  • method of handling problems.

  • If they use older threads, we are not sure if they're using older versions

  • or they just have the same bugs

  • there's no way finding it out, so we just ignore them.

  • We just look at it and do nothing about it.

  • Serving as a maintainer,

  • I think a lot about the characteristics of the framework.

  • Before,

  • I just used the frameworks I liked,

  • And if I don't like it, I proceeded to another framework.

  • If I don't like Mocha, I moved on to Jest, or something like that.

  • Now that I am in the development team

  • I find that the users just request the functions they need.

  • I need this.

  • That's all that they say.

  • But when I am handed their requests, I think about a lot of factors.

  • I have to understand its whole function,

  • and I have to understand that

  • what parts of our function is this function connected to,

  • when I add this function, does it interfere with other functions

  • I have to deal with such issues.

  • Also to consider are the characteristics of our project,

  • is this an issue we, or I, have to deal with?

  • Is it our responsibility as well?

  • or should I say that it

  • should be relegated to a third party

  • it's hard to decide those things.

  • I thought I will understand it after a few months into the job,

  • but there are so many issues and the topic is so broad,

  • It's actually still hard to grasp.

  • I still don't understand it even though I work on it.

  • So on those parts, I decided to

  • think about it myself the best I can,

  • and deliberate over what kind of test framework Mocha should ultimately be.

  • This is what's called the This.skip in Mocha.

  • It's a function that from Mocha,

  • we this.skip to the code,

  • and it's skipped.

  • But this

  • had a lot of problems.

  • For example,

  • it's complicated.

  • In the before hook,

  • there is a test

  • and you know we have the before-after hook.

  • If we this.skip from the before hook

  • how far we're actually skipped to

  • is not consistent.

  • For someone,

  • we can skip the before hook and still run the test.

  • For someone else, on the after hook,

  • they say the after hook should at least be organized,

  • if we skip the `should it`

  • are the sub-`should it` skipped as well, these kind of circumstances

  • all differ and in the end, we have so many to deal with.

  • But those cases,

  • when I tried to fix them individually

  • there were some mistakes and inconsistencies and many other problems.

  • So someone uploaded a PR to get all these organized at once,

  • you may not be able to see it from the back

  • but this was uploaded in November 2018.

  • And it was merged,

  • we were discussing with 90 comments and it was merged in December.

  • It took 10, 11 months.

  • To get it to the merging stage.

  • We kept discussing there

  • and the person who uploaded the PR

  • stayed until the end, I respect that,

  • and this shows that

  • even one fix comes with so many

  • different issues to think about.

  • So in fact I can't respond to all the requests.

  • Then where's the line?

  • What kind of characteristics Mocha should have?

  • To what extent its functions should be? Those kinds of issues.

  • Thinking about it, the maintainers need to get together for a roadmap meeting.

  • We talked about it a few times,

  • but we haven't gotten into specifics on the get-together yet.

  • And the Node.js has the LTS policy.

  • The Node.js

  • keeps discontinuing support

  • and in June,

  • they stopped the support for Node.js V6

  • and now Node.js V8 support

  • is being discontinued next year.

  • Next year,

  • so this coming April.

  • The support stops in April.

  • Then I am going to use LTS if I'd like a stable operation with Node.js,

  • and if I'd like to use it aggressively

  • I'd use the current version

  • That's how I've been using it up until now.

  • Now from the position of doing open source at the maintenance-level

  • what I like about it is

  • If Mocha drops something, we drop something too.

  • For example,

  • now that Mocha has dropped 6

  • We can use the async await.

  • These kind of things,

  • We couldn't use it until then, because

  • the ecosystem of Mocha Javascript

  • uses Node 6, so we have to support that as well.

  • But if the node does not support that, we don't have to do it either,

  • those kind of things are very convenient for maintenance.

  • And these changes are predictable.

  • So, lastly,

  • I love this quote

  • It's a quote from someone else.

  • Someone wrote on Twitter,

  • that the open source should

  • not be treated like a product we purchased

  • but it should be treated like a team we belong to.

  • That's how the quote goes.

  • I used this quote in some other presentation before.

  • With this,

  • I will end my presentation.

  • Thank you.

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

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it