Opensource.guide: [RFC] Sustaining Growth > Best Practices for Maintainers

[nayafia]

Hey open source maintainers! We would love your feedback on the Sustaining Growth > Best Practices for Maintainers article. We will leave this open for comments until Sep 1, 2016.

Does anything seem inconsistent with your experience? What is missing? Are there any other helpful resources on this topic?

Feel free to comment and discuss here, or even open a pull request to suggest changes.

View | Edit

[MikeMcQuaid]

Your happiness and health are the most important requirements of open source work. Without them, nothing else matters.

This feels like a bit of a philosophical statement rather than a practical one (although I admire the intent). What about something like "The happiness and health of maintainers are a non-negotiable requirement of the survival of any open-source project."

[MikeMcQuaid]

Otherwise: great 👍

[jessfraz]

Might be cool to have a section about defining goals if other people want to become maintainers of the project. Unsure if this is mentioned elsewhere but it's a great way for people to have explicit ways to move up the ladder if they wish and also takes a huge amount of effort off maintainers when the work is distributed.

[nayafia]

Maybe include a line about recent email filters in the "automate your work" section? https://github.com/blog/2203-email-updates-about-your-own-activity

[gr2m]

I’d mention semantic-release next to Greenkeeper. The latter automates dependency updates, the former automates the release of your project. It makes my life as maintainer so much easier, because all I do is merge a pull request and a new version gets released minutes later, automatically. This is particularly important as people who send pull requests are not only waiting for the pull request to be merged, but also released, so that they can use it in their apps / libraries. Both is relevant for projects using npm only.

[joshsimmons]

One challenge potential contributors face is fragmentation in the process -- it can vary wildly between projects. With that in mind, I'd recommend readers look at the contribution process for similar or adjacent projects. EG: What does the contribution process look like for most Node modules? What tools or communication tools do they use?

That, paired with the well defined needs/limits you encourage readers to outline, gives someone a great starting point from which to define the process and select tools that will (1) meet their needs and (2) be familiar to potential contributors.

[nayafia]

Closed per #98.

[pdurbin]

What tools or communication tools do they use?

@joshsimmons this is a good question to raise, especially as we are seeing a change over time in terms of communication tools. From my perspective, there used to be a project-users mailing list and a project-dev mailing list, and perhaps a project-announce mailing list. These days there are a multitude of communication options beyond mailing lists. I sort of wonder if projects could have a COMMUNICATION.md file that explains the various communication methods used by the project and provides some minimal guidance on using them.