Spoke Core Contributors meta issue

Created on 18 Aug 2019  Â·  15Comments  Â·  Source: MoveOnOrg/Spoke

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 will not merge to main
  • I will not merge to stage-main
  • I will not use labels: “testing on stage”, “testing in production” related to mergability
  • I have read and affirm the code of conduct
  • If I break code of conduct, or break any of the other agreements, I understand that I might lose Core Contributor status
C-meta

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:

  1. Part of being a core-contributor is that you’re automatically added to the list of reviewers (which you can then opt out of)
  2. If you’d like, you can make a PR to the config file and add yourself to the list of contributors
  3. No auto-assigning at all.

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!

All 15 comments

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:

  1. Part of being a core-contributor is that you’re automatically added to the list of reviewers (which you can then opt out of)
  2. If you’d like, you can make a PR to the config file and add yourself to the list of contributors
  3. No auto-assigning at all.

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!

Was this page helpful?
0 / 5 - 0 ratings