ietf
[Top] [All Lists]

Re: draft-moonesamy-ietf-conduct-3184bis

2013-08-31 16:52:03
Along with the other recent drafts for streamlining the RFC process, I get the feeling even this new drafting on conduct is simply going to be a new rubber stamping tool to shut down the process of due diligent engineering discussions, required cross areas reviews, including increasing conflict of interest concerns.

There is a lost of engineering diversity when there is a lack or lost of industry representation. Folks who shy away, turned off or excommunicated based on leveraging conduct policies, we get a behavior I call "Consensus by Osmosis" -- rough consensus, higher potential for appeals and huge LC debates.

Too much rough consensus conclusions left to the WGLC and IETF LC that should and can be worked out before hand.

Ideally, I would like to see new external "APPEAL-LIKE" paths ("Instant Replay Timeouts viewed by people in the booths") to help, settle, minimize serious issues in a WG before WGLC and IETF LC begins.

Perhaps this draft should has some statements about what is expected of the project leaders in the area of processing participant inputs. I think the draft should also define or describe:

   - Participants
   - Individuals
   - Project Leaders  (AD, CHAIRS, EDITORS?)

Ideally, proper professional conduct should include an expectation the leaders will be not be ignoring participants, individuals, industry peers and vice versa, of course.

--
HLS

On 8/31/2013 3:58 PM, S Moonesamy wrote:
At 11:02 31-08-2013, Melinda Shore wrote:
It seems like this would be a good time for an update.  A few
comments:

. I think there are a few things that we've been taking for
  granted that everybody knows, because they did, but that
  may not longer be the case and consequently they should be
  made explicit.  One that really popped out at me while
  reading this is that we may need to be clearer that people
  are participating in the IETF as individuals and
  contributions are evaluated in that light

Yes.

. I'd like to see some mention of consensus-seeking behavior;
  that is to say, we make decisions on the basis of rough
  consensus and so the goal of discussion should be to build
  consensus rather than to "win."

As a quick reply, it may be possible to put that under Item 2 in
Section 2.  My preference would be to pick a comment from Ted Lemon {1]:

   "Not trying to figure out if what they said meaningfully
contradicts your
    own position, and not making a sincere effort to determine if they
might be
    correct in contradicting your position."

and use the above to mention "sincere effort".

. I'm not 100% comfortable with the concept of "violating
  guidelines

I added that based on a comment from Lars Eggert [2].  The word
"breach" may be more appropriate.  I should have used the word
"consequences" for Appendix B.

. I think it was a good idea to remove text that could be
  discouraging to new participants.

There was a comment from Lars Eggert [3]:

   '"when you begin to participate in a WG, maybe approach the chairs or
    longer-term participants in order get a view on whether the issues
    you wish to discuss fit the current work of the group."
    Rationale: I HAVE seen newcomers raise issues that were either
outside
    the scope, or raise them in ways that got them a bad reception, and a
    little caution about how to get the best result is IMO good.'

My preference is for that to be part of the Newcomers tutorial and/or
the Tao instead of a guideline for conduct.

At 11:15 31-08-2013, Phill wrote:
I think it would be useful to point out that there is a big
difference between getting a draft published as an RFC and getting
the proposal deployed.

The point of the IETF process is that it provides an opportunity to
build the consensus necessary to deploy the proposal. The consensus
is the real product, the documents are secondary.

It would be better to discuss the above as part of the tutorial material.

It is also the case that some consensus matters more than others. A
proposal cannot be deployed without the support of people who write
code and operate infrastructure that must be changed. So people who
work to effect a back room carve up that cuts those people out of
the process are wasting everyone's time

Proposals which do not have the support of the people who write the
code tend to be ignored by the people who write the code.

At 11:15 31-08-2013, Dave Crocker wrote:
Might be worth referencing Pete Resnick's draft; at this point,
casting it as one person's 'exploration' of the concept might avoid
taking it as official, while still treating it as useful.

My preference is to use "sincere effort".  I'll wait for Pete Resnick
to argue why his draft should be referenced. :-)

By way of operationalizing the idea of discussing-to-build-consensus
might be emphasizing both explanation -- to help people understand a
view -- and modification -- to adjust the view based on feedback.

I think that it would be good to have a discussion of that draft when
Pete Resnick says that it is ready for discussion.

A characteristic of talking to win, rather than explore, is having a
very rigid manner of making comments, essentially only re-stating a
point.  By contrast, real discussion incorporates comments being
made, rather than merely seeking to refute them.

The problem may be that it is not clear whether the point will be
considered as valid.  There may be a view that restating a point is
useful or else the point will be noticed.  In a long thread some
points do get missed.  I'll mention an interesting comment:

  "I almost always get at least some private responses, and they inflict
   discomfort often enough for me to not enjoy this communication mode"

It is not possible to have a real discussion if people do not feel
comfortable to discuss.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ietf/current/msg81864.html
2. http://www.ietf.org/mail-archive/web/diversity/current/msg00222.html
3. http://www.ietf.org/mail-archive/web/diversity/current/msg00209.html
4. http://www.ietf.org/mail-archive/web/diversity/current/msg00243.html