Adjustments to our work mode - please read

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Adjustments to our work mode - please read

Mark Nottingham-2
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/


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Eliot Lear (elear)
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 <[hidden email]> 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.
>
> 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/
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Jason Greene
In reply to this post by Mark Nottingham-2

> On Oct 4, 2015, at 7:47 PM, Mark Nottingham <[hidden email]> 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.
>
> 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.

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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Mark Nottingham-2
In reply to this post by Eliot Lear (elear)
Eliot,

> On 5 Oct 2015, at 10:53 pm, Eliot Lear (elear) <[hidden email]> wrote:
>
> Mark,
>
> On the whole I believe this is a reasonable experiment.

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 sufficient for archival purposes.  Others might have asked how easy it would be to manage two parallel discussions on the same issue.

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


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


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


>
> Eliot
>
>> On Oct 4, 2015, at 8:53 PM, Mark Nottingham <[hidden email]> 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.
>>
>> 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/
>>
>>

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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Brian Smith-19
In reply to this post by Mark Nottingham-2
On Sun, Oct 4, 2015 at 2:47 PM, Mark Nottingham <[hidden email]> 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:

- 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

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
--
Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Eliot Lear (elear)
In reply to this post by Mark Nottingham-2


Mark,



Eliot

> On Oct 5, 2015, at 7:14 PM, Mark Nottingham <[hidden email]> wrote:
>
> Eliot,
>
>> On 5 Oct 2015, at 10:53 pm, Eliot Lear (elear) <[hidden email]> wrote:
>>
>> Mark,
>>
>> On the whole I believe this is a reasonable experiment.
>
> Good.

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

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

Let's not get ahead of ourselves.

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

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.

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

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

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?

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

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.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Mark Nottingham-2

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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Willy Tarreau-3
In reply to this post by Mark Nottingham-2
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
> implementers who don't have the time to focus on such a high-volume channel.
(...)

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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Eliot Lear (elear)
In reply to this post by Mark Nottingham-2
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 <[hidden email]> wrote:
>
>
>> On 6 Oct 2015, at 12:50 pm, Eliot Lear (elear) <[hidden email]> 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/
>



Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Ted Hardie-2
In reply to this post by Brian Smith-19
On Mon, Oct 5, 2015 at 4:43 PM, Brian Smith <[hidden email]> wrote:
- 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.


​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

Reply | Threaded
Open this post in threaded view
|

RE: Adjustments to our work mode - please read

Mike Bishop
In reply to this post by Eliot Lear (elear)
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:[hidden email]]
Sent: Tuesday, October 6, 2015 5:06 AM
To: Mark Nottingham <[hidden email]>
Cc: HTTP Working Group <[hidden email]>; Barry Leiba <[hidden email]>
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 <[hidden email]> wrote:
>
>
>> On 6 Oct 2015, at 12:50 pm, Eliot Lear (elear) <[hidden email]> 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/
>




Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Eliot Lear (elear)
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 <[hidden email]> wrote:
>
> 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:[hidden email]]
> Sent: Tuesday, October 6, 2015 5:06 AM
> To: Mark Nottingham <[hidden email]>
> Cc: HTTP Working Group <[hidden email]>; Barry Leiba <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>>
>>> On 6 Oct 2015, at 12:50 pm, Eliot Lear (elear) <[hidden email]> 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/
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Mark Nottingham-2
In reply to this post by Eliot Lear (elear)

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


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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Eliot Lear (elear)
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.

Eliot

> On Oct 6, 2015, at 8:02 PM, Mark Nottingham <[hidden email]> wrote:
>
>
>> On 6 Oct 2015, at 11:05 pm, Eliot Lear (elear) <[hidden email]> 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.
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>



Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Mark Nottingham-2
> On 7 Oct 2015, at 11:07 am, Eliot Lear (elear) <[hidden email]> 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.

The points from my original e-mail were these:

> - 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/mailman/listinfo/http-issues>

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 <[hidden email]> wrote:
>>
>>
>>> On 6 Oct 2015, at 11:05 pm, Eliot Lear (elear) <[hidden email]> 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.
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>

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


Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Barry Leiba-2
(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


On Tue, Oct 6, 2015 at 5:32 PM, Mark Nottingham <[hidden email]> wrote:

>> On 7 Oct 2015, at 11:07 am, Eliot Lear (elear) <[hidden email]> 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.
>
> The points from my original e-mail were these:
>
>> - 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/mailman/listinfo/http-issues>
>
> 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 <[hidden email]> wrote:
>>>
>>>
>>>> On 6 Oct 2015, at 11:05 pm, Eliot Lear (elear) <[hidden email]> 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.
>>>
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>
> --
> Mark Nottingham   https://www.mnot.net/
>

Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Eliot Lear (elear)
In reply to this post by Mark Nottingham-2
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

On Oct 6, 2015, at 8:32 PM, Mark Nottingham <[hidden email]> wrote:

>> On 7 Oct 2015, at 11:07 am, Eliot Lear (elear) <[hidden email]> 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.
>
> The points from my original e-mail were these:
>
>> - 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/mailman/listinfo/http-issues>
>
> 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 <[hidden email]> wrote:
>>>
>>>
>>>> On 6 Oct 2015, at 11:05 pm, Eliot Lear (elear) <[hidden email]> 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.
>>>
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>
> --
> Mark Nottingham   https://www.mnot.net/
>



Reply | Threaded
Open this post in threaded view
|

Re: Adjustments to our work mode - please read

Mark Nottingham-2
In reply to this post by Ted Hardie-2
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 <[hidden email]> wrote:
>
> On Mon, Oct 5, 2015 at 4:43 PM, Brian Smith <[hidden email]> wrote:
> - 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.
>
>
> ​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
>

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