search

scikit-learn / enhancement_proposals

Enhancement proposals for scikit-learn: structured discussions and rational for large additions and modifications
https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest
BSD 3-Clause "New" or "Revised" License
48 stars 34 forks source link

SLEP019: Governance Update - Recognizing Contributions Beyond Code (version II) #81

Closed cmarmo closed 1 year ago

cmarmo commented 1 year ago

Dear all, this pull request offers modifications to the SLEP019 draft, following the discussion in #74. The rendering is available here.

cmarmo commented 1 year ago

Hello everybody, I will be disconnected in the next days. Please, @scikit-learn/core-devs , don't hesitate to add your comments to the current version, I will address them all when back to github. Thanks for your understanding.

adrinjalali commented 1 year ago

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.... innocent I have suggested some rewording as I haven't been granted the opportunity to answer previous comments... Notifying my absence apparently did not help?

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.

cmarmo commented 1 year ago

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 https://github.com/scikit-learn/enhancement_proposals/pull/81#discussion_r1040937300 , so we can effectively move forward with this SLEP. Thanks again @betatim for the excellent summary of the issue.

cmarmo commented 1 year ago

Dear all, a week has gone by. I will try to make things as simple as possible. I will add below two comments containing the two different possible versions of this SLEP. Please, have a look and vote with a 👍 the one you prefer. Thanks for your cooperation.

cmarmo commented 1 year ago

1) The Technical Committee is renamed Steering Committee. Its composition will remain as is. In the future, any Core Contributor may nominate new members belonging to other to-be-defined core teams.

Edited after https://github.com/scikit-learn/enhancement_proposals/pull/81#issuecomment-1349780125

cmarmo commented 1 year ago

2) The Technical Committee is renamed Steering Committee. Its composition will remain as is. A deadline is set for the creation of new core roles (teams) and the integration in the SC of at least one member per core role (team).

thomasjpfan commented 1 year ago

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:

  1. Creating the Teams: If someone leads this effort, I am okay with adding a deadline here. Although, I think there is enough motivation to form the teams, that a deadline is not required.
  2. Adding more people to the SC: I do not think a deadline helps too much here. If there are already Core Contributors interested in joining the SC, then they can get nominated and voted on when the SLEP gets accepted.

Overall, I prefer option 1 as long as the candidates get nominated by any Core Contributor and voted on by the Core Contributors.

cmarmo commented 1 year ago

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. Do you mind materializing your preference with a :+1: under the comment? Just to help 'counting' at the end. Thanks!

glemaitre commented 1 year ago

Regarding the discussion linked to the comments: https://github.com/scikit-learn/enhancement_proposals/pull/81#issuecomment-1345922898, https://github.com/scikit-learn/enhancement_proposals/pull/81#issuecomment-1345924934, https://github.com/scikit-learn/enhancement_proposals/pull/81#issuecomment-1349780125.

Overall, I prefer option 1 as long as the candidates get nominated by any Core Contributor and voted on by the Core Contributors.

I agree with this statement of @thomasjpfan.

A deadline is set for the creation of new core roles (teams) and the integration in the SC of at least one member per core role (team).

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.

cmarmo commented 1 year ago

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. The only goal achieved by this SLEP will be a change of name... quite a small achievement for so much time spent on discussions... and no improvements in the representation of the various roles in the community.

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.

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.
Do you mind considering this proposal?

adrinjalali commented 1 year ago

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.

cmarmo commented 1 year ago

I forever hold my peace,then. Fell free to merge.

lorentzenchr commented 1 year ago

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)😃

jjerphan commented 1 year ago

@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!

jjerphan commented 1 year ago

For your information, @thomasjpfan opened https://github.com/scikit-learn/enhancement_proposals/pull/84 to propose simplifying governance changes via SLEP020, a new SLEP.

adrinjalali commented 1 year ago

Closing per https://github.com/scikit-learn/enhancement_proposals/pull/87