unsubscribe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
ietf-request@xxxxxxxx
Sent: None
To: ietf@xxxxxxxx
Subject: Ietf Digest, Vol 16, Issue 17

Send Ietf mailing list submissions to
	ietf@xxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
	ietf-request@xxxxxxxx

You can reach the person managing the list at
	ietf-owner@xxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf digest..."


Today's Topics:

   1. Re: project management (from Town Hall meeting)
      (Henning Schulzrinne)
   2. Re: project management (from Town Hall meeting) (Aki Niemi)
   3. The  plenary and the nomcom-term and  review panel proposals
      (John C Klensin)
   4. Re: On standards review panel and division of work
      (Spencer Dawkins)
   5. Re: project management (from Town Hall meeting) (Henk Uijterwaal)
   6. Re: On standards review panel and division of work
      (John C Klensin)
   7. Re: project management (from Town Hall meeting) (Pekka Savola)
   8. Re: project management (from Town Hall meeting)
      (Henning Schulzrinne)


----------------------------------------------------------------------

Message: 1
Date: Thu, 04 Aug 2005 05:07:49 -0400
From: Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx>
Subject: Re: project management (from Town Hall meeting)
To: Henk Uijterwaal <henk@xxxxxxxx>
Cc: ietf@xxxxxxxx
Message-ID: <42F1DAE5.7050606@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> I doubt that this is going to solve anything.  All basic project
management
> techniques assume that a project has a deadline and that the people
working

We do have deadlines: charters, and external customers (implementors, 
other SDOs).

> on it have some incentive to get the work done.  This is not the case for
> ID's: we continue working on them until there is rough consensus, no
matter
> how long it takes.  The authors are volunteers, if other activities pop up
> and work on the ID has to be postponed, there is nothing the WG chair can
> do.

This is not quite true: authors are not volunteers in the normal 
soup-kitchen-volunteer sense. In most cases, authors are paid by their 
companies to do the work. This is not a hobby for most contributors. 
Even more classical volunteer organizations, like IEEE (the 
non-standards-part) and ACM, set deadlines and have mechanisms to deal 
with volunteers (true volunteers in that case) that can no longer 
perform. For example, journals routinely drop editors that don't perform 
their (unpaid, volunteer) duties.


> This is another result of doing work with volunteers.  If somebody is
> interested in a topic but not in another, then there is nothing that
> can stop him from working on the first topic, even if it might be
> beneficial for overall progress to finish the topic first.

Part of managing for success in any "volunteer" organization is to 
channel volunteer energy.

Henning



------------------------------

Message: 2
Date: Thu, 04 Aug 2005 12:11:49 +0300
From: Aki Niemi <aki.niemi@xxxxxxxxx>
Subject: Re: project management (from Town Hall meeting)
To: ext Henk Uijterwaal <henk@xxxxxxxx>
Cc: ietf@xxxxxxxx
Message-ID: <42F1DBD5.40705@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

ext Henk Uijterwaal wrote:
> At 10:05 04/08/2005, Henning Schulzrinne wrote:
> 
>> I would never suggest adopting a 4-year project schedule, but would 
>> suggest a number of simple project management techniques and goals:
>>
>> - As part of WG chair training, train WG chairs in basic project 
>> management techniques and indicate that driving progress is an 
>> important role.
> 
> 
> I doubt that this is going to solve anything.  All basic project
management
> techniques assume that a project has a deadline and that the people
working
> on it have some incentive to get the work done.  This is not the case for
> ID's: we continue working on them until there is rough consensus, no
matter
> how long it takes.  The authors are volunteers, if other activities pop up
> and work on the ID has to be postponed, there is nothing the WG chair can
> do.

I hope you're not saying I-Ds have no deadlines. Sorry, but they do.

Sure we're a voluntary organization, and technical quality is the first 
order of priority. But that does *not* mean that it is OK to work on a 
particular draft only six weeks per year (around the f2f meetings), or 
that it's OK to have an author disappear for six months, or that each 
and every crazy idea sent to the mailing list needs to be incorporated 
in late stages of the work, resulting in constant feature creep.

Voluntary does not prohibit an incentives system, nor does it disallow 
project managers (the WG chairs) equipped with carrots and sticks.

> The real question is: how can we set realistic deadlines and get
commitment
> from people to get the work done by the deadline, even if they are
> interrupted.

By using the tools and conventions for WGs that Henning was proposing.

