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