Resent-Message-Id: <E1ZjNXI-0002eN-VL@frink.w3.org>
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Content-Type: text/plain; charset=us-ascii
To: Mark Nottingham <mnot@mnot.net>
From: "Eliot Lear (elear)" <elear@cisco.com>
In-Reply-To: <34F87374-7033-4829-9F76-5415495BF3B0@mnot.net>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Tue, 06 Oct 2015 01:51:09 +0000
Cc: HTTP Working Group <ietf-http-wg@w3.org>,
 Barry Leiba <barryleiba@computer.org>
Content-Transfer-Encoding: quoted-printable
Resent-Date: Tue, 6 Oct 2015 10:23:39 +0200
Message-Id: <618B8FAA-2B75-49CD-8FB6-D5F9A6E055FD@cisco.com>
References: <9C939474-975C-4D12-8B78-E2A74264A9BD@mnot.net>
 <69B99EF5-364E-4BBA-A6AB-49543366EEE3@cisco.com>
 <34F87374-7033-4829-9F76-5415495BF3B0@mnot.net>
Resent-To: ietf-http-wg@w3.org
Subject: Re: Adjustments to our work mode - please read
Archived-At: <http://www.w3.org/mid/618B8FAA-2B75-49CD-8FB6-D5F9A6E055FD@cisco.com>
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list



Mark,



Eliot
> On Oct 5, 2015, at 7:14 PM, Mark Nottingham <mnot@mnot.net> wrote:
>=20
> Eliot,
>=20
>> On 5 Oct 2015, at 10:53 pm, Eliot Lear (elear) <elear@cisco.com> =
wrote:
>>=20
>> Mark,
>>=20
>> On the whole I believe this is a reasonable experiment.
>=20
> Good.

I mean it.  It's a fine thing to try. But you can't break transparency. =
See below.=20

>=20
>> First, you are a chair and not a king.
>=20
> Indeed; if I were a king, I wouldn't have to talk to the AD about it. =
There's also probably be a lot more "off with his/her head" around =
here...

Let's not get ahead of ourselves.=20

>=20
>=20
>> You should have proposed this to the group before acting.  Do other =
chairs get to pick and choose their rules? =20
>=20
> The responsibilities and authorities of a chair regarding process and =
communication seem very well-documented here:
> http://tools.ietf.org/html/rfc2418#section-6.1
>=20

Yes, well. Please read the REST of that document.  It is speckled with =
references to how EMail should be used and in what circumstances. Want =
to vary from that?  Fine.  But document what you're doing.=20

>=20
>> Had you consulted the group first, someone might have asked the =
question about how those coming into the group anew would understand the =
process. Others might have asked about whether GitHub is sufficient for =
archival purposes.  Others might have asked how easy it would be to =
manage two parallel discussions on the same issue.
>=20
> You're giving me a lot of hypotheticals, Eliot. If you have actual =
questions, I'm happy to answer them.


New people coming into the group is a hypothetical, is it?  Having two =
parallel discussions is hypothetical?  But the point is really that you =
didn't consult the group and should have done. This is not a small =
change, though probably a useful one.

>=20
>=20
>> Anyway, what I ask at this point is four things:
>>=20
>> 1.  The charter of the group should indicate the procedures being =
used.=20
>>=20
>> 2. Those procedures should be documented in a draft.
>=20
> Nothing in the IETF process that I can see requires such a level of =
bureaucracy. While I can see the point of doing so if this work mode =
"sticks" over time, requiring us to do so just to perform an experiment =
is busy work. =20
>=20

Because sticking your email in a draft and pointing at it is so hard.   =
Come on.

Transparency requires that people be able to know what the rules are. =
Because you're using an additional communication path that is not =
documented elsewhere it's on you to ensure people aren't surprised and =
that people know when issues are going to be closed and what the =
resolution is.  That makes a result stronger. =20

Pragmatically how do you expect someone coming into this wg from another =
wg or a new participant  to understand how things work?  And what if you =
change things further?  Shall Mark's Rules be a collection of emails =
that must be parsed and diffed?=20

>=20
>> 3.  Before you close an issue in GitHub, you should give fair warning =
on *this* list with a pointer.
>=20
> As mentioned, issues can always be reopened, and will be summarised =
for each draft as we've often done in the past. In practice, I suspect =
that contentious (or potentially contentious) issues will be at least =
canvassed here before they're closed anyway

To be clear: that document you quoted expects two types of =
communication:  mailing lists and meetings. You are adding a new type. =
That is fine, but there are a lot of words around how mailing lists get =
to review other decisions.

>=20
>=20
>> 4.   Finally, you have repeatedly and needlessly used derogatory =
language toward those who have worked hard for *this* organization. I =
think you owe that group an apology.=20
>=20
> You've lost me, Eliot. How have I done so? Have I offended *you*, or =
are you just concerned on behalf of others?

I'd like to know who you think you're talking about when you use the =
term "professional" standards people,  juxtaposed against users and =
developers.    It sounds to me that you are referring to those who have =
done a lot of work in and for this organization-  as if they aren't =
developers or users or should have less voice in the process because =
they've been around.  Yes I'm in that class. It was wrong of you to put =
it in those terms.=20

I imagine what one would politely say is that the process is not =
inviting to the class of developers we need for this WG to succeed, and =
that they are more comfortable using GitHub. =20

And as I wrote above that's fine. Just document what you're doing and =
give those using email notice when you are going to make a decision.  =
How hard can that be?


Eliot