docs/process/subproject-maintainership.md

3 <!--toc:start-->
5 - [Subproject Maintainership and Forward Progress](#subproject-maintainership-and-forward-progress)
6   - [Process](#process)
7   - [Problem Description](#problem-description)
8   - [Scope](#scope)
9   - [Considerations](#considerations)
10     - [Social](#social)
11     - [Technical](#technical)
12     - [Security](#security)
13     - [Synthesis of Considerations](#synthesis-of-considerations)
14   - [Defining and Determining Unresponsiveness](#defining-and-determining-unresponsiveness)
15   <!--toc:end-->
22    [pre-conditions and definitions described below](#defining-and-determining-unresponsiveness)
23    1. The complaint is valid if all the pre-conditions are met and the behavior
25    2. The complaint is partially valid if the pre-conditions are met and but the
27    3. The complaint is invalid if the pre-conditions are not met
44 (BMCs). While it exploits existing open-source projects where possible, the
46 its use-cases.
48 By observation, BMC firmware encounters a lot of diversity in use-cases as well
50 fact that developing OpenBMC-based systems is most effectively done by the
51 companies designing the platforms. Reverse-engineering efforts
55 and are broadly motivated by platform-specific requirements rather than general
72 ---
74 The [Technical Oversight Forum (TOF) contract][tof-contract] paints the TOF's
77 [tof-contract]: /tof/contract.md
88 > - Approval of new bitbake meta layers.
89 > - Approval of new subprojects.
90 > - Supervising subproject maintainers.
91 > - Resolving subproject maintainer disputes.
92 > - Guidance and oversight of the technical direction of OpenBMC.
97 ---
99 [TOF issue #20][tof-issue-20] motivates exploration of a mechanism for it to
103 [tof-issue-20]: https://github.com/openbmc/technical-oversight-forum/issues/20
119 > study.][bias-for-action]
121 [bias-for-action]: https://www.aboutamazon.com/about-us/leadership-principles
128 The [maintainer-workflow][] document recognises the personal effort required to
131 [maintainer-workflow]: /maintainer-workflow.md
136 > - responsible: have a continuing desire to ensure only high-quality code goes
138 > - leadership: foster open-source aware practices such as [FOSS][]
139 > - expertise: typically demonstrated by significant contributions to the code
142 [foss]: https://en.wikipedia.org/wiki/Free_and_open-source_software
145 accommodate the review load][ed-is-only-human]. While unresponsive maintainers
148 put in the effort to build the project to its current capabilities. Healing
151 from community members without their consent is likely counter-productive,
152 [contrary to the initial proposal][initial-proposal].
154 [ed-is-only-human]:
155   https://lore.kernel.org/all/CAH2-KxAsq8=+kYZHb9n_fxE80SuU29yT90Hb0k72bKfY8pnWEQ@mail.gmail.com/
156 [initial-proposal]:
157   https://github.com/openbmc/technical-oversight-forum/issues/20#issuecomment-1272667701
168    that it no-longer applies in the event that they attempt to return to the
171 By the bias-for-action thought framework, (1) shouldn't be much of a concern in
172 practice - it should be feasible to revert changes if necessary. This same
192 it may be possible to quickly revert the problematic code once its existence is
205 putting guard-rails in place for the TOF to safely on-board new maintainers to a
208 unresponsiveness in order to trigger the on-boarding process for new
224 the ability for the TOF to on-board new maintainers. Further, as it is a social
225 contract it should be a socially-driven process: Inspection of the state of
240 Unresponsiveness at the subproject scope but not the project scope suggests its
241 at least possible to discuss on-boarding new maintainers to affected
251 pre-condition must be that unmerged contributions exist and remain unaddressed
263 failed consensus. Therefore it is a pre-condition that all maintainers of a
264 subproject are unresponsive at the project scope before the TOF may on-board new
267 The following values apply when the pre-conditions are met:
271 2. The TOF may on-board new maintainers to the subproject after 3 notifications