> Only when we have answered this question, it makes sense to start looking
> at tools to support this process.
> 
>> - Avoid massive number of parallel efforts in working groups. Instead, 
>> focus on a small number of drafts and get them out in less than a year 
>> from draft-ietf-*-00. (They might start as draft-personal- if they are 
>> exploratory.) 
> 
> This is another result of doing work with volunteers.  If somebody is
> interested in a topic but not in another, then there is nothing that
> can stop him from working on the first topic, even if it might be
> beneficial for overall progress to finish the topic first.

I think there is a misconception here about what "volunteer" means. I've 
worked in other voluntary organizations, and let me tell you, if you're 
a junior basketball coach but don't show up for practice, or decide to 
coach tennis unannounced for the next few months, you get replaced 
pretty quickly.

Cheers,
Aki

> Henk
> 
> 
>
----------------------------------------------------------------------------
-- 
> 
> Henk Uijterwaal                           Email: 
> henk.uijterwaal(at)ripe.net
> RIPE Network Coordination Centre
http://www.amsterdamned.org/~henk
> P.O.Box 10096          Singel 258         Phone: +31.20.5354414
> 1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
> The Netherlands        The Netherlands    Mobile: +31.6.55861746
>
----------------------------------------------------------------------------
-- 
> 
> 
> Look here junior, don't you be so happy.
> And for Heaven's sake, don't you be so sad.                 (Tom Verlaine)
> 
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
> 



------------------------------

Message: 3
Date: Thu, 04 Aug 2005 05:28:49 -0400
From: John C Klensin <john-ietf@xxxxxxx>
Subject: The  plenary and the nomcom-term and  review panel proposals
To: ietf@xxxxxxxx
Message-ID: <2F2F3DFD0C6D4703786A4AF2@7AD4D3FB4841A5E367CCF211>
Content-Type: text/plain; charset=us-ascii; format=flowed

Four observations on the plenary discussion of my drafts...

As I said at the end, I had not planned to come to the
microphone at all.  I wanted to listen.  What I heard
included...

