PROCESS CHANGE: New Contributor Guideline
Leo6Leo opened this issue · comments
In the Knative Eventing community, we've been thrilled to see a surge in active contributions from new members. This influx of enthusiasm is a positive sign of growth. However, it has also brought to light certain challenges.
A persistent challenge we face involves new contributors who ambitiously take on several issues at once (typically two or more) but subsequently become inactive, often without communication for extended periods. This pattern not only delays progress on these issues but also places an undue burden on our maintainers. Our maintainers are tasked with overseeing progress and ensuring project momentum, and such unresponsiveness disrupts these efforts. Currently, our approach to address this involves sending follow-up messages to these contributors, requesting updates. In cases where no response is received, our next step is to unassign them from the issue. This process, while necessary, adds to the workload of our maintainers, underscoring the need for a more effective solution.
Take Knative Eventing as an example:
Right now in the contribution.md, there is nothing to tell the contributors how to contribute and any "rules" that we have.
During a recent Eventing Working Group meeting, we discussed how to address this dilemma more effectively. Key suggestions included:
-
Issue Assignment Limit: Set a cap on the number of issues a new contributor can assign to themselves at a time. For example, limit new contributors to a certain number of issues at a time. This can be measured by the submission of pull requests (PRs). For instance, once a contributor has submitted a PR for one of their assigned issues, they are allowed to take on an additional issue.
-
Documentation : Clearly document these guidelines in our 'contribution.md' file and in the existing "Getting Started in Open Source with Knative" blog post by Calum and Leo.
-
Communication: If a contributor has an issue assigned but has not made visible progress (like commenting, discussing, or submitting a PR) for more than a certain number of weeks, send reminders or check-in messages. If still not hearing back from them 1 week after check-in message, they will be unassigned from the issue.
We are open to discussion and hope to get more insight from the TOC and community to find a better way to accommodate this.
Thanks @Leo6Leo for the initiative! Really appreciated!
Issue Assignment Limit: Set a cap on the number of issues a new contributor can assign to themselves at a time. For example, limit new contributors to a certain number of issues at a time. This can be measured by the submission of pull requests (PRs). For instance, once a contributor has submitted a PR for one of their assigned issues, they are allowed to take on an additional issue.
Do you know if there are any communities who do this? Can we leverage their rules / tooling / workflow?
Documentation : Clearly document these guidelines in our 'contribution.md' file and in the existing "Getting Started in Open Source with Knative" blog post by Calum and Leo.
+1
Communication: If a contributor has an issue assigned but has not made visible progress (like commenting, discussing, or submitting a PR) for more than a certain number of weeks, send reminders or check-in messages. If still not hearing back from them 1 week after check-in message, they will be unassigned from the issue.
Same as the "issue assignment limit".
I think it all sounds good, but to materialize, we need to think about the implementation details.
BTW, term here is "Cookie Licking" (learnt thanks to @jberkus): https://www.redhat.com/en/blog/dont-lick-cookie
I don't have time to work on this myself, but I would do is
- Make some research around how to implement such rules for (1) and (3)
- Create a Google doc for the proposal (with my own judgement and suggestions) and open it up in a TOC+SC meeting to discuss and encourage feedback