Skip to content
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

Merged
merged 3 commits into from
Jun 7, 2021

Conversation

dfarrell07
Copy link
Member

@dfarrell07 dfarrell07 commented May 24, 2021

See commit messages for details.

Signed-off-by: Daniel Farrell dfarrell@redhat.com

@dfarrell07 dfarrell07 added documentation Improvements or additions to documentation cncf labels May 24, 2021
@dfarrell07 dfarrell07 self-assigned this May 24, 2021
@submariner-bot
Copy link

🤖 Created branch: z_pr520/dfarrell07/add_owners_jobs

@dfarrell07 dfarrell07 requested a review from nyechiel May 24, 2021 23:36
@dfarrell07
Copy link
Member Author

I made non-trivial changes to also define how Committers and Members are removed, so re-requested review @nyechiel.

Copy link
Member

@nyechiel nyechiel left a 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

@dfarrell07 dfarrell07 modified the milestones: 0.10-m1, 0.10-m2 May 25, 2021
Copy link
Contributor

@mangelajo mangelajo left a 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.

Copy link
Member

@skitt skitt left a 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).

@dfarrell07
Copy link
Member Author

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.

@dfarrell07
Copy link
Member Author

dfarrell07 commented May 25, 2021

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.

@Oats87
Copy link
Member

Oats87 commented May 26, 2021

@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.
Copy link
Member

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.

Copy link
Member Author

@dfarrell07 dfarrell07 May 26, 2021

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

https://wiki.opendaylight.org/display/ODL/TSC+Election+Process#TSCElectionProcess-TSCSeatAllocationsByRepresentedGroupforthe2021elections

Copy link
Member Author

@dfarrell07 dfarrell07 May 26, 2021

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's a TSC? :)

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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. 👍 🙏

Copy link
Member Author

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.

Copy link
Contributor

@mangelajo mangelajo left a 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.

@netlify
Copy link

netlify bot commented Jun 1, 2021

✔️ 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>
@dfarrell07 dfarrell07 requested review from mangelajo and skitt June 2, 2021 14:27
Copy link
Member

@nyechiel nyechiel left a 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?

@tpantelis tpantelis merged commit d67e68e into submariner-io:devel Jun 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf documentation Improvements or additions to documentation ready-to-test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants