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.