...
Maintainers should have accounts on Discourse and receive some subset of notifications.
This must include direct mentions on posts and replies to posts made. Note that this is the default notification setting on Discourse:
It is recommended that maintainers include notifications on first posts in categories of interest, done by navigating to the topic, clicking the “bell” icon next to the New Topic button, and selecting “Watching First Post”.
Maintainers should check notifications weekly.
To avoid feeling overwhelmed, consider having notifications skip your inbox and go directly into a folder. Check these once a week on a regular cadence - consider putting 15 minutes on your calendar once or twice a week.
Note: when posting a new discussion topic, it is recommended you check at least daily - discussions around things like Deprecations and new Architecture will proceed better with involved discussion.
Maintainers do not need to jump into every “help me” issue, but should answer pointed/strategic questions such as ones related to timelines, deprecations, and roadmaps.
...
Check new issues at least once per sprint, and consider weekly.
“Ack” issues that are real, even if it’s with something like “This appears to be a real issue; we will not have time to work on this in the foreseeable future” to keep the project inclusive and let watchers know where you’re at.
Redirect as needed: perhaps “help” issues should be redirected to Discourse, for example, if that’s your project’s policyGitHub issues are only for, well, issues. Help requests should be posted in the Open edX Discussion Forums. This is a project-wide standard.
For what it’s worth, Tutor has this policy and enforces it. Its Issues are reserved for, well, issues.
Learn to say No. This is the hardest thing to do, but please do it. Excerpts from the linked doc:
“If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.”
“Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.”
“If you don't want to accept a contribution:
“Thank them for their contribution
“Explain why it doesn't fit into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.
“Link to relevant documentation, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.
“Close the request”
Note in the doc, the author suggests the above steps can be done in just 1-2 sentences, especially if you can point to docs/ADRs/OEPs that give detail on why the submission isn’t being accepted.
Audit old issues once per sprint to see if any updates can be given. Consider a policy of closing stale issues (ones where maintainers are waiting on authors to provide more input, and the author has not responded). Rails gives 2 weeks before closing these issues; I would not recommend less than 2 weeks, and might advocate for a looser policy around common holiday times (July & December/January)
...
A new PR should be triaged within a week. During triage, a decision must be made as to whether or not the project wants is interested the PR, and it must be closed within this period if the project does not want it. Remember: Learn to say no
...