meta: about the collaborator nomination process #18090
Comments
joyeecheung
added
the
meta
|
Taking just the first question:
I think we should allow any Collaborator to nominate. The TSC still needs to approve all nominations. I don't see a problem with removing the restriction that a nomination must come from TSC, especially since we ignore it in practice. |
IMO, definitely the TSC. Not Collaborators. Their +1's are nice and all, but they don't count. I think it should stay that way. Giving someone the commit bit and access to not-sandboxed CI machines is not something that should sail under the TSC's radar. TSC members should be sufficiently engaged to have an opinion on these nominations. (If not, they should probably remove themselves as active members of the TSC!) |
what if a collab has a -1 for some reason, as any TSC member might. should it be considered/factored in? |
|
For the general case, as with all things, there really shouldn't be a need for an actual vote. We operate on a We-Should-Only-By-Voting-If-There-Are-Actual-Objections basis. If an individual is nominated by any contributor, that person should become a contributor if they want to do so. If there are objections, then there should be an attempt to resolve that objection without a vote. It should only have to be escalated to the TSC for voting as a last resort. Yes, the TSC members need to be paying close attention to all this and should be raising objections when necessary to do so.
Let's be clear about this: Yes, those +1's DO count for everything except something that escalates all the way to a TSC vote -- which most things should not. |
Any existing collaborator.
No.
The individual being nominated must have shown a willingness to contribute long term (that is, more than just periodically dropping in or doing a one-off PR).
An issue in the tracker.
As long as necessary but no less than our usual 48-72 hour review cycle.
Currently, whomever volunteers to do so. In the future, I'd like to see a more formalized concept of a Welcoming Committee. |
Clarification #1: At the current time, Collaborators do not have a direct say in adding other Collaborators. This is clear from our GOVERNANCE doc which explicitly gives that responsibility to the TSC. Collaborators can nominate. But the TSC ultimate chooses. That's the documented process now. If the documented process should be changed because we're not following it or because it can be improved, then let's do that. But the current documented process is as described above. Clarification #2: The +1's from Collaborators are not meaningless. My words were poorly chosen. Obviously, the TSC takes these things into consideration etc. etc. |
If that happens, the TSC is free to take that -1 into consideration, talk to the Collaborator who lodged it, etc. By the way, as far as I know, that's never happened. And I don't think it's likely in general. It's far more likely that a Collaborator will contact a trusted TSC member privately to express their concerns. |
|
I think we can use the private Github team discussion for a pre-nomination, for example:
The pre-nomination is not a requirement, it just makes things more comfortable since it's informal and private (BTW it looks a lot like the TSC nomination process). I think we all agree collaborators have a say in the nomination, we just need a better channel to coordinate. |
|
Would it perhaps make sense to make a private collaborator-nomination repo that all collaborators have access to? That could serve as a place to document sensitive details such as nomination + discussion, organize individual nominations, and avoid public snafus. |
|
@MylesBorins Maybe this is just me, but it feels like just using github team discussions might have less of a people-rating character than a distinguished repository (maybe because it doesn't feel like it would be as much about documenting the discussions as something to be kept forever?). |
|
I'd be generally -1 on having yet another private repo or discussion area for discussing these matters. Feels like too much private cabal, not enough open community. Reaching out to the individual prior to opening a nomination is easy enough, and thus far I'm not aware of a single objection having been raised when someone is nominated for commit access so that particular issue seems rather theoretical to me. @joyeecheung ... Have there been actual issues that I'm not aware of, or is it more of a generalized concern? @Trott said
The GOVERNANCE doc says only that the TSC has the ultimate authority in terms of "maintaining" the list of collaborators, it does not say that collaborators may only be nominated by the TSC. Our governance documentation also describes clearly how decisions are made generally within the project which is process I described. Perhaps we are just reading ambiguous words in two different ways that can both be considered correct, in which case, I'd suggest that someone open a PR with clarifying language. |
|
As a collaborator, I nominated other collaborators who made it in before - I've seen non TSC members nominate people before and it usually got endorsed (or not if not appropriate). I think the current process works pretty well. |
|
@jasnell Those are just theoretical concerns, but they are possible. Potential controversies that I can think of:
1 is not very likely but if it happens, the person nominating them might not be aware of this while one of the other 100+ collaborators might and they might express their -1 during the public nomination for that. It would be awkward to discuss those things in public, or, after postmortem private discussions, take a nomination back or let it stalled that way, especially if the nomination is done in the OP of an issue instead of being buried in a reply. (BTW I came to realize our current practice - batch nominating people in a reply, then waiting for no-objections - is not very welcoming to the nominees, which is what motivated me to open this issue). For 2 if we have a harder criteria for the nominations (e.g. n months of involvement, m commits, .etc) then I believe we don't need a private discussion for the nomination when the criteria is met. If we want to have a softer criteria and choose not to document it then we probably need a private discussion because if other collaborators propose to wait, the nomination could get stall a bit and the nominee might get disheartened. |
|
I definitely think we can make improvements on the nomination process without having to spin up a private repo or discussion area. Making it more personal by reaching out to the individual and asking them directly if they wish to be nominated, then working with them on ensuring all of the various criteria are met. This is one reason why I would love to have a formal Welcoming Committee within the project whose key purpose would be to help guide people through that process. |
|
@jasnell My concerns around having a fixed committee would be that there could be more potential collaborators than there are people in the committee, then it would hard to coordinate 1-on-1 mentoring in that case. I think in practice our new nominees usually have interacted with a few collaborators frequently prior to their nomination, but those collaborators do not appear to be a fixed group of people. The relationship also might have a lot of to do with local communities I believe. |
|
For the criteria: we can observe the average stats (time, number of commits/lines changed, ranking of activity in the recent 3 months .etc) of collaborators prior to their nomination and post the stats somewhere for reference. Although IMO this kind of stats is not enough to reflect the properties a contributor demonstrates during their contributions, and it doesn't reflect the significance of the contributions that well, so it is just for reference. We could raise the bar a little so if someone meets all the criteria, we don't need to discuss about it in private. But to nominate someone with an unusual contribution profile, a private discussion would probably help. |
|
I would add some more items to the discussion: a. I think everybody can suggests, but the TSC should nominate. |
|
I do like the idea of making the process prior to the formal nomination more personal, as @jasnell suggested. Although based on my observation I don't think it's very practical to form a committee dedicated to the preparation. Any collaborator can do the preparation if they are willing to, they don't have to be in a committee to do that. I think the person who identifies that potential collaborator should make sure that the risk of getting objections from other collaborators or the TSC is low, which I believe is what's currently being done anyway - it's just that we don't have a specific criteria for the nomination so it's hard to tell what other collaborator would think about it. That's something we need to improve, we should at least have some average stats for reference. If we only list the facts, then the whole thing would be less judgemental. About making things less private: I think the person doing the nomination can start a private discussion among the collaborators or talk to the potential nominee if they are uncertain about the risks, but that's not required. In general if a contributor reaches the average stats of new collaborators and they have shown willingness to help out whatever they can on the issue tracker, the risk of the nomination gone wrong should be low. It's just that we need to be cautious about the nomination and don't forget about things that need to be confirmed. We can just list those things out in a document, and let people do the preparation in their own way. |
|
Some stats that I think could be useful:
For reference, we can look at the same stats of an active contributor, and the stats of a new collaborator prior to their nomination. The stats can be used to generate the nomination template that I've mentioned above. This can be automated via https://github.com/nodejs/node-core-utils ( out of curiosity I had a branch that did similar things before when the TSC were trying to get reconfirmation from inactive collaborators. I'll see if I can get that back and rebase it properly..) |
Would the goal be to find collaborators who can help out in currently underrepresented parts of the project? Let's have a look at the last 5000 commits (12/2016 to 01/2018). If we check the average number of approvals per commit (mostly because I cannot think of a better metric) for some of the directories, we see that
If we do the same by subsystem, there is also a significant difference between those:
There are some more or less obvious explanations for these differences (required knowledge, C++ vs JS, effort of reviews, etc.), but I think some subsystems could still use more attention (e.g. crypto). One positive observation is that the average number of approvals across all PRs has gone up. In January 2017, commits were landed with 3.28 approvals on average, while the same number went up to 4.02 in the mid of 2017 and by December, it reached 4.27 approvals per commit. |
|
@tniessen Yes that's the goal. For contributors with expertise in subsystems currently without enough reviewers/maintainers, I think it's OK to require a smaller number of commits / less issue participations, as long as they have shown willingness to help in the long term. In the end it's up to the people doing the nomination though, they don't have to list the numbers, but they can choose to highlight the properties that they consider important in the nomination. Thanks for the stats, BTW. |
|
My 2 cents: I think part of the success we've seen is our "open" open source approach (for some background https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) where we are relatively liberal with bringing people in as "collaborators". We welcome in people who have started contributing and this encourages them to continue participating. I I also think we should avoid putting up a list of 'hard' requirements as some contributors ramp up quickly, while others contribute more consistently but over a long period of time so its hard to come up with a one size fits all. I'll echo an earlier comment that it seems to have been working relatively well with a few points that we can work on:
|
|
I know I'm not TSC nor even collaborator, but since this discussion is taking place here I figured I could throw in my two cents. As was said by multiple persons so far, lastly by @mhdawson , what makes the Node.js community a really dynamic community is the warmth one feels when coming and contributing for the first time. Even when there are things to change in a PR (some of you know how many times I had to change things on my PRs). While I can totally understand the need for security checks, and for specific domains of expertise, I don't expect -nor do I want- the latter to be severely enforced in and open community. I think it'd give a sense of "we want the elite only". For my part, I do hope one day I'll be fit for collaboration, but I know I'll be far from the level some here have. Putting hard requirements would pretty much crush that hope for me, and for many IMHO. This by the way, may relate to some stats given some comments up: while I'd love to contribute to Again, I hope I'm not out of place in any way. If so, feel free to remove my comment! |
I agree. That's why I suggest that we implement something to generate the stats for reference instead of using them to create hard requirements. But in the end we need some reference point for the collaborators to make an informed decision. Different collaborators might have different opinions on what makes a contributor a legitimate collaborator, after all, but it's easier to seek consensus if we have an average contribution profile as a fact.
The current way we do nominations do not give us a good timing or a good place for people to raise their concerns, if there is any. I would say it's more about the timing than about the place. At the moment the nomination is done immediately in public, and if there are any concerns the nomination would get stalled in an awkward way, no matter raised in public or in private. People might refrain from raising valid concerns because they don't want to get other people judged in public - the fact that the nomination gets stalled alone can lead to that. Therefore I don't think it's very healthy to wait for objections in public in the case of collaborator nominations, if we don't have an average contribution profile as a reference point that helps people make an informed decision beforehand. Waiting for objections on other matters in public work because they are much less personal. We also discuss about TSC nominations in private before it goes public for the same reason I believe. |
|
I don't think your comments are out of place. IMO users of Node.js put their trust in our hands so anyone who uses Node.js can express their opinion about our collaborator nomination process.
I agree. Also the collaborators are not just contributors, they are also maintainers. In the end I think the most important thing is that the nominee is willing to devote their time into the project in the long term. Thank you for sharing your experience! |
|
List of questions that we should discuss in today's TSC meeting:
|
PR-URL: #18268 Fixes: #18090 Refs: nodejs/TSC#472 Reviewed-By: Jon Moss <[email protected]> Reviewed-By: Shingo Inoue <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Weijia Wang <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
PR-URL: #18268 Fixes: #18090 Refs: nodejs/TSC#472 Reviewed-By: Jon Moss <[email protected]> Reviewed-By: Shingo Inoue <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Weijia Wang <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
PR-URL: #18268 Fixes: #18090 Refs: nodejs/TSC#472 Reviewed-By: Jon Moss <[email protected]> Reviewed-By: Shingo Inoue <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Weijia Wang <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
PR-URL: nodejs#18268 Fixes: nodejs#18090 Refs: nodejs/TSC#472 Reviewed-By: Jon Moss <[email protected]> Reviewed-By: Shingo Inoue <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Weijia Wang <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
PR-URL: nodejs#18268 Fixes: nodejs#18090 Refs: nodejs/TSC#472 Reviewed-By: Jon Moss <[email protected]> Reviewed-By: Shingo Inoue <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Weijia Wang <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
The current practice of promoting a contributor to a collaborators is somewhat like this:
The current way of doing things works but there are a few issues:
So in this thread I hope we could discuss:
👍 if you are +1 to this nominationin each reply.https://github.com/nodejs/node/commits?author=<githubid>to give readers a view of their contributions.I plan to open a PR updating the documentation when we work out the details mentioned above.
The text was updated successfully, but these errors were encountered: