Subject: Adjustments to our work mode - please read

From: Mark Nottingham <[email-masked]>
Date: Mon, 5 Oct 2015 11:47:55 +1100

Everyone,

A number of folks have commented over the years about how it can be difficult to follow this mailing list. This is especially the case for HTTP implementers who don't have the time to focus on such a high-volume channel.

I've been concerned about this for some time, since it can be seen as biasing participation towards "professional" standards people, and away from implementers and users. So, to see if we can improve matters for those folks without significantly disadvantaging current participants, I've been talking to our Area Director about experimenting with the group's working mode. 

To that end, we're going to try allowing discussion and resolution of issues in the issue tracker itself, rather than requiring discussion there to be moved here -- thereby allowing people to participate without subscribing to the mailing list, if they don't want to. 

For details, see:
  https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md

This takes effect immediately for our current deliverables, whose issue list is here:
  https://github.com/httpwg/http-extensions/issues

If you want to track conversations there and have a Github account, you can click "watch" at the top of the patch to be notified of new comments, etc.

To make sure that those who don't wish to use the issue tracker aren't disadvantaged, we'll do a number of things, including:

- Summarise (with links) the design issues closed by each draft when it is announced on this list
- Allow issues to be re-opened when someone brings substantive new information (as always)
- Allow those who do not wish to use the issues list to comment on this mailing list
- Provide a separate, announce-only mailing list that is subscribed to every issue change, for those who do not want to use a github account to receive notifications. See: <https://www.ietf.org/mailman/listinfo/http-issues>

We'll review this approach on a continuing basis to make sure it's working.

Cheers,

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

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 05 Oct 2015 11:54:35 +0000

Mark,

On the whole I believe this is a reasonable experiment.

First, you are a chair and not a king. You should have proposed this to the group before acting.  Do other chairs get to pick and choose their rules?  

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.

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.

3.  Before you close an issue in GitHub, you should give fair warning on *this* list with a pointer.

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. 

Eliot

> On Oct 4, 2015, at 8:53 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Everyone,
>

---

From: Jason Greene <[email-masked]>
Date: Mon, 5 Oct 2015 11:28:35 -0500

> On Oct 4, 2015, at 7:47 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Everyone,
> 

FWIW, 

I am a recent implementor who has participated for a little over a year. I do not feel this list is in any way a high-volume channel, although it’s certainly true that in the case of a highly-debated topic, there is a brief, but manageable, spike. I imagine that anyone with the technical expertise necessary to participate in this forum also understands how to setup email filters. 

Overall, I appreciate the high-quality, thorough, and well structured comments that are sent to this list. I personally feel that github notifications would be a poor substitution. 

Thanks,

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2015 10:14:34 +1100

Eliot,

> On 5 Oct 2015, at 10:53 pm, Eliot Lear (elear) <[email-masked]> wrote:
> 
> Mark,
> 

Good.

> First, you are a chair and not a king.

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

> You should have proposed this to the group before acting.  Do other chairs get to pick and choose their rules?  

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

> 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 suf…

You're giving me a lot of hypotheticals, Eliot. If you have actual questions, I'm happy to answer them.

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

> 3.  Before you close an issue in GitHub, you should give fair warning on *this* list with a pointer.

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.

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

Regards,

---

From: Brian Smith <[email-masked]>
Date: Mon, 5 Oct 2015 13:43:18 -1000

On Sun, Oct 4, 2015 at 2:47 PM, Mark Nottingham <[email-masked]> wrote:

> Everyone,
>
> A number of folks have commented over the years about how it can be
> difficult to follow this mailing list. This is especially the case for HTTP
> implementers who don't have the time to focus on such a high-volume channel.
>

This is not a high-volume channel. Actually, watching the GitHub repo,
which would be required for participating in new discussion threads in the
issues and pull requests, will result in more volume than the mailing list,
because watching the GitHub repo results in the receipt of a lot of
automatically-generated mail.

> I've been concerned about this for some time, since it can be seen as
> biasing participation towards "professional" standards people, and away
> from implementers and users.

I would say that this change has more of a bias towards professional
standards people--people who attend the meetings--than the previous state
of things. If you look at the TLS WG as an example, the discussions on the
mailing list are much clearer to somebody who hasn't attended the meetings
than the issue tracker activity is.

> To make sure that those who don't wish to use the issue tracker aren't
> disadvantaged, we'll do a number of things, including:
>

Anybody that relies on the above three will be seriously disadvantaged
because their participation will have less impact. For example, if you wait
for an email that says a discussion of a design issue has been closed, you
are less likely to affect a change, compared to if you had participated in
the discussion earlier. Also, the people who choose to communicate via the
mailing list will inconvenience everybody else discussing things in the
issue tracker, and that inconvenience will result in bias against them.

> - Provide a separate, announce-only mailing list that is subscribed to
> every issue change, for those who do not want to use a github account to
> receive notifications. See: <
> https://www.ietf.org/mailman/listinfo/http-issues>
>

Note that GitHub comments can be edited and deleted after the fact, so it
is very important that the http-issues list be a reliable archive of all
the communication.

It is also important that the creation of new GitHub repositories be
announced at the time of creation, so that people can start watching them.

Note that this email isn't an objection to the change.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2015 13:29:57 +1100

> On 6 Oct 2015, at 12:50 pm, Eliot Lear (elear) <[email-masked]> 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.

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

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

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Oct 2015 07:45:13 +0200

Hi Mark!

On Mon, Oct 05, 2015 at 11:47:55AM +1100, Mark Nottingham wrote:
> Everyone,
> 
> A number of folks have commented over the years about how it can be difficult
> to follow this mailing list. This is especially the case for HTTP
(...)

Interestingly, I think that the list provides *notifications*, something
that is not provided at all by a web interface that you have to spontaneously
visit to see if anything new was posted on each and every subject of interest.

With e-mails you can process one at a time when you have some time. A few
minutes several times a day. Emails can be marked read or moved to an archive
for example. You can also easily see if you've responded already and you keep
threading. I'm not seeing these possibilities with an issue tracker. To be
honnest, I'm already predicting that I'll disappear from the discussions
that I used to discover (like this one), because I've mostly been reacting
to certain discussions, which will not happen anymore. But let's try.

I'm also seeing something which I'm not sure will be easy to handle. Till
now, some e-mail based discussions were split in several threads leading
to multiple issues being created and addressed in parallel. I don't know
if it will be possible to split issues into several ones, and even if
possible I'm not sure it will be as easy to review the history of an issue
as easily as it is with e-mail.

But I welcome the experiment! If it is easier to deal with for certain
participants (I'm still wondering how and why) and these participants
provide more value than what we lose from other ones, it can in the end
be positive. We don't know yet and that's the purpose of an experiment.

In fact it raises an interesting point. It has always been difficult to
track issues on the list, especially during "hot" discussions. It has
happened several times that after things calmed down, some issues were
restarted because someone (any of us) forgot the outcome due to many
proposals made. We've seen this even more on hybi where it was very hard
to agree on something and all of us were trying hard not to restart an
issue by fear of losing the very small value we were seeing in the outcome.

So it doesn't appear a bad idea at all to try to mix this with an issue
tracker. If the experiment goes well, maybe we should switch to one which
supports bidirectional e-mail. That provides everything we lose above
plus the archival. For instance I've been dealing with some bugs handled
by bugzilla on some sites and was using e-mail just as we do here, without
having to check every day on the site if something new was posted regarding
the issue I was interested in, nor searching it everywhere.

In the mean time I have no idea if it's possible to configure github to
automatically post an e-mail here (in addition to the new list dedicated
to issues) to indicate that an issue was updated (and ideally with a copy
of the contribution). Or maybe it would simply be better not to have a list
dedicated to issues only. The current list is already for issues, that's
what participants discuss all the day. I don't know either if it's possible
to block edition to ensure we never lose any contents just because someone
felt that something he said was stupid and preferred to remove it. The value
is often in ideas initially considered as stupid :-)

Overall this seems like a good idea to experiment with and the right timing
to try it. There's no emergency to deliver anything critical right now, we
can try different formats without the risk of losing people/value/time yet.

Cheers,
Willy

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 06 Oct 2015 01:51:09 +0000

Mark,

Eliot
> On Oct 5, 2015, at 7:14 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Eliot,
> 

I mean it.  It's a fine thing to try. But you can't break transparency. See below. 

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

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

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

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.  

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

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 06 Oct 2015 12:05:41 +0000

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 <[email-masked]> wrote:
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Oct 2015 09:18:27 -0700

> is very important that the http-issues list be a reliable archive of all
​Brian's comment caused me to go look at the archive, which is found here:
https://mailarchive.ietf.org/arch/search/?email_list=http-issues#

There is a bit of a problem using the new mailing list archive system with
the current method. As it stands, the mailing list archive truncates the
subject of the email after a certain point (apparently no matter what the
width of the window it won't go beyond a certain number of characters).
Because the issue numbers come at the end of the line, the issue number
drops off.  This is already visible in the archive, even though there are
only three messages.

Any chance we can massage github to move the issue numbers to the front?

Also, it was not entirely clear to me from the headers whether the mailing
list archive system threading will work correctly with these messages.  By
any chance, did you test that with another list?

regards,

Ted

---

From: Mike Bishop <[email-masked]>
Date: Tue, 6 Oct 2015 16:52:26 +0000

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:[email-masked]] 
Sent: Tuesday, October 6, 2015 5:06 AM
To: Mark Nottingham <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; Barry Leiba <[email-masked]>
Subject: Re: Adjustments to our work mode - please read

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Oct 2015 11:02:14 +1100

> On 6 Oct 2015, at 11:05 pm, Eliot Lear (elear) <[email-masked]> wrote:
> 
> 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. 

I explained that in the e-mail that you're responding to:

