Open wlandau opened 2 months ago
This is a tough one. I doubt we can just borrow a set of policies for this. There is the danger of being procedurally fair, but blind to the biases that the procedures create in the first place.
We could perhaps try to articulate our values in a sort of memorandum, in terms of what we stand for and what the project aims to achieve.
I guess I should have said "learn" rather than "borrow". Definitely need to think things through from core principles. I haven't even looked into Apache yet.
The title of this thread was originally "Governance for on-boarding administrators and reviewers", but from this meeting, I changed it to be more general. We will need a general governance policy which transparently states how we make decisions. On this, @noamross mentioned https://github.com/Rdatatable/data.table/issues/5676, and @maelle mentioned that repos can have a GOVERNANCE.md
file which GitHub recognizes.
Looks like that data.table
thread was successful: https://github.com/Rdatatable/data.table/blob/master/GOVERNANCE.md
@noamross rightly pointed out that we should start small and learn from precedent. From the original post in https://github.com/Rdatatable/data.table/issues/5676:
We are not the first open-source project to have a governance document, here is a reading list about open-source governance, which can inform our discussion:
- Rust, OpenStack, Jupyter, Django, Typescript, Astropy, Microsoft, which are discussed in https://peps.python.org/pep-8002/
- arrow https://arrow.apache.org/committers/
- pandas https://pandas.pydata.org/about/governance.html
- ggplot2 https://ggplot2.tidyverse.org/GOVERNANCE.html
- substrait https://substrait.io/governance/ (thanks @assignUser )
- rOpenSci https://softdev4research.github.io/4OSS-lesson/04-contributions/ (thanks @waynelapierre )
From my perspective, it's easier to wrap my head around governance for a single package, so starting there might be more intuitive. But we're really more like Apache or PyPI, so it may be best to ultimately borrow/learn from them.
If you create a repository called .github
, its "community health files" (like GOVERNANCE.md) apply to the whole organization, unless single repos override them. https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file
The repo is also where the organization's README would live: https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-public-organization-profile-readme
Another example (but it's still very new, it's not even merged) https://github.com/igraph/.github/pull/1/files
The GOVERNANCE.md
file seems like a good approach here. Although specifically designated as such by Github, I don't actually see it displayed anywhere (for data.table for example) - it seems we'd still need to add a link to it from the README or elsewhere - @maelle correct me if that's not the case.
As for communicating changes to governance or policies, I think this should be a designated usage of discussions in the help
repo. This repo has been designed as the single point of contact for users, and I think we should continue with this. As we move to develop governance / policy / code of conduct etc., we need to remember to be transparent and keep things easy for the user to understand.
data.table doesn't have such a GOVERNANCE.md file actually?
https://github.com/Rdatatable/data.table/blob/master/GOVERNANCE.md they added it end of last yr.
oh sorry! I see it's not linked from the GitHub repo indeed. The contributing file is linked when one starts opening an issue.
not even visible in https://github.com/Rdatatable/data.table/community
Precisely my point, it doesn't seem to be visible in any part of the UI unless we explicitly make it visible.
yeah, I was a bit surprised, it's really more a convention.
The governance policies themselves, which Will highlighted above in https://github.com/r-multiverse/help/issues/60 are fascinating. I'm torn between the simplicity of ggplot2, and the Substrait one (the other extreme). The others I don't care as much for - BDFL + committee is still BDFL EDIT: ok perhaps that's a bit unfair, we can certainly devise something where BDFL only breaks ties etc. - but I think we can still steer clear of the term. We should definitely have another discussion amongst the working group to make sure we're aligned on the broad parameters before I start putting together a draft.
The governance document is in this PR: https://github.com/r-multiverse/r-multiverse.github.io/pull/16 When it is merged, this issue can be closed.
Noam mentioned we could borrow from Apache.