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

[RFC] Sustaining Growth > Best Practices for Maintainers #54

Closed
nayafia opened this Issue Aug 18, 2016 · 8 comments

Comments

Projects
None yet
6 participants
@nayafia
Contributor

nayafia commented Aug 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Aug 19, 2016

Collaborator

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

Collaborator

MikeMcQuaid commented Aug 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Aug 19, 2016

Collaborator

Otherwise: great 👍

Collaborator

MikeMcQuaid commented Aug 19, 2016

Otherwise: great 👍

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Aug 19, 2016

Collaborator

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.

Collaborator

jessfraz commented Aug 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nayafia

nayafia Aug 22, 2016

Contributor

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

Contributor

nayafia commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gr2m

gr2m Aug 22, 2016

Contributor

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.

Contributor

gr2m commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@joshsimmons

joshsimmons Aug 29, 2016

Collaborator

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.

Collaborator

joshsimmons commented Aug 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nayafia

nayafia Sep 2, 2016

Contributor

Closed per #98.

Contributor

nayafia commented Sep 2, 2016

Closed per #98.

@pdurbin

This comment has been minimized.

Show comment
Hide comment
@pdurbin

pdurbin Apr 13, 2017

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.

pdurbin commented Apr 13, 2017

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.

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