-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Project Owner responsibilities #520
Conversation
🤖 Created branch: z_pr520/dfarrell07/add_owners_jobs |
c000625
to
77fa088
Compare
I made non-trivial changes to also define how Committers and Members are removed, so re-requested review @nyechiel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I'd like @mangelajo @Oats87 @tpantelis @skitt to review as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok to me but please make sure that all code owners are ok with L188 before merging, even if we don't have intentions to do anything like that at this time, I guess it's something we need to define as part of the governance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PO removal seems a bit iffy to me, but I’m not sure there’s much more we can do. We’d need an oversight committee of some sort (like the TSC in other groups of projects), or perhaps company participation rules (to guarantee for example that we don’t end up with a dominant company’s employees voting to throw out a PO from another company).
Right, and we've help build systems like that in the past for OpenDaylight and other Linux Foundation Networking projects. I agree we should continue improving, especially as we mature (ie go for CNCF Incubation). For now I was just trying to get us started with something simple. |
Here's the system we helped build for OpenDaylight, for example: https://wiki.opendaylight.org/display/ODL/TSC+Election+Process I think it's very robust and fair, but complex. |
@dfarrell07 et all: The PO removal process seems too open to "hostile takeover" to me, especially after seeing what happened with Freenode recently, I am very wary of such a process being implemented that doesn't have more barriers to prevent POs from a majority company performing a hostile takeover. I'd be more open to a system of votes where PO votes that come from a single company would only count as one vote, but this proves to be difficult as there are only two companies on the project at this point that have POs. |
@@ -179,6 +185,8 @@ The following apply to people who would be an owner: | |||
* Identifying subtle or complex issues in designs and implementation PRs | |||
* Directly contributed to the project through implementation and / or review | |||
|
|||
Project Owners can be removed by stepping down or by two thirds vote of Project Owners. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit too open to hostile takeover possibilities to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Oats87 With our current PO situation, I don't think there can be a system in which a PO can be removed and hostile takeovers are prevented. If it were "by vote of all POs other than the one being removed", it'd still be the same situation.
We'd need to do something more like a TSC I think, and have Represented Groups from stakeholders that aren't Red Hat/Rancher. Open to suggestions. I'll be thinking about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could just say "POs can't be removed except for Code of Conduct violations" for now, and build a TSC when we go for CNCF Incubation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ODL is currently using only a Committer at Large (CaL) Represented Group (RG) with a company cap of 49%. That is quite simple, good for smaller communities, but also provides protection from takeovers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it's complex, but tl;dr that using that system, if people from 3 different companies ran, each company would be guaranteed at least one seat and we would be protected from takeovers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's a TSC? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does a TSC make sense in a single-project context?
Maybe it's better just to scope/call it "electing/removing project owners".
Who would we expect to be in the TSC, and how would we ensure that it wasn’t just the project owners?
I imagined that by the time we go for Incubation, we would have a fairly substantial user community from which we could elect people. I'd hope that the current POs would run and be elected, in addition to new POs from other ~companies.
what's a TSC? :)
Technical Steering Committee, elected project leadership.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a current solution of freezing removals except for CoC violations makes sense, although I would say a TSC is going to require additional manpower to run; if you think that there is enough bandwidth in order to run such a committee then that would be OK, but otherwise, the ODL system with a CaL RG + 49% company cap is "simplest" past the CoC violation removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Oats87 Cool, yes sounds like a good path to me. I saw this a bit late to make changes to the PR before the meeting in 4m, but I'll send an update with that wording after. 👍 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I sent updated wording (split into second commit). Re-requesting review from everyone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's resolve @Oats87 concerns before merging.
77fa088
to
99d6038
Compare
✔️ Deploy Preview for elated-bell-2913d9 ready! 🔨 Explore the source changes: de49f25 🔍 Inspect the deploy log: https://app.netlify.com/sites/elated-bell-2913d9/deploys/60be462c7283dd0007ad8150 😎 Browse the preview: https://deploy-preview-520--elated-bell-2913d9.netlify.app |
While working through the CNCF Sandbox on-boarding process, the Open Governance checklist from opengovernance.dev recommended by CNCF highlighted these as gaps in our current governance. This specifies that Project Owners have responsibility for security disclosures, Code of Conduct violations and funds. These responsibilities should be given to dedicated groups as the Submariner community grows. Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
While working through the CNCF Sandbox on-boarding process, the Open Governance checklist from opengovernance.dev recommended by CNCF highlighted removing Owners/Committers/Members as gaps in our current governance. This establishes a basic process to cover extreme cases, while protecting the project from a malicious takeover and laying out a process for moving to elected governance as a replacement for perpetual Project Owners. Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
99d6038
to
8117f64
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, @Oats87 @mangelajo @tpantelis @skitt can you review as well, please?
See commit messages for details.
Signed-off-by: Daniel Farrell dfarrell@redhat.com