You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's several topics about improving documentation for incoming maintainers: #1331#1267#1117
However, I was wondering if there are best practices that could be formulated for how existing maintainers should gauge the trust resp. level of competence of someone wanting to become a maintainer.
I understand (quite well...) how challenging and thankless packaging is, and so we really want to be as welcoming as possible, because we need all the help we can get.
Still there are some risks with handing out maintainership (at least from an infrastructure - or, worst case, security - perspective), and I've seen several cases where someone opened a PR to become maintainer and was then kindly asked to establish some trust and credentials through PRs beforehand. This matches quite well with how I've tried to handle such instances.
This point came up again recently, where someone was asking to become a maintainer in their first ever PR (including the - to me - highly suspicious removal of existing maintainers), and I suggested they start as a contributor for the time being. This was before I became aware of the additional factor that they are a new joiner of @oblute's team (herself a prolific contributor to CF).
I think adding someone as a maintainer who's actively being mentored in that is fine, but I do not pretend to speak for conda-forge; the opinions voiced were only my own. In any case, I thought I'd bring up the topic for broader visibility & discussion (including some topics like how much of such mentoring should be visible on the feedstocks, see this comment).
The text was updated successfully, but these errors were encountered:
Given that there was no response, I'm planning to unblock conda-forge/gym-feedstock#13, including the addition of the rookie-maintainer-under-mentorship.
The core team leaves these issues up to the feedstock maintainers except for violations of the code of conduct and especially egregious/contentious cases (which to my knowledge has not happened). We expect people to be kind, respectful, and reasonable.
That being said my general attitude is always the more the merrier since there is always a ton to do.
You were right to flag the removal of an existing maintainer, but given the other responses on the specific feedstock, it appears everyone is ok with the changes. Merge away!
There's several topics about improving documentation for incoming maintainers: #1331 #1267 #1117
However, I was wondering if there are best practices that could be formulated for how existing maintainers should gauge the trust resp. level of competence of someone wanting to become a maintainer.
I understand (quite well...) how challenging and thankless packaging is, and so we really want to be as welcoming as possible, because we need all the help we can get.
Still there are some risks with handing out maintainership (at least from an infrastructure - or, worst case, security - perspective), and I've seen several cases where someone opened a PR to become maintainer and was then kindly asked to establish some trust and credentials through PRs beforehand. This matches quite well with how I've tried to handle such instances.
This point came up again recently, where someone was asking to become a maintainer in their first ever PR (including the - to me - highly suspicious removal of existing maintainers), and I suggested they start as a contributor for the time being. This was before I became aware of the additional factor that they are a new joiner of @oblute's team (herself a prolific contributor to CF).
I think adding someone as a maintainer who's actively being mentored in that is fine, but I do not pretend to speak for conda-forge; the opinions voiced were only my own. In any case, I thought I'd bring up the topic for broader visibility & discussion (including some topics like how much of such mentoring should be visible on the feedstocks, see this comment).
The text was updated successfully, but these errors were encountered: