Just to mention a tiny bit of friction that I find, that you're probably already aware of...
I would totally apply to do this but my OSS contributions are pretty sparse and go back a couple of jobs. I'm sure that I have the requisite experience but my GitHub profile for the last year and change is pretty empty. The application process totally discourages me from applying.
Yes, that's one thing that's currently a pain. How do you judge if someone is a good fit to take over (or, even harder, co-maintain) someone else's project just by looking at their Github profile?
Currently it's based a lot of "is this person already a maintainer of widely-used OSS libraries", as this is both a good signal and (hopefully) effectively foils malicious people, since, if you wanted to deploy some malicious code, you'd probably do it on the libraries you already have.
If you have any better ideas for how to "interview" maintainers, please let me know!
My expectation is that someone who is willing to attach their real name to something isn't willing to jeopardize their reputation and career over doing something malicious to a project.
Identity verification, similar to what Keybase supports, where people add a verification code to their social platforms might work here. Enough to verify to a certain degree whether someone is who they say they are. Maybe add a call to their employer to verify that they hold the role that they say they do also.
Hopefully that would solve that issue, but there's also the matter of someone being senior enough to be able to understand the direction of a project, set it, etc. Basically, you need to be able to trust every single one of the maintainers to have commit access on your project, with everything that entails.
For completely abandoned projects, it may not matter as much, but for projects that just need more eyes/hands, it's a larger consideration.
For completely abandoned projects, it may not matter as much, but for projects that just need more eyes/hands, it's a larger consideration.
Maybe add an agreement that if the community calls for a changing of the guard at some point that pending a review the maintainer will step down if the review process agrees.
I know HN is not terribly fond of crypto, but I think KYDcoin is a project that tackles this very usecase (specifically for crypto devs): https://review.kydcoin.io/
They review dev teams and attest they have seen personal information that matches the persons while the developers still can keep pseudonymous nicknames.
Who reviews the contributions? It's a good idea when the project has other maintainers, but when the new person is the only one, that can't really work...
i mean adding a person to the maintainer community. the review can be spread over current members of the community. 5-10 current members review 1-2 patches each from a candidate, regardless of which project the candidate contributes to.
even if you limit that extra work on repos you personally don't care about to once a month you can help one person to join the community per year, which is enough for the membership in the community to double each year.
That would be good, although it would require maintainers to become familiar with repos they might not be, just to review the user's contributions. It's a very good idea, though, since the contributions can just be regular PRs.
Comments
Just to mention a tiny bit of friction that I find, that you're probably already aware of...
I would totally apply to do this but my OSS contributions are pretty sparse and go back a couple of jobs. I'm sure that I have the requisite experience but my GitHub profile for the last year and change is pretty empty. The application process totally discourages me from applying.
Yes, that's one thing that's currently a pain. How do you judge if someone is a good fit to take over (or, even harder, co-maintain) someone else's project just by looking at their Github profile?
Currently it's based a lot of "is this person already a maintainer of widely-used OSS libraries", as this is both a good signal and (hopefully) effectively foils malicious people, since, if you wanted to deploy some malicious code, you'd probably do it on the libraries you already have.
If you have any better ideas for how to "interview" maintainers, please let me know!
My expectation is that someone who is willing to attach their real name to something isn't willing to jeopardize their reputation and career over doing something malicious to a project.
Identity verification, similar to what Keybase supports, where people add a verification code to their social platforms might work here. Enough to verify to a certain degree whether someone is who they say they are. Maybe add a call to their employer to verify that they hold the role that they say they do also.
To me that would be enough skin in the game.
Hopefully that would solve that issue, but there's also the matter of someone being senior enough to be able to understand the direction of a project, set it, etc. Basically, you need to be able to trust every single one of the maintainers to have commit access on your project, with everything that entails.
For completely abandoned projects, it may not matter as much, but for projects that just need more eyes/hands, it's a larger consideration.
Maybe add an agreement that if the community calls for a changing of the guard at some point that pending a review the maintainer will step down if the review process agrees.
I know HN is not terribly fond of crypto, but I think KYDcoin is a project that tackles this very usecase (specifically for crypto devs): https://review.kydcoin.io/
They review dev teams and attest they have seen personal information that matches the persons while the developers still can keep pseudonymous nicknames.
Maybe an inspiration?
how about a probation period? in that time, contributions are more actively reviewed than usual.
eg 3 months or 10 patches (whichever takes longer)
only after that they become a trusted member.
it's like joining any other project. new members need to show their will to contribute, and that doesn't necessarily relate to past contributions.
Who reviews the contributions? It's a good idea when the project has other maintainers, but when the new person is the only one, that can't really work...
i mean adding a person to the maintainer community. the review can be spread over current members of the community. 5-10 current members review 1-2 patches each from a candidate, regardless of which project the candidate contributes to.
even if you limit that extra work on repos you personally don't care about to once a month you can help one person to join the community per year, which is enough for the membership in the community to double each year.
That would be good, although it would require maintainers to become familiar with repos they might not be, just to review the user's contributions. It's a very good idea, though, since the contributions can just be regular PRs.