Re: Adjustments to our work mode - please read

> On 6 Oct 2015, at 12:50 pm, Eliot Lear (elear) <elear@cisco.com> wrote:
> 
> 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. 

I have read it, Eliot, and we have documented it. You seem to be disputing the form that this documentation takes. As I've explained, I don't think it's appropriate to write this up as a draft YET -- we're just experimenting. Give it time.


>>> Anyway, what I ask at this point is four things:
>>> 
>>> 1.  The charter of the group should indicate the procedures being used. 
>>> 
>>> 2. Those procedures should be documented in a draft.
>> 
>> 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.  
>> 
> 
> Because sticking your email in a draft and pointing at it is so hard.   Come on.

So, you're seriously causing a fuss because you want this formatted as 77-column ASCII? Are you worried about IPR on the contribution policy? 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.  
> 
> 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? 

You're getting pretty far off base with the allegations here. It is documented, on our WG home page - <https://httpwg.github.io/>, currently linked as "How to Contribute - start here" (as well as from the navigation bar from every page on that site). We regularly show the home page link at our meetings, it's easily found by any search engine, and it's linked from our charter.

If you think that's not sufficient, perhaps you could help us improve the quality of our documentation.


>>> 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. 
>> 
>> 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. 

You're throwing around words like "wrong" quite freely, Eliot. I apologise if any offence was found, but know that none was intended, and frankly I think you're reaching pretty far to find it.


> And as I wrote above that's fine. Just document what you're doing

Already done. See above.


> and give those using email notice when you are going to make a decision.  How hard can that be?

Eliot, this isn't a big divergence from the past work mode of this group, when editors would often propose issue resolutions in drafts, we'd mark them provisionally closed, and then that would be confirmed once the draft is published, reopening if necessary to discuss. We did that for may issues in the BIS drafts, and some in HTTP/2, if recollection serves. This was with full knowledge of the WG and the ADs, and the quality of documentation for that was considerably worse than what we have here. There were no complaints that I can recall.

We already link to the issues list for pretty much everything we discuss, and record state there. 

All that we're doing here is allowing discussion in the issues list to have "official" weight on decisions, in addition to discussion here, and documenting how that's accounted for. Practically speaking, the only change will be that we'll no longer have to tell people to "move it to the list" when they comment on the issues list.

I will still be polling the list for consensus and input on design issues; if the resolution is non-obvious, I have no doubt we'll still discuss it on the list. If you've noticed, I almost always announce design issue resolutions over here too. None of that was documented last week, and yet you seem to be assuming that it will stop.




--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 6 October 2015 02:30:27 UTC