language about voting phases and a PR template #82
Conversation
choldgraf
force-pushed
the
vote_phases
branch
2 times, most recently
from
e163cba
to
38108db
Compare
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
|
I think this is great text now, and would be happy with it moving to the voting stage. I did suggest one more re-wrapping of lines (purely a whitespace change). Thanks again @choldgraf! |
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
|
I agree that it looks ready for voting, but I say we give it until 24 hrs from opening. |
|
OK all - I think this is ready for a vote - happy to answer people's questions if they have them! |
|
Hey all - just a note that we are 20 days into the 4 week window. If you'd like to vote (particularly if you are |
|
Thanks for the additional nudge, Chris, this one made it through the notification maelstrom. I suspect that the reason for a lack of participation and voting on this PR at the moment stems from the fact that this proposal wasn't announced on the jupyter-steering list, so I just went ahead an corrected that. Hopefully more folks show up soon. |
|
Ah gotcha - thanks @ivanov ! In the future, is there a place that people not on the SC should send PRs like this? I don't believe that I am able to send emails to the SC listserv (?) so I don't really know how to get in touch w/ it. |
|
@choldgraf - I think you sent the PR to the right place. Anyone can send emails to the SC list - they just get held for moderation, but that's more of an implementation detail on our side. I would think that the SC members pitching in would be the ones to raise visibility of this kind of stuff on the SC list. I also see that you can request reviews on GitHub - that might be another way, but that's limited to 15 people, and SC is two bigger than that at the moment. |
ivanov
requested review from
fperez,
minrk,
mpacer,
Ruv7,
SylvainCorlay and
takluyver
|
I just added a request for reviews from the folks who haven't voted yet. |
|
Test ping: @jupyter/steeringcouncil |
|
If someone else confirms that the ping worked (maybe because I generated it I don't get an email), we can make that part of the checklist. |
|
@blink1073 - can confirm that this ping showed up in my GitHub notifications. |
|
@choldgraf do you think we should add language here about pinging that group to "start the voting process" or save it for a follow up PR? |
|
For the record, we now have 12 YES, 0 NO, and 0 abstains. |
In the spirit of this PR itself, I think we should save for a follow-up PR (i.e., once a PR is voted on, it should not change) |
|
yeah - I agree that it's a good idea to add language about how and when the steering council should be notified - but we'd need to restart the voting process if we did that. |
|
I agree with @jasongrout; I think merging and iterating is better than resetting the vote. |
|
Let's get this merged and open a separate PR for notification process. |
Four weeks of open voting end tomorrow; this PR meets the criteria for passing "early" as of two days ago. Thanks @choldgraf! |
|
yay! 🎉 |
Background or context to help other understand the change.
In a recent proposed change, an issue arose where discussion and edits to the PR happened after some people had already voted. This brought up two challenges:
This PR tries to improve upon both of these issues with a slight modification to the voting process. It follows two main principles:
A brief summary of the change
This proposal adds a discussion phase to the voting process. During the discussion phase, the PR is in a draft state and feedback, iteration, and edits are encouraged.
The PR author can call a vote at any point, at which point the PR leaves "draft" phase and enters the "active" state. At this point, no edits are allowed to the PR, and input from the SC is encouraged to be in the form of voting rather than lengthy discussion.
This proposal also adds a pull-request template with language to try and encourage positive and productive voting.
What is the reason for this change?
The aim is to make it clearer what SC members are voting on when a vote is called, and to increase the efficiency of the voting process.
Alternatives to making this change and other considerations.
We could continue in our current voting procedure, which isn't terribly broken, but does result in confusion like the link I shared above. We could also adopt a more technically-restrictive solution, like requiring that PR authors include a commit hash with the top-level comment, but I worry that this is complex enough that it won't be followed (in fact, it has not been followed in recent PRs to the repo). This PR uses GitHub's interface to trigger a vote, which I think is a bit more natural and low-barrier to remember.
Note: Even though this PR is not yet merged, I'd like to follow the proposed process for this PR as much as possible. I'll open the PR in a draft state, and I welcome feedback, comments, edits, etc.
cc @afshin @jasongrout @tgeorgeux and @sharanf who were in earlier discussions about this
Votes