Project Governance Umbrella issue

[bgrant0607]

There have been a number of discussions about project governance.

Relevant issues:

• Elders
  • https://github.com/kubernetes/community/issues/28
  • https://github.com/kubernetes/community/pull/267
• Governance.md
  • https://github.com/kubernetes/community/issues/277
  • https://github.com/kubernetes/community/pull/286
  • https://docs.google.com/document/d/1UKfV4Rdqi8JcrDYOYw9epRcXY17P2FDc2MENkJjMcas/edit
• Three branches
  • https://github.com/kubernetes/community/issues/295
• Bylaws
  • https://github.com/kubernetes/community/issues/351
• Community norms
  • https://github.com/kubernetes/community/issues/350

One thing that is clear is that people are trying to solve different problems. The purpose of this issue is to surface those problems and (ideally) to come to agreement about which problems we're going to tackle first. Then we get move onto proposals for how we're going to solve them.

Some problems that have been mentioned, culled from the above, in no particular order:

• The structure of the project is opaque to newcomers.
• There is no clear technical escalation path / procedure.
• There aren't consistent / official decision-making procedures for ~anything: consensus, lazy consensus, consensus-seeking, CIVS voting, etc.
• There are no official processes for adding org members, reviewers, approvers, maintainers, project leaders, etc.
• There is no official / regularly meeting body to drive overall technical vision of the project.
• We don't agree on the right level/types of engagement for leaders. Some feel that leaders should be recused from responsibilities such as SIG leadership, while others feel they need to be deeply involved in releases, etc.
• There aren't official technical leads for most subareas of the project.
• There is no centralized / authoritative means of resolving non-technical problems on the project, including staffing gaps (engineering, docs, test, release, ...), effort gaps (tragedy of the commons), expertise mismatches, priority conflicts, personnel conflicts, etc.
• In particular, there is insufficient effort on contributor experience (e.g., github tooling, project metrics), code organization and build processes, documentation, test infrastructure, and test health. Some on the project have argued that there is insufficient backpressure and/or incentives for people employed to deliver customer-facing features to spend time on issues important to overall project health.
• A related issue is counterbalancing technical- and product-based decision-making.
• Visibility across the entire project is lacking.
• Metrics, metrics, metrics, metrics. We're flying blind.
• There is no documented proposal process.
• There isn't a documented process for advancing APIs through alpha, beta, stable stages of development.
• Project technical leaders (de facto or otherwise) are not available via office hours.
• We don't have processes or documentation for onboarding new contributors.
• There are no official safeguards to prevent control over the project by a single company.
• Project leadership lacks diversity.
• There is no conflict of interest policy regarding leading/directing both the open-source project and commercialization efforts around the project.
• There is no consistent, documented process for rolling out new processes and major project changes (e.g., requiring two-factor auth, adding the approvers mechanism, moving code between repositories).
• Nobody has taken responsibility to think about and improve the structure of the project, processes, values, etc. A few people have been working on this part time, but it needs more and more consistent attention given the rate of growth of the project.
• We're also lacking people to drive, implement, communicate, and roll out improvements (and test, measure, rollback, etc.).
• There isn't a sufficiently strong feedback loop between technical contributors/leadership and the PM group.
• Nobody has taken responsibility for legal issues, license validation, trademark enforcement, etc.
• Technical conventions/principles are not sufficiently documented.
• Development practices and conventions across our repositories are not consistent.
• Our communication media are highly fragmented, which makes it hard to understand past decisions.

What other problems do people think we need to solve? Let's brainstorm first, then prioritize and cull.

cc @sarahnovotny @brendandburns @countspongebob @sebgoa @pmorie @jbeda @smarterclayton @thockin @idvoretskyi @calebamiles @philips @shtatfeld @craigmcl

[bgrant0607]

Timely: https://medium.com/@mikeal/maintainer-vs-community-97edc28387ad

[bgrant0607]

Cloud Foundry: https://www.cloudfoundry.org/wp-content/uploads/2015/09/CFF_Development_Governance.pdf

[MylesBorins]

Here is the deck from my OSLS presentation https://kni.sh/osls-2017/

More than happy to help out and answer questions

[bgrant0607]

An observation: I think it has helped significantly to define specific roles and responsibilities for the release team. It makes it more clear what needs to be done, enables us to ensure that those roles get staffed adequately, and provides criteria for evaluating whether the responsibilities were adequately fulfilled.

We have quite a bit of other ongoing work in contributor experience (e.g., the issues raised in the SIG community thread, testing, and other groups. We do need to do a better job of maintaining prioritized backlogs of work (e.g., using github projects, which is another discussion), but more well defined roles should be an objective.

[MylesBorins]

Clear responsibility for release team, and clear schedule for releases, is a great start. The TLDR for node is that we have a Core Technical Committee that hands off release responsibility to a small release team (about 6 individuals) who have their gpg keys listed in the README.md. The team acts fairly independently for latest release lines. LTS releases have primarily been done by myself, under the oversight of the LTS working group, which is a small group of people mostly from CTC.

The primary thing that has been important in all of this has been that the release + lts teams have been given the flexibility and support that they need to do their job. The CTC is only brought in when consensus cannot be reached or we want explicit sign off on something controversial

[bgrant0607]

Kubernetes governance docs: https://docs.google.com/document/d/1btvNcAKHG-3vxxpnoOk0dV5-RqyYyd198Psg11cEPVA/edit

PTAL

[spiffxp]

awaiting deployment of https://github.com/kubernetes/test-infra/pull/4089 to take away the needs-sig label

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta. /lifecycle stale

[bgrant0607]

Replaced by https://github.com/kubernetes/steering/blob/master/backlog.md

[bgrant0607]

Note that technical oversight/direction is being handled in SIG Architecture