ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Does someone knows the REAL rules?



Dear fellow GA members,

I for one appreciate Joanna and Bill's work very much
and hope that the GA has the courage to look at the
Best Practices proposal in an unbiased way.

I know that some if not many GA members are extremely
wary of unconfirmed new rules and self-styled officers
(and rightly so!). What Bill and Joanna have been and
are doing is a voluntary, inofficial contribution, and
I haven't seen them claim that their proposal *are*
the new list rules. But there are, in my view, some
good reasons to at least try out the proposed Best
Practices when all documents are ready.

Personally, I think the GA status quo is lamentable,
measured in terms of the contribution it makes to the
overall ICANN policy process. There are numerous
reasons for that which have been mentioned over and
over again, but the lack of a formalized way of
turning vague suggestions into a useful motion is
certainly one of them. The Best Practices documents
is /one/ possible approach, and it may turn out to
be too simple, too complicated, too slow, too
shallow etc. We will not know unless we dare to put
it to the test.

William X Walsh wrote on 15.08.01, 21:22:15:
> I consider constant attempts to rephrase issues being discussed here
> into "BP-eze" to be very close to what Jefsey is referring to here.

William, if by "BP-eze" you mean that you dislike the
overuse of CAPITAL LETTER WORDS, we are on the same
page. (Capital Initial look far more elegant. ;))
We have the problem that there currently are no
"real" rules when it comes to developing a motion.
The answer to that is: Let's define the requirements
and process for developing a motion. Let's have
definitions for the most important terms. And when
we have them, let's see if they work or not. If they
seem to work, let's adopt them and e.g. when referring
to a motion that fulfils such requirements, we can
speak of a Motion. I think we desperately need some
shared definitions of what we are doing here. Just
like the RFCs often say
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
 and "OPTIONAL" in this document are to be interpreted
 as described in RFC 2119.

Finally, I hope that anyone who finds or writes
documents which seem to be equally clear and suitable
as guideline comes forward. I know there are other
sets of rules, e.g. Mark Langston's modified version of
Robert's Rules of Order at
  http://www.bitshift.org/archives/rror.shtml
Frankly, I think it is a bit too complicated (including
the wording, considering the international context),
and the question of time limits (which seems
especially important in our context) is not solved
in a satisfactory way.

What I've seen from the Best Practices proposal makes
me want to see it work in practice. I cannot see how
such a test could cause further damage which isn't
already there in this highly divisive, sometimes
merciless and aggressive environment.

Best regards,
/// Alexander
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>