(1) To repeat what I did say (since it was apparently hard to
hear) I see, once again, the problem that it has become
very hard to introduce a concept into this community.  If one
tries to do so via a comment on a mailing list, there is never
enough detail for anyone to really evaluate it (or the message
is so long that almost no one reads it).  If the concept is
presented in an I-D, then the document is torn to shreds for
not having enough detail for anyone to evaluate it.  On the
other hand, if details are provided in the initial document,
even as an example to show that a plausible set of details is
possible, the community (often including especially the IESG,
immediately focuses in on the details and picks at them,
ignoring the general concept and the usually-better question of
how to adjust the concept and fill in any blanks.

This behavior has a corollary along the "we cannot handle 
complexity" dimension.  If one writes a single draft that covers 
the several aspects of a problem, it is attacked as "too long, 
too complex, and covering too many issues" and told it should be 
broken up into smaller pieces.  If it is  broken up (the set of 
issues here are now two and I have been advised to produce a 
third that identifies the principles only), then people complain 
that having several drafts at once is too much to deal with.

That way of handling things, especially things that some people 
apparently just do not want to deal with, applies, I think, to 
both process proposals and our technical work.  It is not good 
news if we actually want to get things done.

(2) Several comments, during and after the discussion and most
precisely framed by Spencer Dawkins, that I may have made an
incorrect assumption about transition.   The text more or less
assumes that the review panel membership would be new
and the IESG membership would  be left in place.   Perhaps the
current IESG membership are most skilled in document review
rather than the sort of WG leadership and steering functions
that I had in mind -- the functions I think we had in the
early 1990s.  If that were the case, then we should resolve the
detail of the IESG being larger than the review panel, shift
the current IESG members onto the review panel, and repopulate
the steering/coordination/management entity (probably calling it 
something other than "IESG").

(3) A comment from an IESG member that the notion would probably 
add work, since the document provides for documents rejected  by 
the review panel to cycle back through the IESG. To me, this is 
one of the "sample detail" issues identified above.  If the IESG 
wants to be explicitly in that loop, and the community wants 
that, then "back to the IESG as the submitting body" is the 
right model.  I had anticipated their involvement at that point 
as lightweight, with the AD reviewing the comments and passing 
them on to the WG, but not assuming today's role of negotiator 
with the WG (or between the WG and the review panel).  I think 
that negotiator role, after a document goes out for IETF Last 
Call, is the source of several of our problems and needs to be 
eliminated.

For those who are reading this without having read the document, 
please note that rejection of a document by the review panel is 
intended to be A Big Deal.  The document suggests a process that 
would focus on getting good-quality, pre-reviewed, documents to 
the review panel --with shared responsibility between the WG and 
the IESG's steering/managing function for being sure that 
happens-- with the review panel only organizing a final check.

If the IESG believes that being in the "return" loop would be 
burdensome, then the proposal can easily be adapted to that 
belief.  The change would be to have the review panel return the 
document directly to the WG, with the AD involved only as part 
of WG management.  The IESG would then be involved again only as 
part of routine WG oversight and when the WG concluded that it 
was ready to resubmit the document.  I will make that change for 
-01 unless others object.

As a particularly strong variation, one could have the review 
panel return the document to the WG and then require either a 
"new benchmarks" or recharter activity since "rework a rejected 
document" would not be on the WG's pre-rejection charter.

Again, from my point of view, these are details that can be
sorted out and tuned if the community likes and wants the
general concept.  If the community does not, there is no point
wasting the time to generate and debate those details.

(4) I heard at least one IESG member say something that sounded
suspiciously like:

	"We are really busy and have all of these technical
	documents to review.  If you really want to discuss changes
	and process proposals, we will be happy to defer action on
	all of your technical documents until you come up with a
	process proposal that we like".

I'm sure that was not intended.  However, some reassurance
would be appropriate.  It would also, IMO, be appropriate to
pay careful attention to comments (last night and earlier) that
it is probably time to come up with a process for reviewing and
approving process proposals that does not involve the IESG
other than as community members who can comment on a proposal
along with the rest of us.

Almost as a side-effect of the core changes, the review panel
proposal suggests moving sign-off on process proposals to the
IAB.  Would it be useful to generate a very short I-D that does
that, and that only, as a means of moving things forward?

     john
  



------------------------------

Message: 4
Date: Thu, 4 Aug 2005 11:34:25 +0200
From: "Spencer Dawkins" <spencer@xxxxxxxxxxxxx>
Subject: Re: On standards review panel and division of work
To: <ietf@xxxxxxxx>
Message-ID: <001f01c598d7$b4e1ba90$c51eff56@DFNJGL21>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response

Hi, Pekka (but not only Pekka),

If I understood Margaret last night, she was at least somewhat 
comfortable with a hard split between area management and technical 
review, so I'd like to at least ask one question...

In discussions with John Klensin, I (and I think we) both assumed that 
the addition of an Standards Review Panel would mean that that the 
IESG participants remained on the IESG. But now I'm wondering - if we 
have a future-SRP and a future-IESG, which one of these does the 
current IESG more closely resemble?

I'm trying to figure out if we're really adding a Standards Review 
Panel, because the existing IESG is spending too much time on 
standards review, or whether the existing IESG is spending a LOT of 
time on standards review, so we're really adding an Internet 
Engineering Steering Group...

Spencer 





------------------------------

Message: 5
Date: Thu, 04 Aug 2005 11:40:06 +0200
From: Henk Uijterwaal <henk@xxxxxxxx>
Subject: Re: project management (from Town Hall meeting)
To: Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx>
Cc: ietf@xxxxxxxx
Message-ID: <6.2.1.2.2.20050804112939.02cab418@localhost>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:07 04/08/2005, Henning Schulzrinne wrote:
>>I doubt that this is going to solve anything.  All basic project
management
>>techniques assume that a project has a deadline and that the people
working
>
>We do have deadlines: charters, and external customers (implementors, 
>other SDOs).

I haven't counted the number of times were deadlines were missed this
week alone with no consequences.

For example, in a WG I attended this morning, the chair asked a person
about a document he promised to write.  The person answered that he'd do
this in the next month.  The chair replied that he said that last time as
well.  Some laughter followed, but that was the end of it.

>This is not quite true: authors are not volunteers in the normal 
>soup-kitchen-volunteer sense. In most cases, authors are paid by their 
>companies to do the work.

I agree.  But companies change priorities and with that the time people
can spend on ID's.  In this case, there is little we can do.

I can see a solution (have get commitment from employers before assigning
work to a person) but this will require a major change in the basic way we
work.


>   For example, journals routinely drop editors that don't perform their 
> (unpaid, volunteer) duties.

Yes, but I rarely see this happen in the IETF.

Henk


----------------------------------------------------------------------------
--
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
----------------------------------------------------------------------------
--

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine) 




------------------------------

Message: 6
Date: Thu, 04 Aug 2005 06:09:48 -0400
From: John C Klensin <john-ietf@xxxxxxx>
Subject: Re: On standards review panel and division of work
To: Pekka Savola <pekkas@xxxxxxxxxx>, ietf@xxxxxxxx
Message-ID: <AA6E4DD2B90A16498C5F29C8@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed



--On Thursday, August 04, 2005 09:35 +0300 Pekka Savola 
<pekkas@xxxxxxxxxx> wrote:

