[AFS3-std] Re: IBM will not re-license OpenAFS .xg files

[Russ Allbery]

Andrew Deason <adeason@sinenomine.net> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>