You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In today's SSC meeting, we discussed whether the expectation that all SSC members should vote on all JEPs is too high to be realistic.
Particularly, if the JEP covers an area of the Jupyter ecosystem that a member doesn't know very well, there would be much more required of that person than simply reviewing the JEP. They would also need to catch up on all the background/tech/etc. to offer critical feedback on the JEP. I believe this is too much to ask of folks volunteering for the SSC; further, I think there is a better/more efficient way to go about this.
Based on ideas proposed by @willingc from the PEP process, a few of us brainstormed a new approach. I'll summarize it here:
When a JEP is reaching the end of its RFC phase and trending towards a positive final state, one (or more) member of the SSC commits to writing a statement of recommendation for the rest of the SSC. That statement should include a few sentences summarizing the changes, their impact on the community, and final sentence recommending the JEP for approval.
This might unblock folks with less background on the particular JEP topic when voting on a JEP—they don't need to dive into the nitty-gritty because they can lean on their trust of the individuals who reviewed it more closely.
I'd like to formalize this into documentation here, so I'm opening this issue to get feedback before submitting a PR to our process.
tl;dr
To motivate this, I'll share a personal example.
There are multiple JEPs currently open around the notebook format. I'm very familiar with the current notebook format and its weaknesses, but I do not work on software that touches the format. So, I cannot speak to impact/consequences of changing the format—I just don't have experience of someone who might be deeply affected by these proposals.
Instead, I lean on the expertise of the people in this council that do feel the impact of these changes. I'm in support of the PR as long as they sign-off on it.
I think this feeling is shared by others on the council as well. We understand and approve of PRs, as long as those with more expertise approve. Using the "recommendation statement" above might help make this explicit.
The text was updated successfully, but these errors were encountered:
I support this proposal. And I would like to add that voting is a three states choice. If a member does not feel comfortable sanctioning a JEP, abstain is a good vote (I did it in the past).
This proposal should mitigate the risk of having too many abstain votes such that the quorum is not reached.
In today's SSC meeting, we discussed whether the expectation that all SSC members should vote on all JEPs is too high to be realistic.
Particularly, if the JEP covers an area of the Jupyter ecosystem that a member doesn't know very well, there would be much more required of that person than simply reviewing the JEP. They would also need to catch up on all the background/tech/etc. to offer critical feedback on the JEP. I believe this is too much to ask of folks volunteering for the SSC; further, I think there is a better/more efficient way to go about this.
Based on ideas proposed by @willingc from the PEP process, a few of us brainstormed a new approach. I'll summarize it here:
When a JEP is reaching the end of its RFC phase and trending towards a positive final state, one (or more) member of the SSC commits to writing a statement of recommendation for the rest of the SSC. That statement should include a few sentences summarizing the changes, their impact on the community, and final sentence recommending the JEP for approval.
This might unblock folks with less background on the particular JEP topic when voting on a JEP—they don't need to dive into the nitty-gritty because they can lean on their trust of the individuals who reviewed it more closely.
I'd like to formalize this into documentation here, so I'm opening this issue to get feedback before submitting a PR to our process.
tl;dr
To motivate this, I'll share a personal example.
There are multiple JEPs currently open around the notebook format. I'm very familiar with the current notebook format and its weaknesses, but I do not work on software that touches the format. So, I cannot speak to impact/consequences of changing the format—I just don't have experience of someone who might be deeply affected by these proposals.
Instead, I lean on the expertise of the people in this council that do feel the impact of these changes. I'm in support of the PR as long as they sign-off on it.
I think this feeling is shared by others on the council as well. We understand and approve of PRs, as long as those with more expertise approve. Using the "recommendation statement" above might help make this explicit.
The text was updated successfully, but these errors were encountered: