- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 Oct 2015 10:14:34 +1100
- To: "Eliot Lear (elear)" <elear@cisco.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Barry Leiba <barryleiba@computer.org>
Eliot, > On 5 Oct 2015, at 10:53 pm, Eliot Lear (elear) <elear@cisco.com> 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 <mnot@mnot.net> 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/
Received on Monday, 5 October 2015 23:15:03 UTC