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.