On 11-Oct-19 05:05, Ben Campbell wrote: > Here’s an attempt to distill my concern a little better: > > The “dispatch process” can reasonably be thought of as a triage process. Triage makes sense when you don’t have the time and resources to address every problem and have to pick and choose where you can have the most impact. If you do have time and resources to address everything, then triage is just a process bump. > > Do we believe that GEN area proposals will routinely exceed our capacity to discuss them? If so, do we think that will continue to be true for the foreseeable future? (I assume this is intended to be a long-lived wg). I think that we have never really had a problem handling minor process fixes. That's why we have so many process-related RFCs, in fact. For those, GENDISPATCH will clearly help us do the triage a bit more systematically, and that is a Good Thing. Where we've had a problem, for the last 20 years, is in achieving major process changes. Actually we haven't really had any, except RFC 6410. IMHO all the other updates to RFC 2026 were clarifications and tuning. (Of course opinions on this may vary.) And even that change was really a rather late recognition of reality. For major change to occur, we need a strong community will and a flexible IESG. GENDISPATCH won't automatically achieve that, because there's a tendency to put proposals for major change on the "too hard" heap. But at least GENDISPATCH offers a mechanism for discussing proposals for major change, and that too is a Good Thing. Regards Brian > > Thanks! > > Ben. > > >> On Oct 8, 2019, at 5:19 PM, Ben Campbell <ben@xxxxxxxxxxx> wrote: >> >> >>> On Oct 8, 2019, at 5:06 PM, Mark Nottingham <mnot@xxxxxxxx> wrote: >>> >>> Anecdata - >>> >>> I made a proposal at the plenary mic in Montreal for a separate last-call@ list. I'd made that proposal at least twice before to iesg@ in the past, but it never got traction, until it was suggested I bring it up at the mic. Once it got some support in the room, the IESG went away and came up with a fully-baked proposal for an experiment in the community. >>> >>> Under GENDISPATCH, I would have taken the proposal there (I didn't take it to ietf@ because it was too focused on other issues, and I didn't see it as likely to gain traction there). It would have been discussed and presumably we would have developed a proposal in the open, guided by the chair(s). >> >> I don’t disagree with any of your points. But keep in mind that, according the proposed charter, GENDISPATCH would develop a problem statement, context, and assess the level of interest, then pass the work on somewhere else for the developing a solution part. For some things that can help focus thinking. For others it can become yet another process speed bump. For relatively self-contained proposals like the one you suggest, I suspect it may be more of the latter. >> >>> >>> I think that's a better outcome; certainly, as someone who wants to suggest a change to the process, GENDISPATCH is more straightforward and requires less "inside" knowledge. >> >> That’s a pretty good point—it’s possible that GENDISPATCH could become a well-known entry point, with less guessing about who one needs to talk to to promote an idea. DISPATCH has occasionally had complaints from people from areas that don’t use the dispatch process because it doesn’t match the processes they are familiar with. But that’s probably easier for something with more cross-area appeal. >> >>> >>> I do think there are going to be some cases where process changes are only going to get rough consensus, and the chair(s) of GENDISPATCH need to be able to make that consensus stick -- but that's just as it is in every other working group. I suspect that developing the proposals and making those calls in a public process rather than (what some perceive to be) as proclamations from on high is a better way to promote what resembles harmony in our community. >> >> No disagreement there. >> >> Thanks! >> >> Ben. >> >
