-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add next examples that discourages to contributions #19
Add next examples that discourages to contributions #19
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although I'm afraid it's too generic to be a red flag, these are good points.
And I remember the experience we collaborate at apache/maven-shade-plugin#150 and how I refer it many times to show as a good example.
@@ -20,6 +20,9 @@ not a policeman enforcing the rules. | |||
* Discussions are happening off-list. | |||
* Too much talk is happening on the private list. | |||
* Users' questions are going unanswered on the mailing list. | |||
* Users' reported issues are going uncommented and untouched. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on all of these. I think one of the big advisors roles might be to help to figure out how to deal with those oat different stages of the priojects (and here I see great opportunity to exchange learnings between projects - and advisors talking between themselves about some ideas to improve.
For me - for example it was eye-opening that those do not have to be committers to respond - and finding ways to encourage users/contributors to respond to each other and review each other's code - also as a way to become a committer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In PMCs like Maven we have many projects which are different and many times to do a PR review, comment issues deeper knowledge is needed in a specific project ... but not all commiters good know all projects and so on ...
So helping from contributors can be very valuable.
It can be very interesting how others projects deal with such cases ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example from Airflow: We are using "collaborators" for that (AKA triage team) where we ask and encourage people to become members of the team and help to triage the issues/PR, we actively "recruit" people to the team (often those people become committers or stop being active so it's natural but also from time to time we have a "call for collaborators" - which reminds people that there is something like "collaborators" and why.
But it's far from perfect I would love to know how others are doing it :D
I think one of the good things - assuming we will have a number of advisors advising a number of projects - those might be a great subject to discuss - how PMCs are dealing with those? how they dealt with it when things became too overwhelming? How they engaged wider community. I think |
Inspiring by this simple discussion, I'm taking to try to activate more contributors https://lists.apache.org/thread/y1b0x39g3xkh45klmv9ndfj1czcrx4zb we will see what happens 😄 |
Cool. For testing the RC - what works for us perfectly is that when we send an RC we generate this kind of issue: apache/airflow#37648 , apache/airflow#37617 - all the contributors who contributed to the release candidate are |
I think such issues related to approving PR and finally prepare next release with accepted contributions can have impact for new contributions.