Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add historical roles #324
Add historical roles #324
Changes from 23 commits
0ca41fd
0aab970
caabe95
ff8c831
0c0f4af
1e23b85
d80d935
603127e
9d258a5
d7223bf
08224ec
a0d7347
29a21cf
a1981b5
3176e44
ba29021
1617afd
fb1df54
0443f64
769e12a
835bec7
56b76df
e177bd5
130d171
a8c4d25
4c62a3b
9e608d2
82f4e58
7b4e72d
0ef6eb6
a385f71
bded28c
46ffacc
d037f79
beaca73
d11be08
50de3e1
bf6c48d
e7ca512
88e8dfd
91839ab
d50e270
e14bdfe
aecc25a
367869d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the fuzziness of historical roles, is it necessary and/or possible to distinguish between "leads" and "members"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the above comment at the very beginning of this review, but couldn't help but notice that the
historical_members
is always an empty list.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think I could go either way, and it definitely doesn't make too much sense at the moment! When I came up with the structure I thought we'd update the table annually or otherwise as people changed over, and shift the "current" leads/members into the historical column -- but if we head towards just maintaining a "current" column and keeping snapshots of this table around, that's not necessary either. If anyone has strong opinions about this either way they're very welcome!
As a compromise, until we nail down how we want to deal with archival or past lead/subgroups, how about just calling everyone a historical "member" (i.e. unbolding everyone), and removing the
historical_leads
from the documentation?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about cases where we know who the historical leads have been?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess my take here is - there have been a lot of things lately that have been concentrated on very few individuals and I think we should recognise that. But removing historical leads we're effectively saying "everyone did the same work".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true that we haven't directly set when these transitions are meant to happen, thanks for pointing that out. As you said this probably requires core-dev input. Since the next meeting is so far away I'll see if I can get agreement on when the "Current" column starts asynchronously -- if it's either the end of the core-devs role-call or 2024, we can re-title the columns or add explanatory text as appropriate. If it's something else we can perhaps re-visit the idea of dropping the "Current" column in favour of publishing the historical one ASAP, and adding a new column later. Does that feel like a good compromise between getting this table out quickly but accurately to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need for clarification
I would make the time frame and intent of "historical" clearer in the table itself - it should be something along the lines of "historical leads 2020-2023". Right now it says "historical contributors" and most folks aren't going to go into the text to check this.
Dilemmas
Maintenance
One of the categories which I'm not sure about (and I don't think the intent of historical had been communicated as "2020-2023 leads" by then) is general maintance:
Here's my dilema:
Over the 2020 to today period, there were a total of 364 PRs against the core library that were labelled under maintainability. The breakdown of PRs submitted under the "maintainability" label for the top 20 submitters is as follows:
Now, it is fair for @jbarnoud to want to be listed under "historical contributors" for that section - @jbarnoud did an overwhelming amount of maintenance in the past (i.e. prior to 2020). However, this raw data indicates that there are other folks here who have, by measure of the number of submitted PRs, have also done a lot of contributions in the 2020 to 2023 period. What is the right way forward here?
Releases
Another area where we have strict data on "who did what" is releases.
@richardjgowers was the release manager for releases until 2.0.0. I then did all the releases mostly on lonesome since.
It would make sense here to have that distinction because we have that data on hand?
Is 2020 too far away? Should we say 2021 instead?
In retrospect, the limit of our data is really 2020, and honestly it's an odd arbitrary limit to put down (I think I may have been at fault here for setting this date for data gathering).
There are things represented in this table that don't really make sense if we say 2020-2023. For example, I was not made core developer until 2021, admittedly I did a lot of work whilst not being a coredev (I think I got to ~ 50 maintenance PRs before folks agreed to make me one...), but I don't think we can claim that I was "managing CI" back then.
May I suggest being a bit more conservative and setting the max retrospective date to 2021?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both - when we have good data we should do this (see my releases example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd be happy with role-call being the set deadline? As far as I see them things are mostly still under the "old model", if we're saying "this will all change by Monday" then I'm looking forward to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will say here - I do think that we need to have a clear detailed set of instructions about what it means to be a lead, how we will review this table going forward to ensure that we accurately capture who has been doing what, etc...
I am particularly worried that folks will take on positions right now and another set of unamed folks will end up doing the work and we will never end up acknowledging them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@orbeckst - following on from yesterday's discussion, how do we feel about folks that aren't coredevs doing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, this is longer than anticipated — and sorry, you'll have to follow my typed out slow thought process:
Within our current definition of "core dev" as "project leadership" I think that's a bit problematic when viewing it from the perspective of the other side: If I were an outsider, looking to engage with the MDAnalysis Project, I'd eventually like to talk to someone in a position of obvious authority. The only way we currently obviously publicize "authority" is https://www.mdanalysis.org/about/#mdanalysis-core-developers and if I don't see the person I am negotiating with listed there then I might think that ultimately I will need to talk to someone else "who can make decisions".
From the internal side this seems like less of an issue to me. Within the current structure it would mean that the person leading this effort would not be able to vote on anything but could influence the process through discussion. If I were in this position I would probably feel not super-happy that I don't get a say in my own effort but that would depend on the person. We'd just need to be very clear up-front with them.
To come to something concrete:
I am considering
(2) is easy: Of course, the alternative may actually be "no-one does it or someone who cares does it" and then I am pretty sure the answer is that we'll do much better with someone who owns the role than someone whose name was put in to avoid a blank or who is stretched too thin. So there I think that someone who wants to do this and who has a track record of being able to work in such a role and work with the project is great. Ideally, we want both (for reasons above) but if we can't get both, then someone who wants to do it.
(1) It should be possible for "leadership" to delegate tasks. At the moment we are already doing this very successfully with our Project Manager. So I don't think that there's a problem per-se with someone leading a "role" who is not on the CoreDev list. However, the authority to do so must come from somewhere. Therefore, in these cases I'd say that "leadership" (CoreDevs) would need to vote to "appoint" and provide guidance on what the scope of authority is. This might feel mightily awkward.
In summary, I think we should be open to people who are not in the current Project Leadership (=CoreDev) to lead some of these roles and that ultimately they do this with delegated power from Leadership.
At the end of the day, it points more to the issue of rethinking our narrow governance structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we've had plenty more people than this engaged here previously