Re: Robert's rules (Re: [ga] Blockage/delay of postings)

["Mark C. Langston" <skritch@home.com>]

On Fri, Jan 07, 2000 at 08:23:39AM -0800, Mark C. Langston wrote:
> 
> http://www.dnso.org/wgroups/wg-d/Archives/msg00223.html
>   covers the substantial motions, gives analysis, and justification for
>   adoption or rejection of each.

I'd also like to point out that much of what I proposed here has been
independently implemented in other WGs, e.g., WG-C's "position papers"
are identical to the "limit or extend limits of debate" Motion.

Finally, I'd like to speak to something I've noticed which concerns
me: The perceived awkwardness of parliamentary procedure.  Yes, when
it's initially implemented, it can be a bit awkward, because not
everyone is familiar with the procedure.  However, over time, it
becomes second nature.  When you make a Motion, you don't always
formally announce, "I would like to make a motion: The motion is
$FOO".  Instead, work proceeds apace, and as long as it's implicit
that what one is doing falls within the framework of Motions that are
currently in order, the formality disappears.  Usually, in a Body that
has adapted itself to parliamentary procedure, the 'formality' is
evidenced only when there is contention among the members of the Body,
or between the Body and the Chair.  When people work together, you'd
be hard-pressed to distinguish the language from current WG
practice...of course, the work itself may seem more organized due to
the parliamentary framework.

Don't misunderstand me, however: The formality is there, and it's
there for clarity's sake; when someone is being contentious, it
behooves everyone to be very clear about what's occurring.
Parliamentary procedure buys us all something ICANN sorely lacks: A
set of rules agreed to by all participants within which everyone will
work, and within which lay a rigid set of procedures for doing things
and handling disputes.  In short, it eliminates the "we'll do things
this way for now, and then we'll change them completely for this
thing, and now we'll handle problems in this way, since someone
brought one to our attention..." process we've been subjected to by
the NC in various aspects of the DNSO's work.  Everyone might not
agree with all the rules, and everyone might not be happy with the
outcome, but the rules are stark, clear, and available well ahead of
time.  There is also the comfort in knowing that the NC won't change
them at the last minute, or ex post facto.  

The ruleset I propose would bind not only WGs, but all aspects of
effort within the DNSO, from the NC to the GA to the WGs (the
Constituencies would be free to adopt them or ignore them for work
within their respective Bodies, however).  In short, things would be
done by a particular set of procedures, would be done correctly, and
would be done in a way that all the participants have a means of
calling into question the process as it unfolds, to ensure fairness
and equity.

As I mentioned in one of the documents I referenced earlier, the
formality and procedure introduced with contention also acts in an
interesting way as its own check against contention: Many people don't
like the added formality, and so they tend to attempt to work together
amicably to avoid its introduction.

As I read through the documents, I realized I never bothered to write
the document detailing the powers and responsibilities of a Chair --
mainly because no one seemed to care about the proposal, and it took a
lot of effort to whittle down a >100-page document to a few pages.  If
there's actually interest in this now, I could be talked into writing
that document.  It's crucial that it exist if these are going to be
considered, since this document would include the powers of censure
and expulsion, two topics that have been the center of discussion on
this list for the past few weeks or so.

However, don't expect me to do the work just because as things now
stand the proposal is incomplete.  I've come to see very little value
in contributing my time to ICANN, and I'm not about to sit down and
write it 'just because'.  If these stand a serious chance of being
adopted, I'll consider it.

-- 
Mark C. Langston
mark@bitshift.org
Systems Admin
San Jose, CA