Re: Turning GNU into a bottom-up organization

[DJ Delorie]

Ruben Safir <ruben@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?