Re: When to DISCUSS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Spencer" == Spencer Dawkins <spencer@xxxxxxxxxxxxx> writes:

    Spencer> - It is probably helpful to include a reference to a
    Spencer> - One point I took away from the recent chat about IANA
    Spencer> registration on this list is that a substantial portion
    Spencer> of the community thinks that when the IESG speaks, the
    Spencer> IESG has spoken.

    Spencer> I understand that the term "discuss" is chosen
    Spencer> intentionally (there is no "how long have you been
    Spencer> smoking crack?" ballot option), and believe that the IESG
    Spencer> actually expects the authors/editors/working group
    Spencer> chairs/working group to "discuss" the draft with the
    Spencer> AD/IESG, but I believe that a significant portion of the
    Spencer> community hears "discuss", they think the IESG means
    Spencer> "Discuss" (capitalized for emphasis), or maybe even
    Spencer> "DISCUSS" (the IESG equivalent of a bullet through the
    Spencer> forehead), and they start randomly changing text or
    Spencer> otherwise folding up like cheap furniture, instead of
    Spencer> expressing what the working group was trying to do in the
    Spencer> DISCUSSed text.

YES!  It's very frustrating to me when I ask a blocking question and
get a note saying that "the new draft addresses your discuss."  I have
to figure out what changed and then try to imply an answer to my
question.  I'd much rather have a dialogue.


    Spencer> I would suggest one paragraph that says something like
    Spencer> "when we say "discuss", we mean this in the common
    Spencer> English sense, even if we spell it in all caps, and we
    Spencer> really do want a dialog, not random changes to a
    Spencer> specification in the hopes of placating us and getting
    Spencer> the DISCUSS removed".

Yes.

    Spencer> This would naturally fit at the beginning of Section 4
    Spencer> failure.

    Spencer> - I'm not sure I "get" 3.3 ("saying no to a document"),
    Spencer> for these reasons:


Section 3.3 is mostly my fault so I'll try and defend it.

The fact is that there is some possibility an AD will want to try and
convince the IESG that a document is so bad it should not be
published.  If we don't clearly document suggestions on how to do
this, a lot of bad things will happen.  First, in the middle of trying
to deal with a specific document we'll be debating what procedures to
use.  People will be more upset about the process issues than the
actual technical issues.  Things will take a lot of time and they will
not be efficient.  Instead, what I'd like to do is have suggestions
written down ahead of time on how to behave so that we can quickly
determine how the IESG as a whole feels about the document.  If more
than 4 ADs don't want to see the document  go forward, then clearly we
need to spend some significant time on it.  (passing a document
requires 9 ADs on the current IESG).  If only 1 person feels the
document should be stopped and the other ADs have already carefully
considered    the issue, well, we run on rough consensus.  

    Spencer> (1) If the irritated AD votes "abstain", the document
    Spencer> doesn't say what the resolution path is - is the idea
    Spencer> that some other AD who didn't write the comments reads
    Spencer> them and votes "DISCUSS - Marvin's comments are right, or
    Spencer> you need to explain why they are not right"? Or is an
    Spencer> ABSTAIN with very irritated comments somehow a special
    Spencer> state?

Generally it's a special state: you are mostly admitting that you are
part of the rough rather than the consensus and you expect the
document to go forward despite your objections.  The only case this is
not true is when too many people vote abstain.

    Spencer> (2) The ABSTAIN path (assuming that (1) is explained
    Spencer> fully) seems entirely sufficient, without adding the
    Spencer> "However" path, where the irritated AD writes the
    Spencer> comments and still votes DISCUSS. How strongly does the
    Spencer> IESG feel about this? To me, it is edging toward "IESG as
    Spencer> protector of the universe", but it assumes that the AD
    Spencer> can't convince anyone else to vote DISCUSS (or whatever
    Spencer> the path through (1) is). The DISCUSS path seems like the
    Spencer> weakest part of this very good 00 draft. But maybe I just
    Spencer> don't understand the path through (1) well enough to
    Spencer> understand the difference between the ABSTAIN option and
    Spencer> the DISCUSS option.

So, I at least feel really strongly about the discuss path.  The
problem with the abstain path is that part of forming consensus is
taking the time to understand the people you disagree with.

I want the opportunity to stop the document for a week or so--possibly
a bit longer--to try and explain to others why it is broken.
Practically speaking the way to do that on our ballots is a discuss.
I should only use this discuss to get an opportunity to explain my
position and to work with people to make up their minds.  I should do
something else with my discuss as soon as any of the following are
true: the discussion is not making progress, everyone understands me
and has made up their mind, or too much time has passed.  I don't
think specific time limits should apply, but I think the chair of the
IESG should be very sensitive to claims from the document authors and
the proponents of the document on the IESG that the discussion has
dragged on too long.

If I had started with an abstain, I would not have been given this
opportunity.  People would probably read my abstain comments, but in
general abstain comments do not even get discussion in the telechat.

Once the discussion is done, I can do one of two things.  In most
cases I'll want to change my vote to an abstain.  The outcome is
probably reasonably clear and I'll either have convinced enough people
or not.

However another thing I could do is insist on an override vote.  The
reason I would do that is that an override vote has different voting
criteria than a normal vote.  It takes 5 ADs to say no to a document
on a normal vote and 3 on an override vote.  I don't think it would be
wrong to use the override mechanism provided that  you did it quickly
and did not use it as a delaying tactic.

    Spencer> (3) The description of the ABSTAIN path says "writes up
    Spencer> the comments", and the description of the DISCUSS path
    Spencer> says "explain his or her position as clearly as possible
    Spencer> in the tracker". Is this really different, or just the
    Spencer> kind of thing that happens the week before the 00 cutoff?

Text written by different authors.


    Spencer> (I know it happens in MY 00 drafts!) I still wish there
    Spencer> was some reference to the comments on this evil, evil
    Spencer> draft actually appearing in the mailing list that is
    Spencer> theoretically the archive for discussions about the
    Spencer> specifications produced by the working group, but let's
    Spencer> let that lie for now.


I'm not sure this draft is the right place for that discussion but I
completely agree with you.

    Spencer> - The first paragraph in Section 4 is more specific than
    Spencer> "the people who need to discuss the draft, discuss the
    Spencer> draft", but not a lot more specific. I understand that
    Spencer> many possible combinations of AD/ADs/IESG and
    Spencer> editor(s)/working group chair(s)/working groups may end
    Spencer> up as parties to the discussion, but I would like to see
    Spencer> text that finally assigns responsibility for negotiating
    Spencer> DISCUSS resolution to SOMEbody (not sure I care who). If
    Spencer> there was a sentence that says "DISCUSSes are supposed to
    Spencer> be serious and relatively rare, so DISCUSS resolutions
    Spencer> should be posted to the appropriate mailing lists before
    Spencer> the document appears on the next IESG telechat agenda",
    Spencer> that would be lovely. Other sentences with other nouns
    Spencer> might be lovely as well.

The proto shepherd (or document shepherd for non-proto documents) is
responsible for making sure progress happens on resolving discussions.
I'd assume that you would complain to the document shepherd and/or
IESG chair if the process is failing.


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]