JupyterLab Council voting timeframe

[afshin]

Question

Is a seven-day voting period long enough for the JupyterLab Council?

Context

The relevant section of the Decision-Making Guide that lays out the procedure for calling a vote states:

Calling a vote. When the discussion matures during the consensus-seeking phase, any member of the council can call the matter to a vote. When that member (the sponsor) calls the vote, they shall summarize the proposal in its current form for the entire council. After the proposal is seconded by another member of the council, members have seven days to vote. The council may consider longer voting periods as necessary for special circumstances, or shorter periods only if all voting members are present. The decision will be determined by a simple majority of non-blank votes for binary decisions (i.e., approving a proposal) and ranked choice for multi-class decisions (one among many, or several among many). The sponsor may update the proposal at any point during the voting period, in which case the voting period will be reset.

Potential answers to the question

Option 0

We change nothing and believe that a 7-day voting period is sufficient for the JupyterLab Council.

---

Option 0_ɑ

@jasongrout proposes a compromise below:

[A] 7-day normal voting period, with the caveat that it can be easily and automatically extended to 14 days with a motion and a second in comments on the vote.

---

Option 1

The JupyterLab Council chooses to "consider longer voting periods as necessary for special circumstances". It's not explicit what a special circumstance is, but perhaps we might say that since the JupyterLab Subproject is larger than most of the other voting bodies, this is a special circumstance.

---

Option 2

We amend the Decision-Making Guide, but that would affect all other voting bodies. It would also require a vote of the current Jupyter Steering Council or if the SC has disbanded by the time we open a PR in the jupyter/governance repository, it would require a vote of the Executive Council + Software Steering Council.

---

Let's discuss in this thread and during tomorrow's (20 July 2022) JupyterLab weekly meeting (Zoom link) at 16:00 UTC.

• If we decide to go with Option 0, we can close this issue.
• If we decide to go with Option 1 above, we can discuss a suitable voting period. If we arrive at consensus, we can update our team-compass. If we need to vote, we can call a vote.
• If we decide to go with Option 2 above, we can open a PR in the jupyter/governance repository.

CC: @jupyterlab/jupyterlab-council,
@jasongrout, @damianavila have both asked about this issue.

[JohanMabille]

I think a seven-day voting period is enough, even is the project is larger than the other ones. Getting the context and the different discussions relative to a vote should not take that long for people working on the project on a daily basis; the main reason I see for extending this voting period is when people are unavailable because of holidays or conferences, and I think that falls in the "special circumstances" field which does not need a more explicit specification.

[jasongrout]

Thank you very much @afshin for opening this.

I advocate for a 14-day period for JupyterLab because it has become a large complex project with many working pieces and many areas of specialization. I think this is basically option 2 in Darian's choices. Some of the reasoning below would support option 3 as well, but I also think it's important to not be too prescriptive for subprojects.

For me, I often have a week's worth of work mapped out to do. If a vote comes up in an area of the project that I have not been following as closely, it is much harder to work time for context research and evaluation into the schedule (or weekend!) with only 7 days notice. Even for those that do work on the project regularly, disruptions in schedules often are several days to a week, like a conference or time off work (both of which happened for me in this last vote). 14 days is much more accommodating for preexisting plans and schedule disruptions than 7 days.

Further, I strongly believe we should not tailor our decision making process around people that have the luxury of working on the project every day, but that we should be inclusive of the "weekend contributor" who works on open source in their spare time. Two weekends in a vote is much more accommodating than just one for such contributors.

[fcollonval]

I was about to say 7-days is good. But @jasongrout is making a good point. So 2 weeks sounds better.

[ellisonbg]

Thanks for bringing this up, I wouldn't be surprised if we need to tune things about the new governance model over time. I think there are a couple of reasons where a longer voting period might make sense: * In some decisions, we may find that there is a lot more discussion that happens after a vote is called. In this case, I think it is reasonable to apply the "consider longer voting periods as necessary for special circumstances". I am fine with us formalizing how that gets triggered for a vote in JupyterLab. For example, we could say that any council member can motion to extend a vote for another 7 days (a single extension) and that as long as that motion is seconded, it immediately goes into effect. That way, we avoid the awkward "let's conduct a vote to extend the voting period of another vote." * People are generally busy. While I certainly agree that Jupyter contributors - full time and occasional - are very busy, I don't believe that in most situations longer voting periods solve that problem. Speaking personally now, I know that if I can't find the time to understand an issue and vote in 7 days, I am equally unlikely to be able to do that in 14 days. One of the primary reasons we set the voting period to 7 days was that we wanted voting to be an effective method of accelerating decisions that are moving slowly. I believe that making all votes 14 days will significant reduce the velocity of our decision making. * Someone who wants to participate in a particular vote has a specific conflict (vacation, work deadline, etc.). Again, I believe this would be best handled by the "consider longer voting periods as necessary for special circumstances" clause by extending just that vote. If we really want to pursue option 2 (change the Jupyter-wide) voting period, I would be much more inclined if we were moving up to 10 days rather than 2 weeks (I think the point about 2 weekends was a good one).

…

On Tue, Jul 19, 2022 at 8:19 AM Frédéric Collonval ***@***.***> wrote: I was about to say 7-days is good. But @jasongrout <https://github.com/jasongrout> is making a good point. So 2 weeks sounds better. — Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUEQW3YIMFMASM7ZQ5LVU3BPHANCNFSM537S4XIA> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

-- Brian E. Granger Senior Principal Technologist, AWS AI/ML ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[JasonWeill]

@afshin I'm a member of the JupyterLab council, but not of @jupyterlab/jupyterlab-council, so I didn't get a ping about this issue. Can you please add me to the team?

[fcollonval]

@afshin I'm a member of the JupyterLab council, but not of @jupyterlab/jupyterlab-council, so I didn't get a ping about this issue. Can you please add me to the team?

@jweill-aws I just added you - let's know if you did not get the invitation

[jasongrout]

Thanks Brian, I like your compromise. I support option 2, with 10 days (including 2 weekends) for regular votes with the caveat that it is easy to extend to 14 days with a motion and second.

[jasongrout]

After further discussion in the governance meeting today, in order to preserve the norm encouraging more nimble voting, I support a simpler version of Brian's compromise: a 7-day normal voting period, with the caveat that it can be easily and automatically extended to 14 days with a motion and a second in comments on the vote.

[afshin]

I added Jason's proposal as Option 0_ɑ in the top-level comment. I support this option and think it is a good answer to the question.

[damianavila]

I added Jason's proposal as Option 0ɑ in the top-level comment. I support this option and think it is a good answer to the question.

I think it is a good enough compromise.

[isabela-pf]

I also agree with Option 0ɑ. It seems like a good compromise that also leaves open opportunity for us to reassess if we continue to get feedback from future votes.

Further, I strongly believe we should not tailor our decision making process around people that have the luxury of working on the project every day

I also deeply agree with this comment. That was one of my concerns with the original timeline as well.