GOV inactive members and emeritus #28906
Conversation
|
I think for such a change, it's important to understand the motivation and the challenges or problems we're trying to solve. I personally don't see an issue that this would solve:
So my question is, why the change? Note that if it comes to a vote, ATM I'm on the abstain side on this. |
|
cc @scikit-learn/core-devs @scikit-learn/documentation-team @scikit-learn/communication-team |
|
Thank you for starting this discussion, @lorentzenchr. I am in favor of defining clear categories of contributors and their respective responsibilities. I would like to continue maintaining scikit-learn on some aspects that interest me. Yet I, unfortunately, have other engagements and constraints. I think it would be fairer to have inactive maintainers (which I might be part of, for what I consider someone to be active) transition from the "Authors" category (which I think could be renamed to "Maintainers" or "Core-Contributor") to an "Emeritus" one. |
| website as emeritus member to acknowledging the period during which they were active as | ||
| core contributor. | ||
|
|
||
| The Council reserves the right to eject current members of the core contributors, if |
There was a problem hiding this comment.
There is no definition for "The Council" in this doc. Do you mean "The Technical Committee" instead? Or a majority vote among of the active core contributors?
There was a problem hiding this comment.
Also this is a bit out of the scope of the management of inactive/emeritus members.
There was a problem hiding this comment.
Left over from translating from scipy. It should read "the members of the core contributors".
| at least 2 weeks. | ||
|
|
||
| If a core contributor becomes inactive in the project for a period of one year, they | ||
| will be considered for removal from the core contributors. Before removal, inactive |
There was a problem hiding this comment.
If we decide to enforce this rule more strictly that we did in the past, we should probably define what we mean by "inactive" (e.g. no review / comment / created PR / create issue on github or participation in any dev meeting for 12 consecutive months or discussions on the mailing lists / discord server).
And we should probably have a script query the GitHub API to check for that.
There was a problem hiding this comment.
I'm a bit uneasy about this: it has reminiscence of Goodhart's law "When a measure becomes a target, it ceases to be useful", which point to a real antipattern in steering social dynamics.
I would rather not complexify the levels of activity. @jjerphan I think you are still active, since you are currently taking part in this governance discussion ;) But +1 to rename "Authors" to "Core contributors". Ideally I would like to have everyone in that list with extra badges to optionally indicate team memberships. |
I am pretty much inline with this thinking.
I personally feel uncomfortable if we request from me such a vote due to the benevolent nature of the project contributions.
If security is a concern, it would be more related to the ability to merge pull requests. In this case, I would prefer to separate the contributor's status from the merge rights. I'm fine with suspending merge rights, which could be reinstated upon the contributor's request and successful authentication check. Next, let's address the gap between the project's contributors and the project's activities. I agree with the first two points raised by @lorentzenchr. I also agree with @ogrisel's point not to make the levels of activity more complex. "Activities" are somewhat difficult to define. If we are only focusing on this repository, we could simply relay the OSS Insights (https://ossinsight.io/analyze/scikit-learn/scikit-learn) of the core team on the rolling yearly window as: 
It provides quantitative information (Is it right? Do we want to show metric?) on people's activity within the repository, but I must honestly express that I feel this is a step backward from what we aimed to achieve with the change of governance: recognizing a wide variety and types of contributions. I'm therefore unsure how to address the points raised, maybe badges as proposed by @ogrisel are enough. |
|
I think the list of people involved with the project as members should be accurate and represent the present. A bit like you should get rid of old laws, so that you don't accumulate them and then have weird ones like "you may not ride a horse while the moon is full on the beach". Mostly they do no harm (other than generate funny newspaper articles) but sometimes they do end up creating loopholes or weirdness. We clean up old/unused code/ Having a list of project members that is not accurate is a bit like that IMHO. It mostly doesn't cause trouble, except sometimes it does. On a personal note: as someone who has remained listed as a person somehow involved with projects it is nice to be removed. In a weird way. Mostly because the only time it comes up that I am a member with some project from my past is when a someone asks me in person about it. And then I have to explain to them, slightly embarrassed, that actually I've not really done anything for the project for a long time. However, by the time I am back at home I've forgotten or can't quickly find out how to remove myself. Take away: if one day I got a positive email about getting moved to the told people's section, I'd probably be happy. If they sent me a hat with "$foobar old timer" on it I'd be happy for sure :D Maybe we should make a hat that you can only get if you retire from scikit-learn/receive automatically when you retire. |
|
I agree with @glemaitre's interpretation of the issue. I think the security and social implications of this are independent, although they could be entangled by design base on whatever policy we choose. As one such maintainer that hasn't been able to contribute much of anything recently, I think that it would make sense for me, and others sharing my position, to forfeit commit rights from a security perspective after a year. If/when we become active again, it would make sense for those rights to be given again. Essentially, hitting a potentially indefinite "pause" button. Socially, I think it would be better to move inactive members from the member list (better named core-contributor as @jjerphan mentioned). I don't think outright removal should be considered unless there are very concrete reasons supporting that. Note that this is in addition to the commit rights forfeiture. In general I think folks that have irregular schedules or circumstances are the ones that will be most sensitive to this change. Although that may not constitute a large portion of core-contributors, in the ideals of sustainability, we should consider the effects on folks we incorporate in the future that may not have stability/regularity on a year-to-year basis. I understand that the spirit of the "grace period" is to mitigate this concern, but I think the effect is emplacing a deadline for becoming "active" again, which is ill-suited for open-source communities IMO. What does being "active" look like? How many contributions per month, and of what kind, would we deem "active"? I think that there is hardly a satisfying answer there, and trying to codify one would counter the philosophy of accepting that there are diverse social and non-technical paths to contribution. As a personal aside, I vey much look forward to contributing somewhat regularly again once my schedule eases up (hopefully in a few months) but acknowledge the difficulties of keeping up with different maintainers' availabilities and levels of activity and responsiveness when there are those like me among the active list.
Haha, now to farm these hats by becoming active once every 53 weeks so that I can auction them to (the many) scikit-learn fans out there. |
|
I think some contributions are more expensive: in my experience, and energy-wise, submitting a comment (like this present one) and making promises are cheap, whilst understanding the craft of a new solver's design matrix and confidently approving the pull request proposing its introduction, finding funds, and training new contributors for the project are expensive. I do not propose accounting or ranking contributions, nor do I want that we programmatically judge, but I think we must agree on some bare minimum diligence and responsibilities for Core-Contributors (some of which might and need not be developers) otherwise such a title is not representative anymore and looses its value. To be honest, I would be more at ease with being listed as "Emeritus Contributor", or "Sporadic (Core-)Contributor" than as "Maintainer" since it is more accurate. |
|
My opinion on a few high-level points:
In general, I'm not very much in favor of the currently-proposal wording and set of rules. I would be in favor of being more lenient, though I do acknowledge the root desire of keeping list more up to date, and I think that we should adjust our documents and processes to do this. |
|
It feels like there is something that makes people attached to being a core maintainer, even when they say that right now they aren't very active/involved/doing enough to be one? What is the thinking behind/benefit/worry around "I can only sporadically or not at all contribute right now, but might become more active again in a few months. However I would like to remain as a core maintainer"? I think if we can understand this better, we might be able to find a way forward. My feeling/thoughts on answering the above question: It took me a long time to "retire myself" from JupyterHub. I knew it was the right thing to do for a long time before I did it. Most of that time I spent feeling guilty for not being more active. Now, I feel excitement when once every few months I comment on something and when I can deal with all Jupyter related notifications that have piled up via "Archive all". I stop by JupyterHub land once in a while as "the old guy who is out of touch and tells stories from the past" - lets not kid ourselves :) But I feel like people take my opinion and inputs just as serious as they ever did. And I feel like a grown up when I tell people "Yeah, I am now an emeritus JupyterHub'er!" - I also use it as my "get out of jail free card" when asked questions about the project I'd rather not answer. I also worried that by retiring something I helped create would somehow fall apart. In retrospect and as far as I can tell from "the outside" mybinder.org is as alive and flourishing as it ever was. I'd even argue that by officially retiring space was created for others to do their thing. In many cases much better than I ever could have done it, and certainly better than inactive me did it. What I realised is that finishing something is great. You don't have to keep working on something, you can declare it finished (in the sense of how it fits into your life) and feel a sense of achievement. It creates space to work on something new (in this case scikit-learn as well as hobbies that have nothing to do with computers). I agree on not having concrete/automatically measurable criteria for deciding active vs inactive. Besides criteria gaming I think it is too simplistic to ever work. It is probably one of these things where it is difficult to write a concrete rule, but where most people would agree if asked on a concrete case. I think breaking the tie between your access privileges on platforms we use (like GitHub, PyPI, etc) and your standing in the project is a best practice (like using CI, unit tests, etc). The website should be the "source of truth". In particular given today's size of the project, the technical possibilities, number of users, etc, etc. Of course you'd only get one hat. Or maybe we could give out vouchers for your local tattoo parlour (with expedited re-admission as maintainer if you send us a video of your "scikit-learn for life" tattoo ;) ) |
|
All I see here is that it would be nice to have an emiretus status where people could put themselves there while staying active every now and then if they want. We already have that, and we can improve the wording for it if it's not good enough. I don't mind removing (after asking them, opt in) people's permissions on the project if they haven't been active in ages, but I don't see the need to have rules to remove people if they don't follow the rules as I cannot imagine it being healthy for the project. We should strive to have a nice community where we have the right and enough categories where people find one where they identify with at any moment and make it easy for them to move between them. Otherwise I'm afraid this might create a more toxic environment rather than improving it. |
|
There is an interesting discussion here in a private repo: *What do you do
with maintainers who are no longer active?*
community/maintainers#70
GitHub has a private FOSS maintainer community you're welcome to join:
https://maintainers.github.com/
…---
Reshama Shaikh
On Fri, May 3, 2024 at 5:47 AM Adrin Jalali ***@***.***> wrote:
All I see here is that it would be nice to have an emiretus status where
people could put themselves there while staying active every now and then
if they want. We already have that, and we can improve the wording for it
if it's not good enough.
I don't mind removing (after asking them, opt in) people's permissions on
the project if they haven't been active in ages, but I don't see the need
to have rules to remove people if they don't follow the rules as I cannot
imagine it being healthy for the project.
We should strive to have a nice community where we have the right and
enough categories where people find one where they identify with at any
moment and make it easy for them to move between them. Otherwise I'm afraid
this might create a more toxic environment rather than improving it.
—
Reply to this email directly, view it on GitHub
<#28906 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATEDYGKBFPAAY6JE7OI3O3ZANMMFAVCNFSM6AAAAABG5BYGZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJSGY3DQMZYGA>
.
You are receiving this because you are on a team that was mentioned.Message
ID: ***@***.***>
|
|
My understanding is that the discussion isn't about missing categories, but that they are not used (enough). |
|
As an inactive maintainer I would be +1 for this change. Also if someone can remove me from active contributors I would appreciate it. As far as I understand becoming emeritus currently means being removed from the scikit-learn github org altogether? The only thing that I find non ideal is that if we do that, then in old github issues it becomes no longer very clear who was the maintainer in the discussion. I'm still happy to do an occasional sprint, but realistically I don't need commit permissions for it. And I share the feeling that having a very large list of maintainers where not that many are active is not ideal for active maintainers. |
What about just having a scikit-learn/emeritus team on github that doesn't have merge rights (for security reasons)? |
I would prefer that. But I think that's also what we had before, and that team got removed as far as I can tell after a change in the governance. So I imagine there must have been a reason for that change. |
|
Happy to become emeritus as well |
This PR proposes a change of governance for inactive core contributors and the status emeritus. It is a 1-1 copy with slight adaptions to different terms from https://scipy.github.io/devdocs/dev/governance.html#council-membership.
2 thoughts on it:
EDIT
Motivation: