openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Brad Bishop <bradleyb@fuzziesquirrel.com>
To: openbmc@lists.ozlabs.org
Subject: Re: Call for volunteers
Date: Mon, 27 Sep 2021 12:25:28 -0400	[thread overview]
Message-ID: <20210927162528.tfh6igwuwef7rsk7@cheese> (raw)
In-Reply-To: <20210111220919.zwc727vbwc4itm7h@thinkpad.fuzziesquirrel.com>

On Mon, Jan 11, 2021 at 04:09:19PM -0600, Brad Bishop wrote:
>Hello OpenBMC-ers!
>
>Your TSC has been aware of the problem of fragmentation in our project for some
>time.  Fragmentation is a loose term - for the purposes of this note consider
>it to be any time contributor efforts in the community are duplicated without
>thought given to maintenance and/or compatibility.
>
>To begin to address this issue the TSC is looking for volunteers to serve on a
>"repository review forum" to which the TSC will initially delegate its
>authority in the areas of:
>- new repository creation
>- placement of contributed new function into existing repositories
>
>The TSC fully expects the scope of this forum to quickly grow into the role of
>a traditional TSC providing frequent, technical oversight to project
>contributors.  The current TSC will continue to serve the project in terms of
>governance, advocacy and industry exposure - and likely get a rename (OpenBMC
>Board? or OpenBMC Steering Committee?) in the process.
>
>The new forum would meet periodically or at the demand of other forum members
>to:
>- raise the forums combined awareness of new function under development
>  (information exchange)
>- build a consensus within the forum on where the function should exist
>- inform the function contributor and the rest of the community of the decision
>
>A successful forum would be a forum that can simultaneously encourage the
>contribution of new and innovative solutions to existing problems without
>introducing complexity to the project as a whole.
>
>A successful forum member will have previously demonstrated a breadth of
>understanding of the upstream OpenBMC codebase through:
>- frequent participation in peer review, the mailing list, IRC, and Discord.
>- submission of high quality designs and code to upstream OpenBMC
>  (github.com/openbmc)
>- a history of working with and guiding less experienced OpenBMC developers
>  in a timely manner, enabling them to come up to speed quickly.
>
>If you are interested in serving the project in this manner, please reply to
>submit yourself as a candidate.
>
>-brad, on the behalf of the OpenBMC TSC

Hi all

Myself, the volunteers that responded, and the TSC have been working for the
last few months to prepare a charter that outlines how this new workgroup will
operate and I'm happy to report that the workgroup is now online and
operational.  I've appended the workgroup charter for your reading, you can
also find it in the docs repository.

After you read the charter you will likely wonder what the role of the TSC is,
and that isn't documented in the charter so I will discuss it briefly here.
There are several types of open source governance models - a commonly used
model splits project leadership between a board of governors and a TSC.  A
board typically oversees project finances, handles personal and legal issues,
arbitrates or settles complaints and disputes, oversees the use of project
trademarks or other "community" assets, and most importantly is accountable for
the overall success and growth of the entire project and its community.  Many
of these apply to OpenBMC.  With the introduction of the new workgroup
(Technical Oversight Forum or "TOF"), OpenBMC effectively moves to this kind of
split governance model.  Since we are using non-standard and confusing
descriptions for these different leadership groups, I've included this little
decoder ring to help illustrate:

| Leadership Role | Typical Project | OpenBMC |
| ---             | ---             | ---     |
| General         | Board           | TSC     |
| Technical       | TSC             | TOF     |

In the longer term, my goal is to see these different teams formalized in the
OpenBMC project charter and we can use the standard descriptions, board for our
TSC, and TSC for our TOF.

thx - Brad

-------------
# OpenBMC Technical Oversight Forum (TOF)
This is a working document and subject to change.

The OpenBMC TOF or Technical Oversight Forum represents the technical
leadership of the OpenBMC project.

The TOF handles the processes around accepting new features into OpenBMC,
creating new subprojects (git repositories), approving subproject maintainers,
handling and enforcement of subproject maintainer issues, and many other
technical leadership concerns related to OpenBMC.  This source of this document
is in the OpenBMC documentation repository (https://github.com/openbmc/docs).
The TOF updates and maintains this document, using the process documented
within, and it can be considered authoritative unless directly overridden by
the TSC. 

## Working Principles
- Decision making is a spectrum between building broad consensus, in which
   everyone has agreement, and providing guidance quickly, even when there are
   strongly differing view-points.  This group should intend to work towards
   broad consensus, with a balance towards moving forward when there is minor
   disagreement.
- Members within this forum are representatives of the development community as
   a whole and not as representatives for the entities they are employed by.  As
   such, decisions should be made based on merits of the decision at hand and
   not on impacts to various member entities.
- Encouraging progress, experimentation, and decision making within the project
   is the core purpose of the TOF and not to create processes and barriers to
   development.  Velocity should be favored over perfection, except as a
   rationale for ignoring well-reasoned issues.

## Role and responsibilities
Issues the TOF handle include:
- Approval of new bitbake meta layers.
- Approval of new subprojects.
- Supervising subproject maintainers.
- Resolving subproject maintainer disputes.
- Guidance and oversight of the technical direction of OpenBMC.

## Current members
- Brad Bishop - radsquirrel
- Andrei Kartashev - Alatar
- Deepak Kodihalli - dkodihal
- Ed Tanous - edtanous
- Richard Thomaiyar - rthomaiy
- Patrick Williams - stwcx
- Lei Yu - LeiYU

The TOF shall have a minimum of 5 and maximum of 9 members at any given time.

The chair rotates month to month.

Chair responsibilities:
- Preparing the agenda.
- Taking meeting minutes.
- Documenting decisions on GitHub.

Members are elected by community contributors yearly.  The voting process will
be determined by the TOF at a later date and updated in this document.  TOF
candidates should have a breadth of knowledge about the OpenBMC project. Ideal
candidates will also have a public history of fostering collaboration between
teams.

Resignation of TOF members will be handled as an empty/reduced seat until the
next voting session.

## Github issues
The TOF tracks any ongoing decisions using GitHub issues (link to repo goes
here). Issues can be opened by anyone, including TOF members themselves. Issues
can be requests for process or technical changes, or solicitations for the
opinion of the TOF. When an issue is opened the TOF will respond to a proposal
or a solicitation, or add it to the next TOF meeting agenda for TOF discussion.

Once an issue has a proposal, TOF members have 8 days to vote on the proposal
in one of three ways: for, against, or “needs discussion”*.  After 8 days, if
the proposal has at least three votes for and no other votes, the proposal is
approved.  Alternatively, if the proposal has at least three votes against and
no other votes, the proposal is rejected and closed.  Any other vote count
results in the issue being put on the next TOF meeting agenda.   To ensure
proposals do not stagnate, if the initial 8 days elapses and the minimum number
of votes has not been met, the proposal is extended by an additional 6 days and
then put onto the next TOF meeting agenda after 2 weeks.

Issue vote indicators by reacting to the top post:
  - For - 👍 (`:+1:`) 
  - Against - 👎 (`:-1:`) 
  - Needs discussion - 👀 (`:eyes:`)

## Meetings
The TOF meets bi-weekly. Any requests for consideration by the TOF should be
submitted via a GitHub issue using the process documented earlier in this
document.

Meetings require a quorum of the TOF to be present; quorum is defined as:

| Active TOF membership | Quorum |
| ---                   | ---    |
| 5                     | 4      |
| 6                     | 5      |
| 7                     | 5      |
| 8                     | 5      |
| 9                     | 6      |

During the meeting, the TOF discusses proposals under dispute and votes on
them. A proposal is rejected if it does not reach majority approval or there is
more than one dissenting vote.

It is the responsibility of the TOF chairperson to make a public record of the
decisions of the meeting.

## Discord channel
The TOF has a private Discord channel for forum member coordination and, in
rare situations, potentially sensitive topics.  Sensitive topics would be
topics having security or privacy concerns, such as those involving actions of
an individual developer.  The TOF chairperson is responsible for coordinating
the public posting of any information or decisions that do not need to remain
private, using the same process as public issues.

      parent reply	other threads:[~2021-09-27 16:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 22:09 Call for volunteers Brad Bishop
2021-01-12 16:55 ` Ed Tanous
2021-01-12 20:11   ` Gunnar Mills
2021-01-12 21:07 ` Patrick Williams
2021-01-12 22:47 ` Andrew Jeffery
2021-01-13  5:00 ` Thomaiyar, Richard Marian
2021-01-13  5:30 ` Deepak Kodihalli
2021-01-13  5:38 ` Lei Yu
2021-01-13  5:42 ` Andrei Kartashev
2021-01-13 15:28 ` krtaylor
2021-01-14 17:39 ` Vernon Mauery
2021-01-26 23:56 ` Benjamin Fair
2021-09-27 16:25 ` Brad Bishop [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210927162528.tfh6igwuwef7rsk7@cheese \
    --to=bradleyb@fuzziesquirrel.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).