Andrew Deason <[email protected]> writes: > The fact that I have to assume those things and gather them from various > emails... <rant> _this_ is what makes this so aggravating all the time. > This is why there is so little interest, so little movement, so little > progress. This is why, while I believe standards work has some intrinsic > difficulty and tedium, this particular process currently seems > borderline impossible to participate in productively. </rant>
Keeping track of and communicating the state of documents is one of the things that the working group chair normally does in the IETF process. Again, I think this comes back to an issue of lack of time among the people in a position to do the work. Some IETF working groups delegate this work to a group secretary when the chair doesn't have time. If someone wanted to volunteer to maintain and communicate document state, I suspect the chairs would welcome that volunteer effort. My broader point here is that these process problems that you perceive all come *directly* from a lack of time and resources. These are the kind of process problems that just don't happen in standards working groups where there are multiple people actively engaged, because people will constantly ping state or will just start taking over work that goes undone and driving it forward when other people run out of time. However, the level of critical mass required to keep a standards process viable is much higher than the level of critical mass required to keep a software project viable. Standards processes will stall out completely in "everyone is waiting for everyone else to do something" modes at a much higher level of activity than software projects. With software projects, if there are only a few commits a month, one can still make some semblence of forward progress; with standards work, that just doesn't happen. The complaint that you have, that the process is opaque (or the related complaints that I've heard in other standards groups that the process is too heavy-weight or too burdensome), are standard symptoms of that failure mode. They happen with Debian Policy as well. But as soon as one manages to achieve critical mass, my experience is that those complaints almost magically disappear, either because people get familiar with the process by engaging in it regularly or there is sufficient critical mass to achieve consensus on changing the rules in ways that make things more efficient. That's why I believe those complaints, while real, are symptoms, not root causes. Again, I could be wrong, and I of course can't speak to the psychology of everyone participating here. I think the above is an informed opinion based on having done this sort of thing in a variety of different organizations, but it may well not apply, or I may be generalizing too much. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
