New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop support of node v0.10 #816

Merged
merged 1 commit into from Nov 1, 2016

Conversation

Projects
None yet
7 participants
@vieiralucas
Member

vieiralucas commented Oct 2, 2016

As @keithamus suggested here, Chai should no longer support node v0.10 since Oct 1st

@lucasfcosta

This comment has been minimized.

Show comment
Hide comment
@lucasfcosta

lucasfcosta Oct 2, 2016

Member

LGTM.

Member

lucasfcosta commented Oct 2, 2016

LGTM.

@meeber

This comment has been minimized.

Show comment
Hide comment
@meeber

meeber Oct 2, 2016

Contributor

LGTM

Contributor

meeber commented Oct 2, 2016

LGTM

@meeber

This comment has been minimized.

Show comment
Hide comment
@meeber

meeber Oct 3, 2016

Contributor

Wait hold on, looks like EoL is 10-31 not 10-01

Contributor

meeber commented Oct 3, 2016

Wait hold on, looks like EoL is 10-31 not 10-01

@lucasfcosta

This comment has been minimized.

Show comment
Hide comment
@lucasfcosta

lucasfcosta Oct 3, 2016

Member

@meeber actually they changed this 9 hours ago.

It's clear they've got something against the Lucas Syndicate.

nodejs/Release@b90f5a9

Member

lucasfcosta commented Oct 3, 2016

@meeber actually they changed this 9 hours ago.

It's clear they've got something against the Lucas Syndicate.

nodejs/Release@b90f5a9

@vieiralucas

This comment has been minimized.

Show comment
Hide comment
@vieiralucas

vieiralucas Oct 3, 2016

Member

Looks like guys from node are trolling me

Member

vieiralucas commented Oct 3, 2016

Looks like guys from node are trolling me

@vieiralucas

This comment has been minimized.

Show comment
Hide comment
@vieiralucas

vieiralucas Oct 3, 2016

Member

The Lucas Syndicate must not be taken down.
I vote for letting this PR open until 1st of November 🎉

Member

vieiralucas commented Oct 3, 2016

The Lucas Syndicate must not be taken down.
I vote for letting this PR open until 1st of November 🎉

@vieiralucas

This comment has been minimized.

Show comment
Hide comment
@vieiralucas

vieiralucas Nov 1, 2016

Member

Can we merge this now? @meeber @lucasfcosta ?

Member

vieiralucas commented Nov 1, 2016

Can we merge this now? @meeber @lucasfcosta ?

@meeber meeber merged commit 9e16c8f into chaijs:master Nov 1, 2016

2 checks passed

approvals/lgtm this commit looks good
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@vieiralucas vieiralucas deleted the vieiralucas:drop-node-0.10 branch Nov 1, 2016

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Nov 1, 2016

Do you all know if there's been any coordination or discussion with the Mocha side of things?

jdalton commented Nov 1, 2016

Do you all know if there's been any coordination or discussion with the Mocha side of things?

@lucasfcosta

This comment has been minimized.

Show comment
Hide comment
@lucasfcosta

lucasfcosta Nov 2, 2016

Member

@jdalton actually we didn't talk to them yet, but it seems like a good idea. We have released a canary version recently, so it might be a good idea to run some compatibility tests.
Let's get in touch with the guys from Mocha, what do you think?

Member

lucasfcosta commented Nov 2, 2016

@jdalton actually we didn't talk to them yet, but it seems like a good idea. We have released a canary version recently, so it might be a good idea to run some compatibility tests.
Let's get in touch with the guys from Mocha, what do you think?

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton commented Nov 2, 2016

\cc @boneskull.

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Nov 2, 2016

Contributor

@jdalton Thanks.

For the sake of discussion:

I understand v0.10 is unsupported.

  • Why does this mean projects should drop support for it?
  • What does a Mocha or Chai lose if it doesn't?
  • What's the difference between keeping v0.10 support and keeping IE7 support?
  • Mocha runs on Node.js v0.8 if npm v2.x is installed (last time I checked)

While Mocha and Chai are the most popular combo of packages, neither requires the other to be present. So to what degree should we maintain compatibility? How important is it we're in sync?

Along those lines, we may have significant influence on v0.10 holdouts, simply because of the size of our user bases. It would seem "good" to help drive this forward. But, is it userland's responsibility to drive LTS adoption?

Contributor

boneskull commented Nov 2, 2016