>...
> I do not think this is a show-stopper though; as many details
> in the proposal, things like these can be modified.  In this
> case, I believe the problem can be easily addressed by giving
> the ADs the power to initiate the review requests to the
> review panel -- and encouraging them to do so.
>
> This would have several benefits:
>   * if the expectation would be that drafts would be brought
> before
>     the full IESG only in exceptional cases, the load and
> duplication
>...
> I don't see any disadvantages, except that if there hasn't
> been sufficient cross-area review before requesting the review
> panel to review, they might have to shuttle the documents back
> and forth more often.  This approach might also call for
> IETF-wide vetting of also WG-produces
> informational/experimental documents, if they would be
> reviewed by fewer people, but if this would be needed, it
> could be easily added later on and isn't worth considering at
> this point.

See my note posted a short time ago (which was written before 
seeing yours).  But, yes.    This is exactly the thing I was 
commenting about in that note.  It is, at some level, a detail. 
It can be tuned in any of a number of ways.  I picked one, not 
quite at random.  You suggest a different one above.  I think we 
need to decide the concept is worthwhile (I'm not sure there is 
consensus on that yet), and then sort through these details. 
IMO, the "I don't like that detail so the proposal is invalid 
and should not be considered" approach is just not a productive 
way to proceed.

         john






------------------------------

Message: 7
Date: Thu, 4 Aug 2005 13:10:17 +0300 (EEST)
From: Pekka Savola <pekkas@xxxxxxxxxx>
Subject: Re: project management (from Town Hall meeting)
To: Henk Uijterwaal <henk@xxxxxxxx>
Cc: ietf@xxxxxxxx
Message-ID: <Pine.LNX.4.61.0508041303280.29844@xxxxxxxxxx>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 4 Aug 2005, Henk Uijterwaal wrote:
> This is another result of doing work with volunteers.  If somebody is
> interested in a topic but not in another, then there is nothing that
> can stop him from working on the first topic, even if it might be
> beneficial for overall progress to finish the topic first.

Well, at least there is a mitigation factor (in theory).

Set the maximum amount of documents that can be worked in parallel. 
If folks want their own document added as a WG document, they'll have 
to work on the existing documents out of the door first.  (Obviously, 
this is a tool WG chairs can already use; I'd certainly be interested 
if the model has been executed successfully or unsuccessfully.)

This also requires that documents with ineffective editors get 
raplaced reasonably quickly so there's always progress going on (and 
the proposers of new work can't say, "but the existing ones aren't 
going anywhere [because the editor isn't doing the job]").

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



------------------------------

Message: 8
Date: Thu, 04 Aug 2005 06:17:02 -0400
From: Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx>
Subject: Re: project management (from Town Hall meeting)
To: Henk Uijterwaal <henk@xxxxxxxx>
Cc: ietf@xxxxxxxx
Message-ID: <42F1EB1E.80509@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> I haven't counted the number of times were deadlines were missed this
> week alone with no consequences.
> 
> For example, in a WG I attended this morning, the chair asked a person
> about a document he promised to write.  The person answered that he'd do
> this in the next month.  The chair replied that he said that last time as
> well.  Some laughter followed, but that was the end of it.

I would consider this a problem (cultural and otherwise), not a 
desirable state of affairs. If you mean that this requires more than 
just adding tools, I agree. I tend to believe the old saw that "we 
manage what we measure". Currently, we have a creeping bias of low 
expectations and no good way to measure if things are getting worse or 
better.

In volunteer organizations, organizations that don't ask anything of 
their members tend to get what they ask for. (There have been 
interesting economics papers on why mainstream, low-commitment churches 
in the West have had difficulties keeping members. But I digress.)


> I agree.  But companies change priorities and with that the time people
> can spend on ID's.  In this case, there is little we can do.

In extremis, WG chairs can re-assign the work to some other party or 
parties. If no other party is interested in doing the work, the draft 
must not be all that important after all. Forcing a do-or-die decision 
avoids wasting time of all parties concerned. I suspect that this will 
also trigger a discussion between employer and employee which will 
magically make time available.

> 
> I can see a solution (have get commitment from employers before assigning
> work to a person) but this will require a major change in the basic way we
> work.

I don't see "exported" commitments as useful since they won't be 
enforceable unless you add a performance bond. No, I'm not currently 
suggesting performance bonds...



> Yes, but I rarely see this happen in the IETF.

Maybe that's a bug, not a feature. It is currently difficult to pull the 
plug since the tardy author can easily say "all other documents are 
late, why pick on me?".

As a meta comment, saying that culture cannot change is the first and 
most obvious sign of a dying organization. I'm not claiming that you're 
claiming immutability, but I do hear variations on this in various remarks.

Henning



------------------------------

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


End of Ietf Digest, Vol 16, Issue 17
************************************


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]