"""
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 have suggestions on how to improve the link's visibility, they're welcome.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Oct 2015 11:32:46 +1100

> On 7 Oct 2015, at 11:07 am, Eliot Lear (elear) <[email-masked]> wrote:
> 
> Where at that link do you discuss the interaction with the mailing list or anything else in that message?  Please quote because I can't find it, as I wrote. 

> - Summarise (with links) the design issues closed by each draft when it is announced on this list

From [1]: "When a new draft is published, the design issues that have been closed since the last draft will be highlighted on the mailing list, to aid reviewers."

> - Allow issues to be re-opened when someone brings substantive new information (as always)

From [1]: "If substantive new information is brought to our attention, issues can be reopened by the Chair."

> - Allow those who do not wish to use the issues list to comment on this mailing list

From [1]: "Design issues require discussion and consensus in the Working Group. This discussion can happen both in the issue and on the Working Group mailing list."

> - Provide a separate, announce-only mailing list that is subscribed to every issue change, for those who do not want to use a github account to receive notifications. See: <https://www.ietf.org/mai…

This is not in [1]. Do you think it should be there? I was planning on adding it elsewhere on the site.

So what exactly can't you find -- are you looking for something else that isn't above, or did you just fail to find the link even though I gave the title, or...? Please be as precise as you can, as I'm getting frustrated pointing out the same information to you repeatedly, and I don't *think* you're enjoying this either.

I have no doubt that [1] can be improved -- indeed, after some offline discussion with Ted, there are a number of ways I think we can make it a more friendly and complete document -- especially around how decisions are made (which is more about reminding people how consensus works in the IETF and relating that to the work mode). However, most WGs don't have any such document, so I'm finding it a bit ironic to hear you rail about "transparency."

Cheers,

[1] https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md

> 
> Eliot
> 
>> On Oct 6, 2015, at 8:02 PM, Mark Nottingham <[email-masked]> wrote:
>> 
>>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Oct 2015 17:45:07 -0700

(Sorry, everyone: I'm in all-day meetings for a few days, with limited
time to respond.  Of course, that's when things blow up, innit?)

Folks, we've gotten to the point of more heat than light here.  Mark's
response below is a good one, so let's consider leaving it for now,
modulo some specific suggestions for clarifications.  Here's why:

I want to stress that this is an *experiment* -- not an experiment in
the full-on RFC 3933 sense, but an experiment in running the process
of a single working group in a slightly different way.  Mark (and I)
will be watching how this works and will make sure that the mailing
list still has the information that's needed to keep track of what's
happening and to participate in the decisions.  That said, people who
don't want to get on github should also follow the http-issues list to
keep up with current discussions... which you can then respond to on
*this* list, if, again, you don't want to get on github.

There are two things on the bottom line here:

1. If this doesn't work well, we will stop doing it.

2. If this does work well, we will look at how to do it on a broader
scale, and that will involve more discussion with the community at
large, along with a git repository that's hosted on IETF servers, so
we're not dependent upon github.

The IESG has been talking for some time about how to engage better
with the open source community and with development communities in
general that have become used to collaboration tools other than email.
Trying this out in a limited way with one working group is a way to
see how these sorts of mechanisms can work in the IETF.

Let's give it a try.  Let's see how it goes.  And if we really don't
like it, we can stop -- we might have wound up creating some annoyance
in that case, but we will have also gotten some useful information.

Barry, ART AD

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 07 Oct 2015 00:07:43 +0000

Eliot

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 06 Oct 2015 18:19:39 +0000

At this point, just that Mark of incorporate what he wrote onto that that page, and that the mailing list be apprised when an issue is coming to closure. That last one is an "extra mile" sort of thing, given the process change.  But also see Ted's note.  

One more point: someone stated that comments can be edited. Is the edit history available!

Eliot

> On Oct 6, 2015, at 12:52 PM, Mike Bishop <[email-masked]> wrote:
>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Wed, 07 Oct 2015 00:49:49 +0000

Ok thanks.  

And I'm really sorry I missed it.  Twice. 

I'd still ask that you keep the mailing list informed as to the status of issues and when they are coming to closure.  There are many reasons for this. One is that it should be possible for people to work with intermittent connectivity.   Another is simply that many are not accustomed to GitHub. 

Most work in groups just follow the the established process of using email as 2418 discusses and so don't need this sort of stuff.  You are going beyond what was envisioned at the time.  Fine.  But that does require extra care and you've shown that you've gone to those lengths. 

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Oct 2015 17:55:02 +1100

Hi Ted,

I think you're talking about the first one, which was pushed out by the [http-issues] prefix. I've since removed that, reducing the likelihood of this happening.

Also, that appears to be only an artefact of the Web interface, not the e-mail list itself.

Cheers,

> On 7 Oct 2015, at 3:18 am, Ted Hardie <[email-masked]> wrote:
> 
> Note that GitHub comments can be edited and deleted after the fact, so it is very important that the http-issues list be a reliable archive of all the communication.
> 
> 
> ​Brian's comment caused me to go look at the archive, which is found here:  https://mailarchive.ietf.org/arch/search/?email_list=http-issues#
> 
> There is a bit of a problem using the new mailing list archive system with the current method. As it stands, the mailing list archive truncates the subject of the email after a certain point (apparently no matter what the width of the window it won't go beyond a certain number of characters).  Because the issue numbers come at the end of the line, the issue number drops off.  This is already visible in the archive, even though there are only three messages.
> 
> Also, it was not entirely clear to me from the headers whether the mailing list archive system threading will work correctly with these messages.  By any chance, did you test that with another list?
> 
> regards,
> 
> Ted
>