1# Subproject Maintainership and Forward Progress 2 3## Process 4 51. A complaint is raised to the TOF about lack of forward progress in a 6 subproject 72. The TOF validates the complaint against the pre-conditions and definitions 8 described below 9 1. The complaint is valid if all the pre-conditions are met and the behavior 10 exceeds the limits outlined in the definitions above 11 2. The complaint is partially valid if the pre-conditions are met and but the 12 behaviour does not exceed the limits outlined in the definitions above 13 3. The complaint is invalid if the pre-conditions are not met 143. If the complaint is valid the TOF notifies the current maintainers of the 15 impending addition of maintainers 16 1. The TOF identifies the set of candidate maintainers 17 2. If willing candidates exist, one or more are added as subproject 18 maintainers 19 3. Otherwise, the TOF members mentor the complainant on maintenance until 20 there is consensus they would be considered a candidate. The TOF then 21 introduces the complainant as a maintainer 224. If the complaint is partially valid then the TOF must notify the maintainers 23 of the impending addition of maintainers in the event of continued 24 unresponsiveness 255. If the complaint is invalid then no further action is taken 26 27## Problem Description 28 29OpenBMC is a Linux distribution specialised for Baseboard Management Controllers 30(BMCs). While it exploits existing open-source projects where possible, the 31OpenBMC community also maintains many integrated projects that are specific to 32its use-cases. 33 34By observation, BMC firmware encounters a lot of diversity in use-cases as well 35as board and platform design. The shape of the project's community reflects the 36fact that developing OpenBMC-based systems is most effectively done by the 37companies designing the platforms. Reverse-engineering efforts 38exist([1][],[2][]) but do not represent the typical path by which platform 39support enters the project. As a consequence the community tends to be dominated 40by people contributing to the project to support the needs of their employer, 41and are broadly motivated by platform-specific requirements rather than general 42capabilities. The motivation for contribution by those in the community tends to 43be extrinsic. 44 45[1]: 46 https://github.com/Keno/openbmc/commit/327da25efde4fc54b27586be3914159136f03784 47[2]: https://lore.kernel.org/lkml/7baebe77f0f8963e06d5ddeec6c737f5@rnplus.nl/ 48 49A consequence of this latter point is that engagement in the community can vary 50greatly with time based on events beyond the control of contributors and 51maintainers, through changes of roles, organisational direction or other factors 52like completion of support for a given platform. 53 54Extrinsic motivation driving variation in engagement is at odds with the 55consistency required by maintainer roles for the many integrated projects owned 56by the OpenBMC community. 57 58--- 59 60The [Technical Oversight Forum (TOF) contract][tof-contract] paints the TOF's 61role in the project with broad brush strokes: 62 63[tof-contract]: /tof/contract.md 64 65> The TOF handles the processes around accepting new features into OpenBMC, 66> creating new subprojects (git repositories), approving subproject maintainers, 67> handling and enforcement of subproject maintainer issues, and many other 68> technical leadership concerns related to OpenBMC. 69 70and: 71 72> Issues the TOF handle include: 73> 74> - Approval of new bitbake meta layers. 75> - Approval of new subprojects. 76> - Supervising subproject maintainers. 77> - Resolving subproject maintainer disputes. 78> - Guidance and oversight of the technical direction of OpenBMC. 79 80These broad brush strokes touch on the TOF's responsibilities towards 81maintenance but the subject receives no further treatment. 82 83--- 84 85[TOF issue #20][tof-issue-20] motivates exploration of a mechanism for it to 86introduce maintainers to subprojects to ensure the community can make forward 87progress when the existing maintainers become unresponsive. 88 89[tof-issue-20]: https://github.com/openbmc/technical-oversight-forum/issues/20 90 91## Scope 92 93While all unresponsive maintainers are problematic maintainers to some extent, 94it's not true that all problematic maintainers are unresponsive maintainers. 95This discussion specifically considers defining a mechanism to allow forward 96progress at the subproject scope in the face of unresponsive maintainers. It 97does not consider the more general problem of problematic maintainers. 98 99## Considerations 100 101The social, technical and security impacts of the TOF changing a subproject's 102maintainers are considered in the context of the following principle: 103 104> [Many decisions and actions are reversible and do not need extensive 105> study.][bias-for-action] 106 107[bias-for-action]: https://www.aboutamazon.com/about-us/leadership-principles 108 109The principle is used to prompt the question "Are the consequences easily 110reversed?" for each of the concerns below. 111 112### Social 113 114The [maintainer-workflow][] document recognises the personal effort required to 115become a maintainer: 116 117[maintainer-workflow]: /maintainer-workflow.md 118 119> Repository maintainers ought to have the following traits as recognized by a 120> consensus of their peers: 121> 122> - responsible: have a continuing desire to ensure only high-quality code goes 123> into the repo 124> - leadership: foster open-source aware practices such as [FOSS][] 125> - expertise: typically demonstrated by significant contributions to the code 126> or code reviews 127 128[FOSS]: https://en.wikipedia.org/wiki/Free_and_open-source_software 129 130Further, the community of maintainers inside the project [isn't broad enough to 131accommodate the review load][ed-is-only-human]. While unresponsive maintainers 132can be frustrating for contributors and a concern for the project, the problem 133needs to be weighed against the risk of alienating those who have (previously) 134put in the effort to build the project to its current capabilities. Healing 135alienation is at best intensive if not a futile effort; it is hard to reverse. 136This suggests that the TOF stepping in to remove maintainership responsibilities 137from community members without their consent is likely counter-productive, 138[contrary to the initial proposal][initial-proposal]. 139 140[ed-is-only-human]: 141 https://lore.kernel.org/all/CAH2-KxAsq8=+kYZHb9n_fxE80SuU29yT90Hb0k72bKfY8pnWEQ@mail.gmail.com/ 142[initial-proposal]: 143 https://github.com/openbmc/technical-oversight-forum/issues/20#issuecomment-1272667701 144 145### Technical 146 147At least two technical concerns exist: 148 1491. Contributors promoted to maintainers may lack or have no way to learn the 150 nuances and context for the current state of the codebase in question. There 151 may be a period (or periods) of instability until these issues are resolved. 152 1532. An unresponsive maintainer's knowledge of the codebase may age to the point 154 that it no-longer applies in the event that they attempt to return to the 155 subproject 156 157By the bias-for-action thought framework, (1) shouldn't be much of a concern in 158practice - it should be feasible to revert changes if necessary. This same 159approach applies in the case of (2) so long as the work is done in good faith. 160The process does need to consider the scenario where changes are not made in 161good faith. 162 163### Security 164 165Security concerns cut both ways. It's possible that: 166 1671. Contributors promoted to maintainers knowingly make changes that impact the 168 security posture of the project, or behave in a way that erodes or fails to 169 build the community's trust in their decision making. 170 1712. Not removing rights of an unresponsive maintainer from the subproject exposes 172 the project to a security hazard in the event that their account is 173 compromised. 174 175The first concern suggests that the contributors must have established trust 176relationships in the community before earning the responsibility of 177maintainership. It's hard to reverse a problem that isn't known to exist (though 178it may be possible to quickly revert the problematic code once its existence is 179known). Security problems can have an impact on the project's reputation; damage 180to reputation is also difficult to reverse, therefore the TOF needs to have 181confidence in any promotions. 182 183The second concern exists even for active maintainers and the process required 184to handle it might be the same: Removing rights until it's established that the 185compromise has been addressed. Unannounced activity from an otherwise 186unresponsive maintainer should itself be notable. 187 188### Synthesis of Considerations 189 190By the discussion above, a method for enabling forward progress should focus on 191putting guard-rails in place for the TOF to safely on-board new maintainers to a 192subproject. This is in contrast to not concerning itself too much with 193unresponsive maintainers, beyond recognising that they have met some bar of 194unresponsiveness in order to trigger the on-boarding process for new 195maintainers. 196 197## Defining and Determining Unresponsiveness 198 199Defining unresponsiveness sets expectations for both contributors and 200maintainers. Contributors can expect to have their work reviewed inside this 201period, and maintainers should endeavour to not let patches lapse. 202Responsiveness is a social contract. 203 204A tension exists between contributors needing feedback to maintain momentum 205against maintainers' available time both inside and outside the project. 206Maintainers are people: Life happens. Sometimes it is possible to communicate 207expected absences or hand over responsibilities, other times that may not 208happen. It's likely that unresponsiveness requires a fair margin in favour of 209maintainers, and that more than one instance should be needed before triggering 210the ability for the TOF to on-board new maintainers. Further, as it is a social 211contract it should be a socially-driven process: Inspection of the state of 212affairs in a subproject should only be performed if there are complaints about 213it, rather than using automation to detect the conditions. 214 215Unresponsiveness can appear at multiple scopes: 216 2171. Patch scope: Maintainers may ignore a given patch while attending to others 2182. Subproject scope: Maintainers may ignore a given repository while attending 219 to others 2203. Project scope: Maintainers may cease involvement in the project entirely 221 222Unresponsiveness at the patch scope would suggest a failure by the contributor 223and the maintainer to build consensus. It is already the role of the TOF to 224mediate these cases; this proposal considers such problems as out of scope. 225 226Unresponsiveness at the subproject scope but not the project scope suggests its 227at least possible to discuss on-boarding new maintainers to affected 228subprojects. Where possible, this is the preferred route to enabling forward 229progress. Failure of this process is again a failure of consensus, and is 230handled using existing mechanisms. 231 232The proposal concentrates on unresponsiveness at the project scope: Without 233regard to reason it is not possible to hold discussion with the maintainers in 234question. 235 236Lack of activity in a subproject is not evidence of lack of responsiveness. A 237pre-condition must be that unmerged contributions exist and remain unaddressed 238for the defined period. 239 240Further, multiple instances of unresponsiveness should be measured serially. 241Unresponsiveness is a property of behaviour in time: while the number of 242unaddressed contributions increases the impact and may increase frustrations, 243for any one period of unresponsiveness there is only one instance of the 244behaviour. 245 246Unresponsiveness also needs to be measured in terms of the set of maintainers. 247If any maintainer of a subproject is responsive in the project it's possible to 248make forward progress or to consider unaddressed contributions in terms of 249failed consensus. Therefore it is a pre-condition that all maintainers of a 250subproject are unresponsive at the project scope before the TOF may on-board new 251maintainers to enable forward progress. 252 253The following values apply when the pre-conditions are met: 254 2551. Maintainers are considered unresponsive after failing to address 256 contributions for a minimum period of 1 month. 2572. The TOF may on-board new maintainers to the subproject after 3 notifications 258 of unresponsiveness have been issued to the subproject's maintainers in a 12 259 month period. 260