This meta issue forms the agreement for folks who meet the criteria to become a member of the Spoke Core Contributors Group to affirm before getting access to the group.
As a Spoke core contributor, I agree to the following:
I agree!
🎉
I agree!!
I agree. Also would be good to clarify what contributors can do, not just what we can't :) . cc: @deasterdaywfp @lperson @bdatkins
Couldn't agree more!
On Wed, Aug 21, 2019, 12:37 PM Joe McLaughlin notifications@github.com
wrote:
I agree, though want to tweak the Code of Conduct somewhat. Also would be
good to clarify what contributors can do, not just what we can't :) .
cc: @deasterdaywfp https://github.com/deasterdaywfp @lperson
https://github.com/lperson @bdatkins https://github.com/bdatkins—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MoveOnOrg/Spoke/issues/1205?email_source=notifications&email_token=AIQWPSWI53BXRMRUQ6CXXPDQFVVLDA5CNFSM4IMT365KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD42JMEQ#issuecomment-523539986,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIQWPSST4F7SIBAM7PW427DQFVVLDANCNFSM4IMT365A
.
@lperson pls take a look at ^^^ and if you're good, would love to get you in as a Contributor here, "officially" :) .
Hey everyone! I'm interested in starting an auto-assign rotation for pull requests to make reviewing PRs move a bit faster and also create a real and sustainable review culture that helps keep code quality high. This would also help a lot with our ability to bring in new folks because fast review turnaround dramatically increases contributor rate of return.
The way this would work, is that we'd implement this bot that auto-assigns a reviewer to a PR and then some (or all) of us would be in the rotation of reviewers with the ability to opt out. If we were on vacation or away from the project for any reason, I'd build a feature for this bot to allow us to not be included in the rotation for that period of time
In preparation, I've written up a doc that is included in the next merge round on how to code review.
I could see 3 options here:
For option 1, react to this with 🎉
For option 2, react with 👍
For option 3, react with 👎
And if you have any thoughts or questions, share them here!
@joemcl @azuzunaga @filafb
Option 1 is the way to go, but not sure how much work it means. We can definitely start there, but review it after a few months or so.
@ibrand I voted for 1, but need a way for the randomly-assigned person to add in/recruit other reviewers if the randomly assigned person (say, me) does not feel competent to review the code in the PR but thinks another person is. Also I'd like a way to be able to ask folks like @bchrobot @harpojaeger etc to be able to review PRs here even if they haven't yet signed up per above.
@joemcl I did some reading about this and it looks like only folks explicitly added with read access can be assigned PRs. I'm going to add a handful of folks right now with read access so that you can re-assign PRs that get assigned to you to someone appropriate. That said, if you don't feel qualified to review PRs more generally, option 1 does allow you to opt out of being in the review cycle!
I agree to the terms and I opt in.
I agree and I'm in!
I agree to these terms and opt in.
I agree!
I agree! And I'm in!
Most helpful comment
Hey everyone! I'm interested in starting an auto-assign rotation for pull requests to make reviewing PRs move a bit faster and also create a real and sustainable review culture that helps keep code quality high. This would also help a lot with our ability to bring in new folks because fast review turnaround dramatically increases contributor rate of return.
The way this would work, is that we'd implement this bot that auto-assigns a reviewer to a PR and then some (or all) of us would be in the rotation of reviewers with the ability to opt out. If we were on vacation or away from the project for any reason, I'd build a feature for this bot to allow us to not be included in the rotation for that period of time
In preparation, I've written up a doc that is included in the next merge round on how to code review.
I could see 3 options here:
For option 1, react to this with 🎉
For option 2, react with 👍
For option 3, react with 👎
And if you have any thoughts or questions, share them here!