Re: Proposed change to draft-ietf-nomcom-rfc2727bis-01.txt

[Brian E Carpenter <brian@hursley.ibm.com>]

Hmm. I can only respond to this by repeating msyelf, so I won't.

   Brian

Dave Crocker wrote:
> 
> At 11:08 AM 7/12/2002 +0200, Brian E Carpenter wrote:
> > > Let's take a step back, folks:  Why 5 months?  Why not 8 or 3?
> >
> >Specifically, because I think we need about 8 weeks more in the process,
> >which I think is the intention of the draft anyawy.
> 
> Yes, it clearly is the intention.  What is NOT clear is how this extra time
> is actually to be used and why it is necessary.  Also...
> 
> > > 5 months means that we have a yearly process that takes nearly half a
> > > year!  That just does not make sense.
> >
> >Why not?
> 
> What the heck, let's start the nomcom process 18 months before we select
> people.  That way we will be sure to have enough time.
> 
> And I hope that taking this ad absurdem highlights that we need concrete
> reasons for making these choices and that the reasons need to be
> balanced.  Besides that, spending 1/2 of every year doing selections keeps
> the tone of the IETF that much less stable.  It also makes affects that
> quality of the information acquired, since it permits that much less
> history for the people being evaluated.
> 
> Right now, it appears that the philosophy is to throw "time" at all nomcom
> concerns.  It therefore fails to consider what the actual problems are, and
> it fails to respect the time of the nomcom participants.
> 
> > >          It ignores the reality that a nomcom's members
> > >          get exhausted.
> >
> >Surely having a bit more time to do the same amount of work should reduce
> >the exhaustion level?
> 
> That is exactly wrong.
> 
> Nomcom is an extra activity.  The longer it goes, the longer the
> participants have to carry an extra activity.  The longer they have to
> carry the support of their management.  The longer the process of nomcom
> has to keep nomcom "project energy" strong.  The longer they are attending
> to nomcom and not IETF technical work or IETF management.
> 
> These are not abstract concerns.  They apply to any project and they were a
> very noticeable factor in the recent nomcom.
> 
> > > Sometimes, throwing money at a problem fixes it.  Same for throwing
> > time at it.
> > >
> > > Sometimes we need to figure out what real problems there are and fix them
> > > more directly.
> >
> >And the real problem I spoke of in Minneapolis was the difficulty encountered
> >by the conforming bodies in understanding and handling controversial choices
> >made by NomCom.
> 
> I hope it's clear that this concern makes sense to me, too, and that it is
> a very good idea to attend to it.  However I believe that "time" is not the
> answer, but trying to improve the nature of the interactions -- and
> improving the sense of the role of the confirming body.
> 
> > > For all of the real and obvious concern over having the confirming bodies
> > > feel rushed, I have yet to understand what would take place that would be
> > > different and better.
> >
> >Having sat on the confirming side of the fence for 8 straight years, I can
> >tell
> >you that feeling rushed when called on to approve a controversial decision
> >is not a good place to be.
> 
> And just to be redundant, I'll stress that I agree that that is a bad state
> of affairs.  However it is not clear that giving the confirming bodies more
> time actually fixes the core problem, which I believe is to ensure that a
> confirming body has a solid basis for understanding how nomcom selections
> are made.
> 
> If that is not the core problem, or if there are more core problems, don't
> you think we should come to some understanding, before making assumptions
> of how to solve them?
> 
> For example, we could try to provide some information sooner.  And we could
> try to provide better information, as you have suggested.
> 
> (By the way, my sense of the activity in this nomcom working group is that
> it is dominated by IETF management and confirming body folks, and has very
> little participation by people who have been voting members of nomcom.)
> 
> > > Can someone please describe the changes to the confirming process that
> > > would be enabled?
> >
> >There is no formal change. There is just time to do it with some thought.
> 
> And I repeat that that is not likely to improve things.  The 2 nomcoms I
> have been on both had push-back from one or both confirming bodies.  It was
> fine that the confirming bodies were concerned.
> 
> However the actual process was, essentially, that either a) the confirming
> body said the equivalent of "are you sure" and the nomcom said "yes", or b)
> the confirming body said "you need to talk to these people" and the nomcom
> did, with no change in the outcome.
> 
> Alternative a) is a waste of time.  Alternative b) has 2 problems.  One is
> that the confirming body did not adequately understand what interviewing
> had already taken place -- and frankly did not try to find out, though they
> thought they did.  (I think that your suggestion for proactive reporting of
> process details could substantially alter that.)  The other is that it
> basically represents an attempt by the confirming body to direct the
> details of the nomcom process.  It is my understanding that that is not a
> confirming body's job, and also there is no way a confirming body can do
> that at the end of the process, no matter how much time is allocated.
> 
> > > This treats the confirming bodies as collaborating members of the process,
> > > which I suspect is the real change that needs to happen, as long as the
> > > nature of the collaboration does not alter the role of confirming bodies as
> > > confirming process.
> >
> >Yes, that wouldn't be bad, but perhaps as an oral tradition item until we
> >have some running code.
> 
> sounds good.  so good that it should be applied to the desire to make
> calendar changes without having any real idea how they will be used...
> 
> \d/
> 
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.850.1850
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.elistx.com/subscribe>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland