Closed isabela-pf closed 1 year ago
Thanks @isabela-pf I support this proposal. Lots of Jupyter projects have done so. And this is a great way for members to increase their involvement if they are interested.
i think that this makes sense. thanks for raising the issue.
the accessibility to burnout pipeline is real. terms would allows members to check if they are properly resourced and supported to continue serving these roles.
I am +1 on this proposal
Thank you all for commenting!
Given that there hasn't been any reason mentioned to not hold a vote and that voting will be an expression of opinion anyways, I'll set up a vote. I will report the results back on this issue and close it once the vote is completed.
The voting period for this proposal has closed!
With a voting body of 10 council members, the quorum of 50% is met and the proposal passes.
Thank you all for your time. I will be looking into what document/documentation changes need to be made to update this change then.
Background
In the current Jupyter governance model, Jupyter Accessibility is a software subproject. As a software subproject, we elect a council member to represent us on the Jupyter Software Steering Council (SSC). At the time of writing, I am that representative.
While we have a process for this election, the accessibility project has not previously made a formal decision related to term length or representative election timelines. The Jupyter Software Subproject documentation currently leaves this decision up to the software subprojects themselves.
Proposal
I propose we set the term length for accessibility subproject SSC representatives to be a year. This would require annual elections. I am not proposing any caps on the number of terms or consecutive terms at this time.
I'd like to bring this to a vote, but I want to make sure I leave time for discussion outside meeting times as well. I will follow up in a week to see what next steps are relevant.
Actions needed
Thank you for your time and thoughts!
cc: @jupyter/accessibility-council