@jdalton Thanks.

For the sake of discussion:

I understand v0.10 is unsupported.

  • Why does this mean projects should drop support for it?
  • What does a Mocha or Chai lose if it doesn't?
  • What's the difference between keeping v0.10 support and keeping IE7 support?
  • Mocha runs on Node.js v0.8 if npm v2.x is installed (last time I checked)

While Mocha and Chai are the most popular combo of packages, neither requires the other to be present. So to what degree should we maintain compatibility? How important is it we're in sync?

Along those lines, we may have significant influence on v0.10 holdouts, simply because of the size of our user bases. It would seem "good" to help drive this forward. But, is it userland's responsibility to drive LTS adoption?

@keithamus

This comment has been minimized.

Show comment
Hide comment
@keithamus

keithamus Nov 2, 2016

Member

Thanks @jdalton & @boneskull

Why does this mean projects should drop support for it?

Critical fixes that are needed in Node 0.10 won't be patched in, so if a vulnerability is found in Node 0.10 - it won't be fixed. In addition, new features which we'd like to utilise will never be supported in these older versions. A concrete example: we use Proxies for a certain feature - we can't use those in 0.10 (or 0.12 or 4.0 but that's another discussion). To put it succinctly - this is an opportunity for us to move the platform forward.

What does a Mocha or Chai lose if it doesn't?

If we don't support 0.10, then we lose a potential portion of our user base who are still using 0.10. We also lose the burden of supporting Node 0.10 - which I guess is a gain, not a loss 😆

What's the difference between keeping v0.10 support and keeping IE7 support?

None I suppose - but for clarity - Chai 3.5.0 & the upcoming Chai 4 don't actually support IE7. We dropped support for IE7 and IE8 a while ago, or actually - we never really properly supported them (I think).

Mocha runs on Node.js v0.8 if npm v2.x is installed (last time I checked)

This may be problematic I suppose?

While Mocha and Chai are the most popular combo of packages, neither requires the other to be present. So to what degree should we maintain compatibility? How important is it we're in sync?

Good question. I suppose Node 0.10 users can always just use Node's assert over Chai, whereas there isn't an alternative to Mocha I guess? It could be jarring to users who often conflate mocha with chai, to see one of them not working. If we're out of sync, we might see issues on eachother's respective trackers about this - which is a small burden, but a burden nonetheless. (Side note: as I'm sure mocha does; we get a good handful of issues which are mocha related fairly frequently on the chai issue tracker already).

Along those lines, we may have significant influence on v0.10 holdouts, simply because of the size of our user bases. It would seem "good" to help drive this forward. But, is it userland's responsibility to drive LTS adoption?

Another good point - however I'd like to change the train of thought here. While we're in a position of leverage, and could use that to influence LTS adoption, and it is arguable as to whether we should do it or not, there is a more salient point: Chai, and I am fairly sure Mocha have small teams with a big codebase. I feel it is less of a "let's leverage our position" and more a case of "we don't really have resources to support these old versions, while still moving forward with desired features"

Member

keithamus commented Nov 2, 2016

Thanks @jdalton & @boneskull

Why does this mean projects should drop support for it?

Critical fixes that are needed in Node 0.10 won't be patched in, so if a vulnerability is found in Node 0.10 - it won't be fixed. In addition, new features which we'd like to utilise will never be supported in these older versions. A concrete example: we use Proxies for a certain feature - we can't use those in 0.10 (or 0.12 or 4.0 but that's another discussion). To put it succinctly - this is an opportunity for us to move the platform forward.

What does a Mocha or Chai lose if it doesn't?

If we don't support 0.10, then we lose a potential portion of our user base who are still using 0.10. We also lose the burden of supporting Node 0.10 - which I guess is a gain, not a loss 😆

What's the difference between keeping v0.10 support and keeping IE7 support?

None I suppose - but for clarity - Chai 3.5.0 & the upcoming Chai 4 don't actually support IE7. We dropped support for IE7 and IE8 a while ago, or actually - we never really properly supported them (I think).

Mocha runs on Node.js v0.8 if npm v2.x is installed (last time I checked)

This may be problematic I suppose?

While Mocha and Chai are the most popular combo of packages, neither requires the other to be present. So to what degree should we maintain compatibility? How important is it we're in sync?

Good question. I suppose Node 0.10 users can always just use Node's assert over Chai, whereas there isn't an alternative to Mocha I guess? It could be jarring to users who often conflate mocha with chai, to see one of them not working. If we're out of sync, we might see issues on eachother's respective trackers about this - which is a small burden, but a burden nonetheless. (Side note: as I'm sure mocha does; we get a good handful of issues which are mocha related fairly frequently on the chai issue tracker already).

Along those lines, we may have significant influence on v0.10 holdouts, simply because of the size of our user bases. It would seem "good" to help drive this forward. But, is it userland's responsibility to drive LTS adoption?

Another good point - however I'd like to change the train of thought here. While we're in a position of leverage, and could use that to influence LTS adoption, and it is arguable as to whether we should do it or not, there is a more salient point: Chai, and I am fairly sure Mocha have small teams with a big codebase. I feel it is less of a "let's leverage our position" and more a case of "we don't really have resources to support these old versions, while still moving forward with desired features"

@meeber

This comment has been minimized.

Show comment
Hide comment
@meeber

meeber Nov 2, 2016

Contributor

From the downstream perspective:

When an organization decides to keep running an unmaintained version of Node (e.g., v0.10), they've already made the painful determination that the cost of upgrading Node is greater than the cost of either a) maintaining that version of Node themselves by writing patches as future vulnerabilities are discovered, or b) exposing their servers to those unpatched vulnerabilities. They've also determined that having access to the latest language features isn't a big enough benefit to tip the scales in favor of upgrading Node.

Given the decision that they've already made, should such an organization then have a reasonable expectation to use the latest versions of upstream libraries such as Mocha and Chai? Or is having to use Chai v3.5 instead of Chai v4.0 just a relatively small part of the large cost they've already decided to pay by running an unmaintained version of Node?

From the upstream perspective:

It's up to each library maintainer to decide if they want to pitch in and help pay the cost that's incurred by those running an unmaintained version of Node. That cost is paid primarily by library developers in terms of time. It takes time to maintain compatibility with legacy platforms due to having to troubleshoot and program around one-off behaviors, as well as address user-reported issues specific to legacy platforms.

The cost is also shared among all users of the library because less time is spent moving the library forward with improvements, as well as because there are more restrictions in terms of using new language features to make the library better.

Maintaining compatibility with legacy platforms also increases complexity of the code due to feature detection and branching logic. It also often has a performance impact, although usually at the micro level.

I don't think the benefit of supporting unmaintained versions of Node is worth the cost to Chai. And the downstream organizations that made the decision to run an unmaintained version of Node should already have come to terms with the fact that they're probably not going to be able to use the latest and greatest stuff.

It should be stressed that a downstream organization running an unmaintained version of Node (or another library wishing to support unmaintained versions of Node) can still use Chai. They just can't use the latest version.

All of this is to say that I agree with a comment made by @keithamus in another thread:

I think supporting every engine that is officially supported by their respective vendors is a happy and relatively non-arbitrary point to fix to

From my perspective, tight coordination between Mocha and Chai in terms of platform support only becomes critical if one of the two libraries decides to drop support for a version of Node that's still officially maintained, in which case it has the potential to negatively impact large groups of users that haven't already gone through the difficult decision making process about running unmaintained software.

Contributor

meeber commented Nov 2, 2016

From the downstream perspective:

When an organization decides to keep running an unmaintained version of Node (e.g., v0.10), they've already made the painful determination that the cost of upgrading Node is greater than the cost of either a) maintaining that version of Node themselves by writing patches as future vulnerabilities are discovered, or b) exposing their servers to those unpatched vulnerabilities. They've also determined that having access to the latest language features isn't a big enough benefit to tip the scales in favor of upgrading Node.

Given the decision that they've already made, should such an organization then have a reasonable expectation to use the latest versions of upstream libraries such as Mocha and Chai? Or is having to use Chai v3.5 instead of Chai v4.0 just a relatively small part of the large cost they've already decided to pay by running an unmaintained version of Node?

From the upstream perspective:

It's up to each library maintainer to decide if they want to pitch in and help pay the cost that's incurred by those running an unmaintained version of Node. That cost is paid primarily by library developers in terms of time. It takes time to maintain compatibility with legacy platforms due to having to troubleshoot and program around one-off behaviors, as well as address user-reported issues specific to legacy platforms.

The cost is also shared among all users of the library because less time is spent moving the library forward with improvements, as well as because there are more restrictions in terms of using new language features to make the library better.

Maintaining compatibility with legacy platforms also increases complexity of the code due to feature detection and branching logic. It also often has a performance impact, although usually at the micro level.

I don't think the benefit of supporting unmaintained versions of Node is worth the cost to Chai. And the downstream organizations that made the decision to run an unmaintained version of Node should already have come to terms with the fact that they're probably not going to be able to use the latest and greatest stuff.

It should be stressed that a downstream organization running an unmaintained version of Node (or another library wishing to support unmaintained versions of Node) can still use Chai. They just can't use the latest version.

All of this is to say that I agree with a comment made by @keithamus in another thread:

I think supporting every engine that is officially supported by their respective vendors is a happy and relatively non-arbitrary point to fix to

From my perspective, tight coordination between Mocha and Chai in terms of platform support only becomes critical if one of the two libraries decides to drop support for a version of Node that's still officially maintained, in which case it has the potential to negatively impact large groups of users that haven't already gone through the difficult decision making process about running unmaintained software.

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Nov 2, 2016

Contributor

Thanks for the comments. Please allow me to prattle.

Mocha contains no ES6 features and very few ES5 features. It'd be cool to bring the codebase current. But in reality, there's no resources for such an effort. Holding on to v0.10 support may not be "easier" than simply dropping it, but there's no current proposal on the table that would necessitate v4.x for production use.

(We've held back ESLint, so we're feeling this more on the development end. But what's needed for development and what's needed for production don't absolutely need to be equal--and ESLint 3 isn't really compelling enough. In a perfect world, if Mocha drops support, maybe it should have something shiny to entice an upgrade!)

Dropping IE7, IE8, and PhantomJS 1.x would bring us to ES5. We could drop many handrolled shims, and the codebase would be simplified. But someone still has to do it.

I'd like to drop v0.10, but I'm having a hard time justifying doing that now, in other words. About all I could say is "we'd get the latest version of ESLint". The immediate impact on the maintenance burden would be small, because v0.10 is not our biggest problem--IE7/8 is.


Notes:

Most of the "Chai" issues I see are users misunderstanding which part of a test failure output comes from where. This is understandable, because Chai makes the determination to fail, but it's up to Mocha to do something with that information.

@meeber makes an excellent point that if an org uses an unsupported version of Node.js, they shouldn't expect cool new stuff--or even critical fixes-- from userland. I am probably guilty of losing sight of that.

Contributor

boneskull commented Nov 2, 2016

Thanks for the comments. Please allow me to prattle.

Mocha contains no ES6 features and very few ES5 features. It'd be cool to bring the codebase current. But in reality, there's no resources for such an effort. Holding on to v0.10 support may not be "easier" than simply dropping it, but there's no current proposal on the table that would necessitate v4.x for production use.

(We've held back ESLint, so we're feeling this more on the development end. But what's needed for development and what's needed for production don't absolutely need to be equal--and ESLint 3 isn't really compelling enough. In a perfect world, if Mocha drops support, maybe it should have something shiny to entice an upgrade!)

Dropping IE7, IE8, and PhantomJS 1.x would bring us to ES5. We could drop many handrolled shims, and the codebase would be simplified. But someone still has to do it.

I'd like to drop v0.10, but I'm having a hard time justifying doing that now, in other words. About all I could say is "we'd get the latest version of ESLint". The immediate impact on the maintenance burden would be small, because v0.10 is not our biggest problem--IE7/8 is.


Notes:

Most of the "Chai" issues I see are users misunderstanding which part of a test failure output comes from where. This is understandable, because Chai makes the determination to fail, but it's up to Mocha to do something with that information.

@meeber makes an excellent point that if an org uses an unsupported version of Node.js, they shouldn't expect cool new stuff--or even critical fixes-- from userland. I am probably guilty of losing sight of that.

@lucasfcosta

This comment has been minimized.

Show comment
Hide comment
@lucasfcosta

lucasfcosta Nov 2, 2016

Member

@boneskull thanks for your input! 😄

Well, even if you don't need v4.x to support anything new, it would still be interesting to go forward with Mocha without always depending on supporting older versions. Here at Chai, for example, even though we are still able to run on v0.10 (without some features, but anyway, we're still able to do so) we simply won't take the burden of having to fix things if they break on v0.10 from now on. This not only allows you to support new features that depend on v4.x on the future, but it also reduces the amount of work your team needs to do in case something breaks on v0.10, allowing you to focus on updating the codebase.

The same applies to IE7/8, if they're not supported anymore, dropping them would just be easier and reduce the maintenance burden.


Regarding the issues on both trackers, I think there's no way we can solve this, that totally depends on our users. We can warn them, but this will still happen and I think it's not a big deal, because (IMO) our job as Open Source contributors should be to help people in the first place, so whenever I see an issue that is related to Mocha and not Chai I still do my best to answer it.
Also, there are some small compatibility issues that still make sense to be reported on our tracker, such as the recent #790 which addressed a minor issue we had with the diffs sent to mocha.

*PS: * If you guys need any help with upgrading Mocha's codebase I'd be more than happy to contribute. I've been reading your code quite frequently but I'm not fully comfortable about submitting PRs yet. Anyway, we're here to help.

Member

lucasfcosta commented Nov 2, 2016

@boneskull thanks for your input! 😄

Well, even if you don't need v4.x to support anything new, it would still be interesting to go forward with Mocha without always depending on supporting older versions. Here at Chai, for example, even though we are still able to run on v0.10 (without some features, but anyway, we're still able to do so) we simply won't take the burden of having to fix things if they break on v0.10 from now on. This not only allows you to support new features that depend on v4.x on the future, but it also reduces the amount of work your team needs to do in case something breaks on v0.10, allowing you to focus on updating the codebase.

The same applies to IE7/8, if they're not supported anymore, dropping them would just be easier and reduce the maintenance burden.


Regarding the issues on both trackers, I think there's no way we can solve this, that totally depends on our users. We can warn them, but this will still happen and I think it's not a big deal, because (IMO) our job as Open Source contributors should be to help people in the first place, so whenever I see an issue that is related to Mocha and not Chai I still do my best to answer it.
Also, there are some small compatibility issues that still make sense to be reported on our tracker, such as the recent #790 which addressed a minor issue we had with the diffs sent to mocha.

*PS: * If you guys need any help with upgrading Mocha's codebase I'd be more than happy to contribute. I've been reading your code quite frequently but I'm not fully comfortable about submitting PRs yet. Anyway, we're here to help.

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Nov 2, 2016

Contributor

@lucasfcosta Thanks for the offer. Sorry for derailing this discussion, but I don't think people realize the kind of pickle OSS projects like Mocha and Chai are in.

I don't have a time series graph to back this up, but I've noted the following from libraries.io:

In the two (2) months of August and September 2016:

  • The number of projects dependent on Mocha increased by over 5,000.
  • In this time, we merged about twelve (12) pull requests with seven (7) unique authors, two (2) of which are core contributors.
  • No core contributors were added.

At the end of October, we lost four (4) core contributors due to inactivity.

What's to be done?

Contributor

boneskull commented Nov 2, 2016

@lucasfcosta Thanks for the offer. Sorry for derailing this discussion, but I don't think people realize the kind of pickle OSS projects like Mocha and Chai are in.

I don't have a time series graph to back this up, but I've noted the following from libraries.io:

In the two (2) months of August and September 2016:

  • The number of projects dependent on Mocha increased by over 5,000.
  • In this time, we merged about twelve (12) pull requests with seven (7) unique authors, two (2) of which are core contributors.
  • No core contributors were added.

At the end of October, we lost four (4) core contributors due to inactivity.

What's to be done?

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Nov 2, 2016

FWIW I run Lodash, which is like the Mocha of direct dependencies (instead of dev deps). Fastest growing direct dep, 1,000+ new direct deps each month, billions of downloads, and so on. And like Mocha the core is small (mostly me). With each major bump (which happens once a year) I raise the minimum support bar (dropping older enviros).

  • v3 dropped Node 0.6 support
  • v4 dropped Node 0.8, IE < 9, oddball Adobe Illustrator support

With v5 we'll drop Node 0.10 and 0.12 support.
Dropping support does help with the maintenance burden and testing cost. Being more lang util focused I have to tackle a lot of edge case engine bugs (even JIT bugs). I dig major version bumps because it gives me the opportunity to shed some of the burden and push things forward.

jdalton commented Nov 2, 2016

FWIW I run Lodash, which is like the Mocha of direct dependencies (instead of dev deps). Fastest growing direct dep, 1,000+ new direct deps each month, billions of downloads, and so on. And like Mocha the core is small (mostly me). With each major bump (which happens once a year) I raise the minimum support bar (dropping older enviros).

  • v3 dropped Node 0.6 support
  • v4 dropped Node 0.8, IE < 9, oddball Adobe Illustrator support

With v5 we'll drop Node 0.10 and 0.12 support.
Dropping support does help with the maintenance burden and testing cost. Being more lang util focused I have to tackle a lot of edge case engine bugs (even JIT bugs). I dig major version bumps because it gives me the opportunity to shed some of the burden and push things forward.

@lucasfcosta

This comment has been minimized.

Show comment
Hide comment
@lucasfcosta

lucasfcosta Nov 2, 2016

Member

@boneskull, don't worry, you are not derailing the discussion, it's always great to talk about Open Source and see different points of view about it. 😄

IMO, attracting new contributors is one of the maintainer's responsibilities. I see many new folks around trying to find a new project to contribute and none of them offers any help for beginners. I was only able to start contributing to Chai because of @keithamus' detailed explanations about what should be done regarding each issue, after a couple of issues I got ready to start sending contributions more often and got confident about making bigger changes on the codebase. Now that I learned a bit about GitHub's etiquette rules and this kind of thing I also feel more comfortable contributing to other projects.

Maybe we, as open source maintainers, should start looking forward to help beginners start contributing and therefore have more people to maintain modules.

Thank you all for sharing your thoughts, you rock, buddies ❤️

Member

lucasfcosta commented Nov 2, 2016

@boneskull, don't worry, you are not derailing the discussion, it's always great to talk about Open Source and see different points of view about it. 😄

IMO, attracting new contributors is one of the maintainer's responsibilities. I see many new folks around trying to find a new project to contribute and none of them offers any help for beginners. I was only able to start contributing to Chai because of @keithamus' detailed explanations about what should be done regarding each issue, after a couple of issues I got ready to start sending contributions more often and got confident about making bigger changes on the codebase. Now that I learned a bit about GitHub's etiquette rules and this kind of thing I also feel more comfortable contributing to other projects.

Maybe we, as open source maintainers, should start looking forward to help beginners start contributing and therefore have more people to maintain modules.

Thank you all for sharing your thoughts, you rock, buddies ❤️

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Nov 2, 2016

Contributor

@jdalton lol @ adobe illustrator support

Contributor

boneskull commented Nov 2, 2016

@jdalton lol @ adobe illustrator support

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton commented Nov 2, 2016

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Nov 2, 2016

Contributor

IMO, attracting new contributors is one of the maintainer's responsibilities. I see many new folks around trying to find a new project to contribute and none of them offers any help for beginners.

Agree. Reducing the effort necessary to contribute = more contributors. This is a known equation. 😄

Some part of me worries that more contributions will actually compound the problem. We get more PRs than we can review in a timely manner. If they land, who maintains that code?

I'm hesitant to say this, but I will: Mocha doesn't need more contributors. Mocha needs more maintainers.

Being a maintainer requires some level of dedication and commitment that's greater than a drive-by PR.

How do you convert a contributor to a maintainer?

Contributor

boneskull commented Nov 2, 2016

IMO, attracting new contributors is one of the maintainer's responsibilities. I see many new folks around trying to find a new project to contribute and none of them offers any help for beginners.

Agree. Reducing the effort necessary to contribute = more contributors. This is a known equation. 😄

Some part of me worries that more contributions will actually compound the problem. We get more PRs than we can review in a timely manner. If they land, who maintains that code?

I'm hesitant to say this, but I will: Mocha doesn't need more contributors. Mocha needs more maintainers.

Being a maintainer requires some level of dedication and commitment that's greater than a drive-by PR.

How do you convert a contributor to a maintainer?

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Nov 2, 2016

How do you convert a contributor to a maintainer?

For me, I just ask. I repo-sit other projects while primary maintainers are away and find folks that are active in issues and PRs and ask them if they'd like to be a maintainer. That way I can step away from repo-sitting and things are still handled.

jdalton commented Nov 2, 2016

How do you convert a contributor to a maintainer?

For me, I just ask. I repo-sit other projects while primary maintainers are away and find folks that are active in issues and PRs and ask them if they'd like to be a maintainer. That way I can step away from repo-sitting and things are still handled.

@lucasfcosta

This comment has been minimized.

Show comment
Hide comment
@lucasfcosta

lucasfcosta Nov 2, 2016

Member

@boneskull IMO the most important part is getting a contributor in the first place and then you make that contributor comfortable to send more and more pull-requests. This is achieved by mentoring that person and answering doubts about how the code works.
Also when you make the contribution experience something that gives pleasure to the one contributing, that person will certainly come back for more. This is what happened to me and I think this is what happened to @meeber, @vieiralucas and @shvaikalesh too (as you can see on this PR for example: #812).

Member

lucasfcosta commented Nov 2, 2016

@boneskull IMO the most important part is getting a contributor in the first place and then you make that contributor comfortable to send more and more pull-requests. This is achieved by mentoring that person and answering doubts about how the code works.
Also when you make the contribution experience something that gives pleasure to the one contributing, that person will certainly come back for more. This is what happened to me and I think this is what happened to @meeber, @vieiralucas and @shvaikalesh too (as you can see on this PR for example: #812).

@ScottFreeCode

This comment has been minimized.

Show comment
Hide comment
@ScottFreeCode

ScottFreeCode Nov 2, 2016

For what it's worth, my thoughts on this are:

  • Is it reasonable to separate what's officially supported from what may still work? E.g. to say "supports IE 9+ and Node 4.x+", but if it happens to be easy to keep working in IE 7 and Node 0.10 then so much the better, but if one day those stop working it's not officially a breaking change because they haven't officially been supported anyway?
  • I think we usually get Chai questions in Gitter; but in any case, it would be really cool to work out an easy process to help people find the right place to be asking or to report issues, given that Chai and Mocha are frequently used together. More collaboration! (Also, it'd be interesting to brainstorm ways that the underlying tools such as GitHub could make it easier; maybe we could open a feature request if we come up with any really good ideas.)
  • Over in Mocha, while I try to help out with issues and occassionally with code, I don't feel the kind of ownership where I'm comfortable making many decisions. It might help convert contributors to maintainers to have a slightly more formal process for things like getting X number of approvals for a proposed change (like some larger projects do) so that anyone who would like to help out more as a maintainer just has to know those processes (and, since we're not so large a project despite the non-trivialness of the current codebase, hopefully there wouldn't be much to it).
  • One thing that may be helped by dropping Node 0.10 is, if I'm not mistaken, that we could resolve the output cut-off issue (mochajs/mocha#2471 - but see also the PR, where it's confirmed to affect more than just help) without blocking output by using process.exitCode instead of process.exit() (although it would mean a bit of restructuring of the CLI to avoid running other stuff after the points where we would previously have called exit).

ScottFreeCode commented Nov 2, 2016

For what it's worth, my thoughts on this are:

  • Is it reasonable to separate what's officially supported from what may still work? E.g. to say "supports IE 9+ and Node 4.x+", but if it happens to be easy to keep working in IE 7 and Node 0.10 then so much the better, but if one day those stop working it's not officially a breaking change because they haven't officially been supported anyway?
  • I think we usually get Chai questions in Gitter; but in any case, it would be really cool to work out an easy process to help people find the right place to be asking or to report issues, given that Chai and Mocha are frequently used together. More collaboration! (Also, it'd be interesting to brainstorm ways that the underlying tools such as GitHub could make it easier; maybe we could open a feature request if we come up with any really good ideas.)
  • Over in Mocha, while I try to help out with issues and occassionally with code, I don't feel the kind of ownership where I'm comfortable making many decisions. It might help convert contributors to maintainers to have a slightly more formal process for things like getting X number of approvals for a proposed change (like some larger projects do) so that anyone who would like to help out more as a maintainer just has to know those processes (and, since we're not so large a project despite the non-trivialness of the current codebase, hopefully there wouldn't be much to it).
  • One thing that may be helped by dropping Node 0.10 is, if I'm not mistaken, that we could resolve the output cut-off issue (mochajs/mocha#2471 - but see also the PR, where it's confirmed to affect more than just help) without blocking output by using process.exitCode instead of process.exit() (although it would mean a bit of restructuring of the CLI to avoid running other stuff after the points where we would previously have called exit).
@keithamus

This comment has been minimized.

Show comment
Hide comment
@keithamus

keithamus Nov 3, 2016

Member

This is a great conversation everyone! Fun to see lots of maintainers having a good conversation about this. I don't have much more to add about the main point, because everyone has covered it so well so far! I will add this though, about the contributor/maintainer dynamic:

How do you convert a contributor to a maintainer?

@boneskull here at chai, we have a kind of unwritten rule: if we see a contributor pop up a few times; making a couple of nice PRs and maybe helping out in the issue tracker, we invite them to become maintainers.

We started this process this year, and we've since added over a half dozen or so new maintainers, across the chai organisation. Generally speaking everyone has taken their role as maintainer seriously, and made some excellent contributions to the projects. We certainly have a few maintainers who are fairly inactive (that's no problem though, they can help out where they can), and we have some very active ones (e.g. @meeber, @lucasfcosta, @vieiralucas and others).

I certainly some trepidation inviting a bunch of folk to come and maintain these projects; but I think once you start you soon realise if people are keen enough to join, they're keen enough to do the job well.

The question then becomes, I suppose, how do you get good contributors that you can convert into maintainers? (Personally) I try quite hard to avoid doing any actual work on chai's codebases and instead spend most of my time on the issue tracker; not because I'm lazy but because any work I do is taking away work for potential new contributors to do. Often times I'll end up describing exactly what needs doing to make a PR (an example here) - sometimes to the point where it would have been quicker for me to just code it. Sometimes I'll go and promote these issues in out-of-band channels like twitter or @yourfirstpr.

Once we get a contributor making a PR, I try to give them plenty of encouragement and good feedback, as well as lots of congratulations if the PR is merged, as well as a victory-lap of congratulations release PR (an example). If a contributors PR doesn't get merged I'll make a point of apologising and imploring the contributor to keep making good contributions (example 1, example 2). I think that taking the time to write responses in each of these scenarios makes quite a difference in the level of discourse, and the enthusiasm of contributors we have (I have experience on maintaining other projects where this isn't the case and the difference is noticeable).

So yeah, I guess ultimately that's a long winded way to say, I guess my role in Chai is more like a coach than a contributor - and I think that has helped us get some great new contributors. If you're looking for a recipe to replicate for Mocha, to try and get some more contribs, I would say we have had success here, doing it this way, so try it!

Member

keithamus commented Nov 3, 2016

This is a great conversation everyone! Fun to see lots of maintainers having a good conversation about this. I don't have much more to add about the main point, because everyone has covered it so well so far! I will add this though, about the contributor/maintainer dynamic:

How do you convert a contributor to a maintainer?

@boneskull here at chai, we have a kind of unwritten rule: if we see a contributor pop up a few times; making a couple of nice PRs and maybe helping out in the issue tracker, we invite them to become maintainers.

We started this process this year, and we've since added over a half dozen or so new maintainers, across the chai organisation. Generally speaking everyone has taken their role as maintainer seriously, and made some excellent contributions to the projects. We certainly have a few maintainers who are fairly inactive (that's no problem though, they can help out where they can), and we have some very active ones (e.g. @meeber, @lucasfcosta, @vieiralucas and others).

I certainly some trepidation inviting a bunch of folk to come and maintain these projects; but I think once you start you soon realise if people are keen enough to join, they're keen enough to do the job well.

The question then becomes, I suppose, how do you get good contributors that you can convert into maintainers? (Personally) I try quite hard to avoid doing any actual work on chai's codebases and instead spend most of my time on the issue tracker; not because I'm lazy but because any work I do is taking away work for potential new contributors to do. Often times I'll end up describing exactly what needs doing to make a PR (an example here) - sometimes to the point where it would have been quicker for me to just code it. Sometimes I'll go and promote these issues in out-of-band channels like twitter or @yourfirstpr.

Once we get a contributor making a PR, I try to give them plenty of encouragement and good feedback, as well as lots of congratulations if the PR is merged, as well as a victory-lap of congratulations release PR (an example). If a contributors PR doesn't get merged I'll make a point of apologising and imploring the contributor to keep making good contributions (example 1, example 2). I think that taking the time to write responses in each of these scenarios makes quite a difference in the level of discourse, and the enthusiasm of contributors we have (I have experience on maintaining other projects where this isn't the case and the difference is noticeable).

So yeah, I guess ultimately that's a long winded way to say, I guess my role in Chai is more like a coach than a contributor - and I think that has helped us get some great new contributors. If you're looking for a recipe to replicate for Mocha, to try and get some more contribs, I would say we have had success here, doing it this way, so try it!

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Oct 2, 2017

Contributor

FWIW, Mocha will drop support in v4 (hopefully tomorrow). changelog

Contributor

boneskull commented Oct 2, 2017

FWIW, Mocha will drop support in v4 (hopefully tomorrow). changelog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment