Hi Brian, I like what I see. This permits the pacing of work as we discussed during the F2F in Prague with the area director, and allows for building on the foundational work that is now completing.
Eliot > On 11 Jun 2019, at 03:02, Brian E Carpenter <[email protected]> > wrote: > > Hi all, > > I've taken the liberty of posting an update to the draft charter > at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried > to respond to all the IESG comments, and in particular: > > (a) I deleted Intent from the summarised reference model framework, > since the reference model doesn't usefully define Intent. > > (b) I tried to make the statement about workload throttling more > implementable. > > (c) I still think that the laundry list of *possible* work items > is useful (it helps to define the scope) but I've tried make it > clear that it is only the "indicative scope of possible work items". > It really isn't mission creep; all the items mentioned relate > directly to the ANI and AF topics. > > (d) I intentionally removed the reference to not covering machine > learning and AI. It isn't suggested anywhere in the reference model, > so why even mention it? > > (e) I fixed nits and tuned the wording in several places. > > I hope this helps. We really need a new charter before Montreal. > WG Chairs and AD, over to you... > > Regards > Brian Carpenter > > On 02-May-19 08:39, Brian E Carpenter wrote: >> Hi Alissa, >> >> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: >> ... >>> ---------------------------------------------------------------------- >>> BLOCK: >>> ---------------------------------------------------------------------- >>> >>> (1) "Acceptance of work items by the WG will be scheduled/throttled so that >>> contributors can target them to enter WG last call after not more than a >>> number >>> of IETF meeting cycles agreed by the AD." >>> >>> I don't understand the implications of this. What happens if the adopted >>> work >>> items have not entered WGLC after the agreed number of cycles? If the >>> answer is >>> anything other than "the WG abandons the work," I don't understand how this >>> is >>> a throttling mechanism. A throttling mechanism would need an explicit limit >>> on >>> the number of adopted work items at any one time, I think. >> >> I agree that the text is a bit illogical. In a sense it's unnecessary, >> because >> every WG should be matching its workload to its capacity. Maybe that's all >> we should say, rather than trying to describe a slightly vague algorithm? >> >>> (2) The proposed work items is a very large and somewhat unbounded list of >>> items, whereas the purpose of writing a charter is to scope the work of the >>> WG >>> and hopefully set out a realistic work plan that will be accompanied by >>> deployment. For a WG that has produced 5 documents in the last 5 years, I >>> think >>> the charter needs to more narrowly focus on the most highly prioritized work >>> items. Once those are nearing completion, it seems as though evaluation of >>> what >>> is needed next based on deployment experience would then dictate the next >>> set >>> of items for another re-charter. >> >> I think the point here is that now that the relatively small number of >> infrastructure documents are almost finished, the next stage opens up >> the possibilities for a much wider range of work that builds on the >> infrastructure. The priorities aren't even obvious. So this goes with >> the previous point, and to quite some extent the criteria will be >> whether the WG has capacity more than which topic has priority. >> >> That's why there's a bucket list of work items and a short list of >> immediate milestones. >> >> Would this help? >> >> s/Proposed work items include.../Possible work items include.../ >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> It would be good to see milestones with dates before this gets approved. >>> >>> I think this charter would benefit from an English edit pass before going >>> out for external review. >> >> I'll volunteer, when the open issues have been resolved. >> >>> What is "compounding environment"? >> >> An excellent question. >> >> Brian >> > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
