SLEP019: Governance Update - Recognizing Contributions Beyond Code (version II) #81
Conversation
slep019/proposal.rst
Outdated
| At this aim, the Technical Committee is renamed as Steering Committee, opening the | ||
| decision process to new to be defined core roles. | ||
| New core roles are allowed to be defined without requiring new SLEPs, to ease subsequent | ||
| related changes to the Governance. |
There was a problem hiding this comment.
I think it would be good to describe what the process is going to be like. "By consensus" is an option, though tends to stall, "by lazy consensus" is also an option? I don't mind not having a SLEP, but I think the SLEP should give an alternative.
There was a problem hiding this comment.
| Core Team members will become scikit-learn "Core Contributors": | ||
| a Contributor will be promoted to a Core Contributor after being proposed by | ||
| at least one existing Core Contributor. The proposal must specify which | ||
| Core Team the Contributor will be part of. The promotion will be effective |
There was a problem hiding this comment.
This mentions "Core Team". Should we first define what are Core Teams (and enumerate them)?
There was a problem hiding this comment.
As per #74 (comment), let accept here the general principle of new core roles and define a simple way to create them.
Once this SLEP accepted it will be easier and straightforward to introduce those new roles.
There was a problem hiding this comment.
This seems fair and reasonable to me.
There was a problem hiding this comment.
I'm not sure I understand the distinction between Core "Team" vs Core "Role". Is the prior explicitly meant to refer to GitHub permissions?
There was a problem hiding this comment.
Is the prior explicitly meant to refer to GitHub permissions?
Yes. Roles will exist even scikit-learn should migrate from github one day.
This is important when someone take a responsibility in the organization: github permissions should be set as this person could effectively do the job ... not the other way around... say people tasks modeled on github permissions.
Co-authored-by: Julien Jerphanion <git@jjerphan.xyz>
slep019/proposal.rst
Outdated
| last for two weeks and which must reach at least two-thirds positive | ||
| majority of the cast votes. | ||
| The current members of the Technical Committee [8]_ will ensure the transition | ||
| for a two-years period, starting from the acceptance of this SLEP. |
There was a problem hiding this comment.
Why two years? Is it a starting point to be discussed or is there some thinking behind why two is a good number?
My worry and experience with other governance changes/refactors/restructuring is that "work expands to take the time allocated to it". For me four weeks is (obviously) too short, and equally two years is (obviously) too long. At least it isn't clear to me that there is so much work needed that people would react with "two years to get this done, we better start right now and consistently work towards it because we might miss the deadline otherwise."
How about six months?
For me overly long deadlines are a signal that "this isn't really that important" as the first reaction by people having to deliver on the deadline will be procrastination and not action A deadline has to create a sense of urgency, not panic, but urgency. Otherwise it is IMHO useless to have a deadline.
There was a problem hiding this comment.
Why two years?
Some experience with decision times in scikit-learn.... 😇
But I am open to optimism, I believe a renewal of the SC is doable in one year: I am scared by the frustration that a deadline of 6 months could generate ... at least for me.
Quick reactions about this PR from all the core-devs might eventually push me to further shorten the deadline... 🙏
There was a problem hiding this comment.
Is it a starting point to be discussed
Yes, it is.
There was a problem hiding this comment.
Reduced the transition period to one year... 🤞
There was a problem hiding this comment.
I (still) believe that people deliver when you have high expectations. More practically, I expect people who agreed to serve in some role for a project (be that maintainer, team lead, club president, steering committee, etc) do so knowing that it will require commitment. By limiting the time frame you also give people a way to justify spending time now, because they know it won't be wasted or will drag on forever and ever.
It isn't like a honorary title that a university gives out or an award where you don't have to do anything in return for receiving it.
(I also get disappointed because that doesn't happen, but I remain optimistic :D)
Co-authored-by: Julien Jerphanion <git@jjerphan.xyz>
slep019/proposal.rst
Outdated
| At this aim, the Technical Committee is renamed as Steering Committee, opening the | ||
| decision process to new to be defined core roles. | ||
| New core roles are allowed to be defined without requiring new SLEPs, to ease subsequent | ||
| related changes to the Governance. |
There was a problem hiding this comment.
I think it would be good to describe what the process is going to be like. "By consensus" is an option, though tends to stall, "by lazy consensus" is also an option? I don't mind not having a SLEP, but I think the SLEP should give an alternative.
Co-authored-by: Andreas Mueller <t3kcit@gmail.com>
There was a problem hiding this comment.
Thanks @cmarmo , this looks much better now.
|
Hello everybody, I will be disconnected in the next days. |
Co-authored-by: Tim Head <betatim@gmail.com>
There was a problem hiding this comment.
This PR makes the SLEP quite light, which I like.
This SLEP does NOT say how exactly the governance doc should be changed. That would be a separate PR after the SLEP is accepted, and I think the details and nits and exact wordings would be a discussion for that PR.
I think this PR is now in a mergable state, so I propose to merge it, and call for another vote. Unless there are still major outstanding issues.
There was a problem hiding this comment.
Thank you @adrinjalali for your motivation, even if as a side effect I am forced back on line with limited capacity to act or even interact.... 😇
I have suggested some rewording as I haven't been granted the opportunity to answer previous comments... Notifying my absence apparently did not help?🤔
| majority of the cast votes. | ||
| The Steering Committee will accept members from any of the core contributor teams, | ||
| and after this SLEP is accepted, the definition and formation of core teams such as | ||
| the triage team and the communication team will go ahead. |
There was a problem hiding this comment.
As said previously no need to specify here which team will be added . This was matter of discussion in the previous pr.
There was a problem hiding this comment.
This doesn't strictly define them, it's more of a general direction in my mind.
My bad, sorry about that @cmarmo . I somehow interpreted your message as "I won't be available, please feel free to edit/move this forward". But after re-reading your message, I see you invited only comments. Silly misunderstanding. |
|
No problem @adrinjalali , thanks for clarifying. As a useful outcome, it seems like our conversation had pointed out a critical issue in this SLEP. I would rather see it clarified before the vote as we did not hear from all the core devs about it. @scikit-learn/core-devs please comment about |
|
Dear all, |
|
The Technical Committee is renamed Steering Committee. Edited after #81 (comment) |
|
The Technical Committee is renamed Steering Committee. |
|
For both options, I do not want the SC deciding who belongs on the SC. I prefer candidates to be nominated by any Core Contributor and voted on by the Core Contributors. For me, a "Core Contributors" is anyone on the existing Contributor Experience Team, Communication Team and Core Developers. As for "at least one member per core role" from option 2, I think that would be nice to have, but I do not want to mandate it. I prefer to let the Core Teams decide if any of them wants to join the SC. If an individual wants to join, they can be nominated and voted on. As for option 2, it proposes adding a deadline to:
Overall, I prefer option 1 as long as the candidates get nominated by any Core Contributor and voted on by the Core Contributors. |
Thanks @thomasjpfan I have modified option 1. following your suggestion. |
There was a problem hiding this comment.
Thank you for pushing this, @cmarmo.
I prefer the first option based on @thomasjpfan's comment #81 (comment).
I think it's fair to add a deadline for the end of the edition of this document and the start of the vote for the SLEP.
I am approving this PR, even if I am biased to due authorship.
Co-authored-by: Joel Nothman <joeln@canva.com>
Co-authored-by: Julien Jerphanion <git@jjerphan.xyz>
|
Regarding the discussion linked to the comments: #81 (comment), #81 (comment), #81 (comment).
I agree with this statement of @thomasjpfan.
I really like the idea to have a representative and diverse SC, that must be composed of members of all "future" teams. My concern is that I have no clue how to word this and even fewer clues on how to implement it properly. Adding quota would make sure that it happens. However, quotas are not quite ideologically aligned with voluntary-based membership: I don't want to force anyone to be in the SC if they don't want to. So stating clearly that the SC should represent all teams would be another solution. But stating it does not mean enforcing it (as somehow brought by @betatim when discussing the difference between "accept" and "integrate"). So in the end, I don't have a revolutionary proposal to make things better and even less have the right wording to express it in a SLEP. I would therefore go along with the current proposal. |
There was a problem hiding this comment.
I really like the idea to have a representative and diverse SC, that must be composed of members of all "future" teams. My concern is that I have no clue how to word this and even fewer clues on how to implement it properly.
Adding quota would make sure that it happens. However, quotas are not quite ideologically aligned with voluntary-based membership: I don't want to force anyone to be in the SC if they don't want to.
So stating clearly that the SC should represent all teams would be another solution. But stating it does not mean enforcing it (as somehow brought by @betatim when discussing the difference between "accept" and "integrate").
I agree with this sentiment. I don't think there's a reasonable way to compel this, aside from the social aspect of making a best effort of achieving that diversity of team representation. I think it makes sense to explicitly state it as the intended composition of the committee, and potentially rely on an understanding to achieve that.
I don't like how unofficial or "soft" that solution feels, but I can't think of anything stricter than that which avoids the issues brought up so far.
|
Dear all, The current version of this SLEP is a vague affirmation of principles without roadmap for actions.
The Steering Committee is likely to keep its current composition for years.
Here the solutions adopted by Python itself and by astropy.
Therefore, before forever holding my peace, I would like to suggest the following
No quotas, nominations based on volunteering, a clear perspective of better representation. |
|
This whole discussion started by us wanting to add more groups and have them considered as "core contributors". I don't think anybody objects to that. However, I don't think the sort of aggressive language, and attacks and judgements on the TC in this thread have been warranted. All TC members AFAIK agree with the sentiments proposed by the SLEP, but I don't see how the harsh language and the strict proposals for the SLEP are helpful. This proposal is bringing in some change, and I personally very much welcome the change. However, we have 10-13 active maintainers (depending on how you count), and a TC of size 7, and some members are not necessarily very active; so there's some room for rotation there. However, we haven't cared much about how active people in the TC are since we intentionally made sure the TC doesn't have much power as long as there's a consensus between the core developers when we wrote the governance model. There has been only one instance where we had to refer to the TC, and that was a rather unimportant one. Therefore I don't see how the TC's composition would be a problem which would require a rather quick change. To me the change in the TC/SC has the prerequisite of having more empowered and enabled people in roles other than the core developer role, and ythat is what we are going to do, and we agree on doing. But that'll take time, and once that happens, discussions about TC's composition would feel more relevant. |
|
I forever hold my peace,then. Fell free to merge. |
There was a problem hiding this comment.
A suggestion based on the last proposals from @cmarmo, @thomasjpfan, @glemaitre and @Micky774.
| The Steering Committee shall consist of members from any of the core contributor teams, | ||
| and after this SLEP is accepted, the definition and formation of core teams such as | ||
| the triage team and the communication team will go ahead. |
There was a problem hiding this comment.
Taking the comments into account:
- @thomasjpfan's proposal in SLEP019: Governance Update - Recognizing Contributions Beyond Code (version II) #81 (comment), which seems to got approval based on reactions.
- @cmarmo's remark in SLEP019: Governance Update - Recognizing Contributions Beyond Code (version II) #81 (comment)
- @glemaitre's remark in
- @Micky774's confirmation of @glemaitre's remark in SLEP019: Governance Update - Recognizing Contributions Beyond Code (version II) #81 (review)
This suggestion proposes:
- mentioning the diversification of the Steering Committee
- mentioning Core Contributors promotion to the Steering Committee via usual votes
- defining a maximum number of Steering Committee members'
- defining Steering Committee members' mandates.
| The Steering Committee shall consist of members from any of the core contributor teams, | |
| and after this SLEP is accepted, the definition and formation of core teams such as | |
| the triage team and the communication team will go ahead. | |
| The Steering Committee shall consist of at max 10 members from any | |
| of the to-be-defined Core Teams. No quota will exist for Teams' | |
| representation but Core Contributors agree to have a diversity of | |
| members for the Steering Committe. | |
| Any Core Contributor may nominate existing and new members belonging | |
| to other to-be-defined Core Teams to join the Steering Committee. | |
| The promotion of the nominated Core Contributor to the Steering | |
| Committee will be effective after a vote on the private Core Contributor | |
| mailing list which must last for two weeks and which must reach at least | |
| two-thirds positive majority of the cast votes. | |
| Each Steering Committee member: | |
| - has a mandate of at maximum two years | |
| - has the right to leave the Steering Committee during their mandate | |
| - can have their mandate renewed by a vote on the Core Contributor | |
| mailing list | |
| After this SLEP is accepted, the definition and composition of each | |
| to-be-defined Core Team (such as the Triage team and the Communication | |
| Team) will be discussed. |
There was a problem hiding this comment.
- has a mandate of at maximum two years
I can't seem to suggest edits here.
- has a mandate of maximum two consecutive terms
There was a problem hiding this comment.
I think a 2 year lifetime max is too restrictive, if that is what the current wording is implying.
There was a problem hiding this comment.
Some suggestions for organization of the Steering Council:
Have some folks with 1-year terms and others with 2-year terms.
Benefits:
- gives people flexibility on how long they want to serve
- we won't have all or majority of SC members going out at the same time
- easier for inactive SC members to exit
Considerations:
- there is the consideration that there is a limit of how many SC members can be from the same institution.
Turnover can be healthy for a volunteer leadership committee: "has a mandate of maximum two consecutive terms". However, there is the issue that there may not be enough people to serve.
There was a problem hiding this comment.
I’d like to avoid to vote too often and to limit possible candidates too much. Python with PEP0013 has a much more powerful SC, no term limit, but a vote after each feature release, i.e. once per year. Every SC member can leave anytime.
Concerning terms, I could imagine something similar.
There was a problem hiding this comment.
I think the words above are unclear, but the idea of explicit rather than implicit renewal makes the structure of the committee better reflect the variable nature of participation in the project. I hope that renewal will not be an opportunity to vote people out, but rather an opportunity for people to stand aside or discuss doing so.
There was a problem hiding this comment.
@jnothman: Thanks for your comment. I do not know what you are referring to with this remark:
I think the words above are unclear.
Can you suggest a rewording of the parts which aren't clear to you? Thanks!
|
Governance is important, so is discussing it. I appreciate all the thoughts and different discussion cultures so far. I think we are getting close to finishing this SLEP, but we‘re in no rush and it needs "due diligence". As to stricter enforcement of some of the intended changes: Even accepting a SLEP that says X will be done until some date does not guarantee that X will happen. For me, it is more important that X happens than having it in prose that it will happen. But it is important having it in prose that X is the intent and this we have (if I read correctly)😃 |
|
@lorentzenchr, thank you for your participation. I generally agree with your point, yet I do not know what you are referring to with X in this SLEP. Can you be more specific or suggest a reword of the part which aren't clear to you? Thank you! |
|
For your information, @thomasjpfan opened #84 to propose simplifying governance changes via SLEP020, a new SLEP. |
|
Closing per #87 |
Dear all,
this pull request offers modifications to the SLEP019 draft, following the discussion in #74.
The rendering is available here.