How would you enforce a policy of documenting every role and project timetable in Debian, to enable easy staff changes for every task?
I simply would not enforce/encourage such a policy. In my oppinion debian is a lot about grassroots movements and people voting by working on something they like.
I would try to reglement as little as possible. We have enough bureaucratic rules, we need less, not more.
Err, I wouldn't. I think that would be a waste of time and detract from productive work on improving the distro. Areas that benefit from being documented can be without any enforcement required. I don't think any great encouragement is needed -- if people want to do that, they already can, and usually already do. I'm happy to suggest ways of talking to people cooperatively if they want explanations of how things work, so that it doesn't turn into "but if I tell you anything, you're just going to use it against me if I get busy later" or similar.
I wouldn't. I don't believe organizational charts are possible or practical in a large, ever-evolving volunteer project like Debian. I think we should make a best effort, but not sweat it. As long as the powerful positions like ftp master, new maintainer, people with root access and db access are documented and accountable, everyone else can get their stuff documented on an as-needed basis.
Enforcing documentation of roles and timetables is a little hard - we're volunteers! But certainly each of the teams should be encouraged to do this; I've often found in my own work that I don't truly understand something until I've tried to explain it to others. Part 1 of the task is to talk to each of the people involved right now, and try to get an honest assessment of what the roles entail and how things are proceeding. Part 2 is to actually try to get these things documented well enough that others in the project can understand them more readily. If help is needed on that documentation, I will try and find people to help. If no help is forthcoming, I will even pitch in myself.
I don't think this is raisonnable, let alone possible. New role and project get created litteraly every days. Some process could be better documented, but enforcing such a policy would be similar to rejecting every packages that does not include its full specification.
However I think it is a task "observers" might play a positive role, observers being people loking at a task without actively working on it.
I'm sure we could easily have a wiki page linking to the various project sites, but keeping track of every minute project change in a central place really doesn't sound like it would work. On a side note, major project timetable/membership changes should be added to Debian Weekly News.
I would simply work on the documention part myself, or with others if they volunteer. I already know a great deal about the various teams, and could pretty easily find out more that I need to know.
About staff changes, we're not a company. We are a project consisting of volunteers, volunteers who you don't just reassign at the snap of your fingers. I don't think there's any need to do that, either, but if there's percieved or real problems with a task, I'll look into it. I don't think it's ever a good idea to 'change' staff, but rather, to encourage teams to reinforce themselves with new members when the need arises, possibly starting out with trainees (such as release-assistants with limited privileges). By increasing transparancy, it is much easier also for new people to get involved and prove themselves.
People should generally only stop doing a task when they no longer are interested in it.