Skip to content
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

Use a "recommendation" statement to transition from RFC to voting #113

Open
Zsailer opened this issue Jun 12, 2023 · 2 comments
Open

Use a "recommendation" statement to transition from RFC to voting #113

Zsailer opened this issue Jun 12, 2023 · 2 comments

Comments

@Zsailer
Copy link
Member

Zsailer commented Jun 12, 2023

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.

@fcollonval
Copy link
Contributor

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.

@JohanMabille
Copy link
Member

I support this proposal too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants