RE: Adjustments to our work mode - please read

The process is on https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md, which is prominently linked from the WG repo's home-page (http://httpwg.github.io/).  If I understand your suggestion correctly, you're advocating that there also be a prominent link from http://datatracker.ietf.org/wg/httpbis/?  Or if not that, then from which page?

Personally, I didn't find Mark's tone offensive.  Referring to "professional" standards people is simply an acknowledgement that some of us are able to earn a living or part of one by participating actively in this working group, while others are participating out of passion in their personal time.  Those of us who are professionals contribute a lot of value, and I haven't heard anyone disputing that.  If there's a way to make it feasible for even more people to contribute on an equal footing, I think that's a worthy goal.

Myself, I think the lack of travel funding to attend IETF meetings and interims in person is a higher barrier than requiring them to subscribe to a moderate-volume mailing list.  We make a lot of progress in meetings, which is supposed to be subordinate to WG consensus on-list, but the in-person meetings are often treated as conclusive and attendance is highly tilted toward those of us who have an employer footing the bill.  To that end, I value the IETF's investments in remote participation options.  But if there's consensus in IETF leadership that the mailing list itself might be a barrier, I'm willing to try an alternative.

-----Original Message-----
From: Eliot Lear (elear) [mailto:elear@cisco.com] 
Sent: Tuesday, October 6, 2015 5:06 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>; Barry Leiba <barryleiba@computer.org>
Subject: Re: Adjustments to our work mode - please read

Thank you for your apology. 

To be brief, Mark, what I want to be able to continue to tell governments that we operate in a bottom up community driven manner where we use the same rough consensus approach to approve standards as well as processes, that our processes are well documented, and that everyone has an opportunity to participate.  Don't make that hard for those of us who do that by not documenting what you are doing.  The points I made were pretty much straights from OpenStand principles, amongst others. 

You  don't even have to convert to 77 character ASCII since your mailer did that for you ;-).  Honestly if you put up that process on your GitHub home page I'd be satisfied (if it's there I can't find it).  Better to make clear through IETF mechanisms that people from other WGs are used to. 

You raised an IPR issue. I think counsel already looked at least some aspects that, if memory serves, but that really isn't my department.  Check with the IAOC if you wish. 

Eliot

> On Oct 5, 2015, at 10:30 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
>> 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 16:53:02 UTC