Hi Ted, Thanks for your thoughtful mail. > Are these roughly in order of importance to the IESG? If so, I think > the order is wrong. Speaking personally, I did not think of the set of principles as being ordered. Certainly, as you argue, there are some differences in how they should be weighed. The IESG did not attempt to prioritise them, but rather wanted to point out what key issues we want to keep in mind. > So, I think this increasing your flexibility, but does nothing much for sustainability. > You still are having the same pool of bodies do the work, simply taking AD capacity > from one area and using it another. That may be nice, but it increases the > level of cooperation needed between the area management and the visiting > ADs, so it is really only a marginal gain even for the area getting the outside talent. > > To make a dent in this, you actually have to increase the number of bodies > available to do the work. And to do that, you have to reformulate some of the > work so that bodies who do it don't have to have the tag AD. (The document > shepherd opening up to non WG chairs is a good example here). I agree, but not all specific actions that we suggested may affect all the things we want to have an effect on. Increasing flexibility is important. Again in my personal opinion, sustainability is largely about two other factors. One, that you can distribute work in the organisation, and by this I do not mean to the other ADs :-) Two, that you have ADs that are overseeing and managing work that the world determines to be of high value. > This justification seems to hint at a "Model Language AD" who > can serve the whole IETF as a shepherd of YANG work across areas. > Why is that not a better answer here? That would be another way to do it, but in my personal opinion we have a long-term growth in the routing-related work and that is not solely about model languages, even though that topic indeed is a key topic. > Noting that you are short of routing AD attention and shifting other > work into the area after fixing that problem also seems to ignore the > "out of area" AD mechanism introduced above--why is that not > sufficient? Again, I think flexibility is useful for us to react, and the kind of “small scale” flexibility that out-of-area ADs for instance provides, is useful to address the day to day needs of the IESG to organise its work. Nevertheless, the definition of our areas still has to evolve, and in my mind that addresses the bigger scale changes. If you have an organisation that can use experts from anywhere when an issue comes up, that is flexible. Still, if that organisation embarks on a big project, they probably should hire the staff for it. > I also note that the proposed shift changes the useful > skillsets for both routing and INT, and that doing so at this point in > the nomcom cycle isn't exactly optimal. Noted. Finding the optimal point to make changes is not easy, however. I think the IESG feels that the benefits of making changes outweighs the downsides. > So, I thoroughly agree that the name here is distractingly bad, but I > also believe that you're building the wrong bike shed. Thank you for focusing on the substance :-) > As it stands, coordinating > four or five people's schedules to have calls and agree on document processing either > means a fairly large investment in time spent on Doodle polls or allowing > the area to have "mini-Areas" whose coordination remains loose. I think having mini-areas would probably mean that an organisational change did not really get implemented as intended, which is bad. > As Robert Sparks pointed out, the failure to use common methods (like DISPATCH) > is going to run into trouble and exacerbate that. Noted, and I agree. > There are a lot organizational principles possible here. RAI was organized more or > less as a topic area with "all those things relating to Internet Telephony (plus a few)" > as the topic. This meta-area doesn't seem to have such an organizational principle, > and the "there are overlaps" argument doesn't seem that strong given the large number > of _other_ overlaps. I understand that folks are tempted by the "select a bunch of generalists" > and let them work it out as a free-form approach to the AD job, and that this could be > a mini version of that. Personally, though, I think having set areas remains valuable, in > part because it shows how the overall organization understands the way the work interconnects. > Putting too much in a single bucket muddies the interconnection into incomprehnsibility, > at least to me. I think I at least agree on your principles, i.e., areas remain as valuable entities, and that putting too much or too different topics in the single bucket would not be optimal. Point noted, although, of course, the question we need to think about is whether the proposed area crosses that line or not. The IESG will for sure discuss this. > To return a moment to the question of sustainability, I think the key element is always offload. > When all the site selection and contract work left the IESG and was taken up by the IAOC, > the IESG gained cycles over all. That might have been hard to see at the time because of > the overall transition, but it is obvious now. I think the IESG might get more bang for its > re-organizational buck if it focused on areas where its tasks could be handed over to new > bodies. As a very small example, if the conflict review work were done by a different group, > with each area sending a delegate, would that hurt anything much? Would it gain any real > time? This may be a small example, but I think the principle is general--please focus on > areas where the IESG can differentiate its workload and then delegate the bits that > can be done elsewhere. Good advice, and thanks. I will add that the IESG certainly believes this as well, and wants to proceed in this direction as well. (But see above about my two aspects of sustainability. Also, the ability to offload work does not relieve us from the need to have the right organisational structure or the right areas.) Jari
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail