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.

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

PROCESS CHANGE: New Contributor Guideline #1475

Open
Leo6Leo opened this issue Dec 7, 2023 · 3 comments
Open

PROCESS CHANGE: New Contributor Guideline #1475

Leo6Leo opened this issue Dec 7, 2023 · 3 comments

Comments

@Leo6Leo
Copy link
Member

Leo6Leo commented Dec 7, 2023

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:

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

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

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

@creydr @Cali0707 @pierDipi @aliok

@aliok
Copy link
Member

aliok commented Dec 11, 2023

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

@aliok
Copy link
Member

aliok commented Dec 11, 2023

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

@Leo6Leo
Copy link
Member Author

Leo6Leo commented Dec 11, 2023

@aliok Thanks Ali for the reply! I will take on action items on this, and reported the updates here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants