Decide on general Governance Structure

[Qwerky7835]

Governance Structure

As a first step to formalizing the shape of the Bazel SIG, a governance structure must be agreed upon. The first part of the issue will describe some current existing structures and then propose a structure for the Bazel SIG.

Important to bare in mind that Governance structures depend on the goals, members and values of the community and may evolve with time.

Existing Governance Structures

Large communities like Kubernetes tend to have just one Steering Committee (SC) which takes care of the cultural, organisational and business related activities. They favour highly independent SIGs who makes their own decisions on all technical workflows, member contributions and Repo management. SIG chairs report to the SC on a monthly basis. These communities adopt values of transparency and autonomy - all meetings and decisions are written, recorded and publicly available and there are automated processes for everything - and really everything. Example - PR checking bots differ depending on the status of the Repo (new, core, maintenance, etc.)

A smaller SIG set up, on the other hand, have more centralized technical control. See here for Spinnaker. They have a Steering Committee, a Technical Oversight Committee (TOC) and then SIGs. The function of their TOC is to centrally decide on Roadmap, and can dedicate how SIGs function in terms of, for example, PR processes and membership. The SC still serves the same function of business and cultural direction.

Goals to keep in mind

What do we envision the current Bazel SIG becoming?

We are currently one group of Rules Authors coming together to better prioritise PRs and communicate needs in a concise, industry relevant, manner to the Core Bazel team. Could we become a multitude of independent SIGs per language or per use case (eg. build automation, remote exec)?

The proposed Governance Structure below is based on my personal assumptions of our needs and goals:

• Authors of identified key repos to come together and discuss progress
• Liaison with Google Core Bazel team
• Operational arm for finances (donations based at this point) and general governance and conduct maintenance
• Scaling and onboarding / marketing considerations:
  • Potential to mature the Steering Committee
  • Allow current members / Rules Authors to start their own SIGs in the future.
  • Developer onboarding vs business stakeholder onboarding

Proposed Structure for Bazel Contrib

We still need to decide on the nomination process for these roles and can do a call for candidates over the next few weeks (months?) or we can informally take on roles amongst the initial members and expand outwards slowly over time.

• Steering Committee for Bazel Contrib

  • Possible Roles:

    • Chairs - from a range of companies and languages
    • Operational Manager for finance and marketing - one or two depending on area of need / expertise

  • Functions:

    • Decide on Organisation milestones (eg. What are we announcing at Bazel Con?)
    • Decide in Communication method with SIGs (right now we have rules auth and learning)
    • Liaise with Core Team efficiently
    • Methods of finance/donation
    • Community Management/Marketing

• SIGs (rules-auth; learning)

  • Roles:

    • SIG Leads
    • Mentors
    • Members

  • Functions:

    • Leads - Sync with SC, manage meetings and community (Sort of a one head many hats).
    • Mentors - Senior members of the SIG. They review / approve PRs and support members.
    • Members - Anyone interested. Can have detailed Member functions and interactions in another issue.

This issue is a general skeleton for the SIG and will be formalized into a PR once sufficient discussion and consensus have been reached.

[alexeagle]

Could we become a multitude of independent SIGs per language or per use case (eg. build automation, remote exec)?

per-language would defeat our purpose. However remote exec is one of the other three candidate SIGs we know of - Windows and Editors are the others. https://github.com/bazel-contrib#bazel-contributors

Allow current members / Rules Authors to start their own SIGs in the future

this is essentially those people forking our structure, which we can't stop them from doing, but it would represent a failure of our SIG to achieve what they wanted, and is certainly outside our scope.

Another way to say this is, the Bazel team can decide about organizing between various SIG's, our job here is only to organize our own. The "Bazel-learning-paths" repo doesn't represent a SIG.