Skip to content
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.

Sign up for GitHub

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

sustaining/best-practices: some small ideas & additions #61

Merged
merged 1 commit into from
Sep 6, 2016
Merged

sustaining/best-practices: some small ideas & additions #61

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions sustaining/best-practices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,10 @@ Saying no applies to many situations you'll come across as a maintainer. You can

One of the most important places you'll practice saying no is on your issue and pull request queue. If someone suggests an idea that you know you won't accept, don't leave it open because you feel guilty or want to be nice. Be kind, but firm. Thank them for their contribution and explain why it doesn't fit into the scope of the project. Then close the request.

If you notice repeated requests for things you don't want to accept, consider adding them into your contribution policy, so you don't have to keep repeating yourself.
Defining your project's scope makes closing pull requests that have "scope
creep" easier. If you notice repeated requests for things you don't want to
accept, consider adding them into your contribution policy or modifying your
project's scope, so you don't have to keep repeating yourself.

If the thought of saying no terrifies you, you're not alone. As @jfrazelle put it: _"I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want."_ [^3] But the more often you practice saying no, the easier it becomes. Promise.

Expand All @@ -63,7 +66,7 @@ If the thought of saying no terrifies you, you're not alone. As @jfrazelle put i

Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.

It's tempting to respond to private communication, especially early in the life of a project. Resist the temptation. Keeping communication public means less work for you personally. It also opens up opportunities for other people to learn and participate.
It's tempting to respond to private communication, especially early in the life of a project. Resist the temptation. Keeping communication public means less work for you personally. It also opens up opportunities for other people to learn and participate. When the communication is public it means other people with the same question or problem can easily find the answer without having to ask again.

Notable exceptions to this practice are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these types of issues privately. If you don't want to use your personal communication channels, set up a separate email address for this purpose.

Expand Down