Ruben Safir <ru...@mrbrklyn.com> writes: > Appointment has always worked.
In another project I contribute to, there was a conversation about the project's "bus factor": https://en.wikipedia.org/wiki/Bus_factor We tried to restructure the project so that no one role had a bus factor of one. RMS is a bus factor of one. So the question becomes... what happens if, $diety forbid, RMS gets hit by a bus? Who does the "appointing" then? How can we be assured that the project continues with the same goals as before? Every GNU project should ask themselves this question too - is there one person who, if they went MIA, would cause the project undue distress? Say, a keeper of passwords, or owner of domains? If so, does the project have a plan for fixing that? Appointing a new maintainer will not magically make secret passwords appear. But as for the larger topic - RMS does not appoint *everyone*. As he noted, he delegates that authority to maintainers. Historically, he's had a hands-off approach to the practical day to day operation of the projects, so for most projects appointing a new maintainer *is not enough*. How can a project mitigate this problem? What needs to be documented, shared, escrowed, so that a new appointee can just step into the task and ensure a robust continuation of the project? Even if we all agree on the "big picture simple answer" the details and "best practices" are just as important. Do you have any suggestions for filling in these details? _______________________________________________ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
