InnerSourceCommons/InnerSourcePatterns

bug: CODEOWNERS file has errors

jmeridth opened this issue ยท 8 comments

Looks like @psanxiao needs write access to fix .github/CODEOWNERS

Screenshot 2024-03-24 at 7 52 40โ€ฏAM Screenshot 2024-03-24 at 7 52 47โ€ฏAM

Welcome Banner](https://zenodo.org/record/3695300)
๐ŸŽ‰ Welcome to The InnerSource Commons community, and in particular to our patterns! ๐ŸŽ‰ We're really excited to have your input into the project! ๐Ÿ’–

If you haven't done so already, please check out our Contributing Guidelines. If you need to connect more synchronously with members of The InnerSource Commons community, come chat with us in our Slack workspace.

Fair point @jmeridth. it is nice of you (and GitHub :)) to remind us of this!

If I recall correctly, our idea with the lower section of the CODEOWNERS file was, that those folks doing the translation work might sort of be "maintainer apprentice", and through their involvement in the project become maintainers eventually. I think this is why we might not have given all of them WRITE access immediately.

However I think there is no harm in doing so. Therefore I just sent an invite to @psanxiao, so if he accepts this issue will disappear shortly.

Let's keep this issue open until we confirmed that it is fixed โค๏ธ

I love that re: maintainer apprentice. Thank you for clarifying. No worries if you want to close this. I appreciate the process.

๐Ÿ˜† emoji is re (and GitHub :)) in your message.

@spier Could this "maintainer apprentice" approach be another pattern to add to this book? ๐Ÿค”

That could definitely be something organizations could use to vet maintainers.

Hmm. That is an interesting idea.

We don't have a pattern about this, I think.

I wonder if this has been expressed under different names elsewhere already. Maybe even just as a part of a description of how to onboard a new maintainer. Wouldn't be too far fetched to assume that a new maintainer might get increasing responsibilities (and with that permissions) in stages of increasing difficulty and risk.

However my suspicion is that in open source the general idea would be to start with a lot of trust right from the beginning, while many orgs with an InnerSource might be more risk adverse in the same situation. Just speculating :)

If you are interested in this space and have time, would be great to break this out into a new issue and research this a bit.

@spier with the invite sent to @psanxiao, I'm good closing this issue. Thank you for the great conversation on the "maintainer apprentice" pattern.