Subject: [apps-review] Suggested changes for Applications Area Review Team

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 00:50:46 -0700

Hello,

I have been acting as Applications Area Review Team Lead for nearly a 
year.  My assessment is that the team is still not fully 
functional.  Alexey made some suggestions.  Please comment on the 
following suggested changes:

There are three kinds of requests:

  (a) Early reviews requested by the Apps Area ADs

  (b) Review of a document in Last Call

  (c) Document on the IESG Agenda

I would like to minimize requests for (c) as it would mean a short 
deadline for assignments.

Reviews requested by Apps Area ADs could include a list of issues to 
look for when specific reviewer expertize is required.

When an assignment is made, the review can:

  (i)   acknowledge that he or she can perform the review before the deadline

  (ii)  acknowledge that he or she can perform the review but he or 
she requires more time

  (iii) decline the assignment

If a reply is not provided within 24 hours of the request for review, 
it is assumed that the reviewer will be able to perform the review 
before the deadline.

Team members that have been unable to perform three assignments over 
a six month period can be dropped from the team.

The review template at 
http://www.apps.ietf.org/content/apps-review-template suggests that 
the review should provide a one-sentence summary, e.g.:

  (i)   This draft is ready for publication as an Experimental RFC

  (ii)  This draft is almost ready for publication as an Informational RFC but
        has a few issues that should be fixed before publication

  (iii) This draft is not ready for publication as a Proposed Standard and
        should be revised before publication

followed by major issues, minor issues and nits.

Major issues are the type of concerns that will result in the 
document being blocked until they are resolved.

Minor issues are concerns about clarity or technical accuracy that 
should be discussed and resolved before publication, but which would 
normally be resolved between the authors and the reviewers.

Nits are editorial or layout items.  They would ideally be resolved 
before publication to make the document more readable.  Usually a 
reviewer will not be looking for this type of issue, but may find 
some in the course of the review.

If you have any other suggestions, please send them to the list.

Best regards,
-sm

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 19 Mar 2011 18:48:37 +0900

I think this looks good, except that I would add that (as usual in the 
IETF) these rules should be applied according to circumstances, not 
strictly according to the letter.

Regards,   Martin.

On 2011/03/19 16:50, SM wrote:
> year. My assessment is that the team is still not fully functional.
> Alexey made some suggestions. Please comment on the following suggested
> changes:
>
> (ii) acknowledge that he or she can perform the review but he or she
> requires more time
>
> If a reply is not provided within 24 hours of the request for review, it
> is assumed that the reviewer will be able to perform the review before
> the deadline.
>
> Team members that have been unable to perform three assignments over a
> six month period can be dropped from the team.
>
> The review template at
> http://www.apps.ietf.org/content/apps-review-template suggests that the
> review should provide a one-sentence summary, e.g.:
>
> Major issues are the type of concerns that will result in the document
> being blocked until they are resolved.
>
> reviewer will not be looking for this type of issue, but may find some
> in the course of the review.
>
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 19 Mar 2011 06:34:37 -0700

On Mar 19, 2011, at 12:50 AM, SM wrote:

> If a reply is not provided within 24 hours of the request for review, it is assumed that the reviewer will be able to perform the review before the deadline.

I think this is a poor assumption to make.   The reviewer might have dropped off the face of the Internet for a few days, or might even be dead.

I suggest instead that after 24 hours without a response, the team lead either reassign (such as when time for the review is short) or give the assigned reviewer another 24 hours to respond.  After 48 hours of now response, always reassign.

I also would not count hours of weekend and days of the reviewer's national holidays against those hours. 

-- Kurt

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 19 Mar 2011 08:48:59 -0700

Overall, the plan looks fine to me.

Two points:

On 3/19/2011 12:50 AM, SM wrote:
> If a reply is not provided within 24 hours of the request for review, it is
> assumed that the reviewer will be able to perform the review before the deadline.

I suggest that all assignments MUST receive an explicit acknowledgment.  I'm not 
sure what the timeout should be for the less urgent ones, but 24 hours seems 
fine for the IESG (relatively urgent) one.

But a default ack is not a good protocol construct for critical functions...

> followed by major issues, minor issues and nits.

I usually follow a review format that has:

    1. Summary of my understanding of the purpose and content of the document. 
This is a common reviewing technique and it establishes a base of factual 
understanding, before launching into the my opinions about the quality of the 
content. If I have any misunderstanding of the basics, it's better to surface 
that at the outset.  I also find that the discipline of formulating the factual 
summary helps to organize my thoughts about the draft.

    2. Summary of major issues

    3. Inline detailed comments.  For extended documents, the detailed feedback 
is typically extensive and not subject to summarization.  I frankly do not know 
how to break it out into clean distinctions of major/minor/nits without 
dramatically more work.  In addition, my view of major vs. minor vs. nit is 
likely not to match the authors'...

Adding an explicit "rating" at the beginning seems like an excellent idea; I'll 
try to remember to add one.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 09:00:09 -0700

Hi Martin,
At 02:48 19-03-2011, Martin J. Dürst wrote:
>I think this looks good, except that I would add 
>that (as usual in the IETF) these rules should 
>be applied according to circumstances, not strictly according to the letter.

I would like it to be read as "this is how we do 
things" instead of official rules.  I agree that 
it should be applied according to the 
circumstances and not strictly to the letter.

Some of the team members have asked to take leave 
for various reasons.  For example, if you tell me 
that your spouse is expecting a baby, I will ask 
you how much time off you would like to 
take.  Some people may ask for one month, some 
may say three months.  If you ask for nine months 
and you are not biologically inclined for it, I 
will say that the leave is too long. :-)

If Ted, Claudio or Eliot tell me that they are 
busy and they won't be able to take several 
assignments, I do not have to question that as I 
know that they performed 10 of the 35 reviews last year.

Some of you are document editors and WG Chair 
while seeing to your day job.  You might be very 
busy.  The circumstances justify not being able 
to perform an assignment.  But it does not work 
for me when over two thirds of the team members 
fit that profile.  I can then only count on one 
third of the team to perform the reviews.  The 
end result will be a dysfunctional team once again.

Best regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Mar 2011 12:33:53 -0400

--On Saturday, March 19, 2011 00:50 -0700 SM
<[email-masked]> wrote:

> Hello,
> 
> I have been acting as Applications Area Review Team Lead for
> nearly a year.  My assessment is that the team is still not
> fully functional.  Alexey made some suggestions.  Please
> comment on the following suggested changes:
>...

This generally looks ok.   I agree with Dave -- implicit ACK is
not a good protocol, especially so when you are anticipating a
24 hour timeout.  As strange as the idea may seem, some of us do
end up with travel, day job, or other commitments that might
result in our being offline wrt review team messages for
significantly longer than that (e.g., while I hope to do better,
my current expectation is that I'll be offline all of the week
starting April 4 due to circumstances entirely beyond my
control).

Although I usually try to make "major/minor/nits" distinctions
when doing reviews, I agree with Dave that it can sometimes be
very difficult,  with rather subjective boundaries, and
time-consuming.  I think you should try to be clear about
priority for that sort of breakdown when you might be able to
get it only at the price of a delayed review or no review at
all.  

Perhaps as the basis for a different classification system for
standards track documents, I also think that it would be very
useful to get a reviewer opinion that distinguished between "not
yet ready for publication given the criteria for the relevant
maturity level in RFC 2026 (as amended)" and "not ready for
publication using other criteria that the author thinks are
appropriate".  Especially from the standpoint of those of us who
believe that the IETF spends too much time fine-tuning
early-stage specifications, making that distinction might be
helpful for the IESG and a useful reminder for everyone else.

Finally, I strongly favor your inclination (and Martin's) to
make this process descriptive rather than normative/rigid.

  john

---

From: Claudio Allocchio <[email-masked]>
Date: Sat, 19 Mar 2011 19:53:58 +0100 (CET)

> assumed that the reviewer will be able to perform the review before the 

but this is not ok. Implicit ACK is bad, because we still do not have 
internet on airplanes everywhere... and it might happen that we end up on 
top of some mountain where there is no Internet connection (even if, as 
you see, we answer email also on Saturday evening  :-)  ).

Please change the implicit ACK with an explicit ACK, and 24 hours is 
really only for very urgent requests (IESG queue) and should be used only 
a very short urgent reviews. 2 *working* days is much more likely to 
accomodate all.

>       should be revised before publication

well, the above does not cover all possible compbinations, and 
"structuring" too much requires a full list of combinations. Or... the 
above are just "examples" of short summaries.

and Yes... IETF style application of the guidelines ("rough common sense") 
works better than literals. :-)

all the best!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 09:55:47 -0700

Hi Kurt,
At 06:34 19-03-2011, Kurt Zeilenga wrote:
>I think this is a poor assumption to make.   The reviewer might have 
>dropped off the face of the Internet for a few days, or might even be dead.

I agree that it is a poor assumption to make.

It may happen that the reviewer is travelling for over a day or that 
he or she is without Internet connectivity for several days.  I have 
experienced both cases.

>I suggest instead that after 24 hours without a response, the team 
>lead either reassign (such as when time for the review is short) or 
>give the assigned reviewer another 24 hours to respond.  After 48 
>hours of now response, always reassign.
>

I'll try to explain the problem from my perspective.  Some team 
members do not respond to a request for review even after 48 hours 
(excluding weekends and holidays).  I reassigned the review in such 
cases.  After a while, it turned into reviews being assigned to a 
small subset of the team.

If I have to reassign three out of five assignments, it leaves me 
with very little choice especially when a specific expertise is 
required.  And that is what happened last year.  This team does not 
operate like other review teams; the next team member in line for an 
assignment may have to be skipped when, for example, XML expertise is desired.

You performed all the assignments that you got.  The same cannot be 
said about every team member.  I can go to Alexey and Peter and say 
that I am using the well-established "procedures".  In practice, we 
know that the "process" don't work.  Or I can make assumptions that 
do not look good on paper.  In practice, some teams members may end 
up on the pending reviews list and I can walk to the Alexey and Peter 
and say that I found a good excuse to drop them from the team.  I 
know that some people listed on the pending reviews list are very 
busy.  As I have met some of them, I gather that they can tell 
whether I would drop them due to personal disagreements.

Best regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 12:09:04 -0700

Hi Dave,
At 08:48 19-03-2011, Dave CROCKER wrote:
>I suggest that all assignments MUST receive an explicit 
>acknowledgment.  I'm not sure what the timeout should be for the 
>less urgent ones, but 24 hours seems fine for the IESG (relatively urgent) one.
>

I agree.  However, we are not working on a protocol here.  This is a 
people issue.  If I assign you a review, I know that you will send an 
ack within 24 hours.  If you do not do that, I would wait for a 
couple of days as I know that you generally do reply to emails.

If I go for MUST receive an explicit acknowledgement, I already have 
historical evidence that it will fail in at least 50% of cases even 
if I wait five working days for an answer.

I'll be candid.  The suggested changes are to get team members to 
actually perform the assignments instead of having an Applications 
Area Review Team in name only.

The latest review was assigned to Carsten.  It falls within an IETF 
period where he will be travelling to Prague and he will be busy at 
the meeting.  I do take that into account.    My choices are simple; 
I can tell Alexey and Peter that the review cannot be done within two 
weeks or I can discuss with Carsten to find an alternative that fits 
his schedule.  I prefer the latter.  That is why I told him that he 
can take more than two weeks.  From past experience, I know that he 
will deliver on the review.

I prefer not to comment on specific cases of reviews that have not 
been performed.  Alexey and Peter probably know about them even 
though I did not discuss the cases with them.

>    1. Summary of my understanding of the purpose and content of the 
> document. This is a common reviewing technique and it establishes a 
> base of factual understanding, before launching into the my 
> opinions about the quality of the content. If I have any 
> misunderstanding of the basics, it's better to surface that at the 
> outset.  I also find that the discipline of formulating the factual 

Thanks for sharing this.  It would help the Apps Area ADs if the 
summary clearly states whether the document is ready for publication.

>    3. Inline detailed comments.  For extended documents, the 
> detailed feedback is typically extensive and not subject to 
> summarization.  I frankly do not know how to break it out into 
> clean distinctions of major/minor/nits without dramatically more 
> work.  In addition, my view of major vs. minor vs. nit is likely 
> not to match the authors'...
>
>Adding an explicit "rating" at the beginning seems like an excellent 
>idea; I'll try to remember to add one.

The clean distinctions are certainly more work and it is not always 
clear what should be major or minor.  And as you said, it may not 
necessarily match the author's or even the Apps Area ADs' view.

I'll use the review of apps-team review of 
draft-ietf-netconf-4741bis-07 as an example ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02268.html 
).  As Joshua mentioned, the I-D is an update to RFC 4741 and has 
therefore "stood the test of time".  If the reviewer gives a "Do Not 
Publish" in such a case, it won't stop publication.

Best regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 13:49:21 -0700

Hi John,
>starting April 4 due to circumstances entirely beyond my

For what it is worth, some of the reminders I send go 
unanswered.  The people who have been arguing against implicit ACK 
are the same people who reply within 24 hours and who perform the 
assignments. :-)  I mentioned it in my previous replies and I'll say 
it to you too, I agree with the arguments you raised above.

If you look at the tracker ( 
http://www.apps.ietf.org/content/apps-review-tracker ), you will see 
that there was only one review in July 2010.  The month after that 
was an odd case.  There were 14 reviews in September, 2010.  This was 
preceded by discussions on how to make the team functional.  The drop 
in January 2011 is due to the end of year season.  February and March 
were slow as I received a few review requests.

>get it only at the price of a delayed review or no review at

The major/minor/nits distinction is what typically appears in our 
reviews.  It is not an ID-nits that the review must pass.  I 
personally would not ask for a specific format for reviews.  The Apps 
Area ADs may have a preference.  I'll defer to them on that as our 
task is also to make their work easier.

There is an indirect readership.  Some people not be familiar with 
the IETF might be considering writing an I-D.  It is easier for them 
to learn from the reviews about what major issues to look out for if 
there are these boundaries.  It takes time for people to understand 
that the boundaries are subjective.  There is nothing this team can 
do about that.

I'll leave it to Alexey, Peter and Pete to comment on the priority 
for the breakdown.

>helpful for the IESG and a useful reminder for everyone else.

This is again subjective as we may have different views about RFC 
2026.  From an Apps Area perspective, I do not feel strongly about 
this.  I may have different views if you ask me on another mailing list. :-)

There is always room for improvement in an I-D.  An I-D with an 
intended status of Proposed Standard might have a higher bar than one 
intended as Experimental.  If a document is not ready for publication 
as Proposed Standard, it does not mean that the document does not fit 
the criteria for Experimental.  A review could recommend a different 
publication status.

>make this process descriptive rather than normative/rigid.

Although I did not mention it on this thread, I am aware that 
everyone on the team is doing volunteer work.  Some of you may be 
doing the reviews during your free time and you have other 
commitments as well.  Although I could ask for team members to be 
dropped from the team, it is the Apps Area ADs that have the final 
say.  I can only say "please do the assignment".

Best regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 14:06:31 -0700

Hi Claudio,
At 11:53 19-03-2011, Claudio Allocchio wrote:
>really only for very urgent requests (IESG queue) and should be used 
>only a very short urgent reviews. 2 *working* days is much more 
>likely to accomodate all.

As you have all argued against the impilcit ACK, let's go an explicit 
ACK of two days.  I suggest that you let me get away with not 
specifying "working" as I would then have to keep track of national 
holidays around the world. :-)

I reserve the right to ask for you to be dropped off the team if I do 
not receive an explicit ACK for three assignments over a period of 
six months. :-)

>"structuring" too much requires a full list of combinations. Or... 
>the above are just "examples" of short summaries.

The above are just "examples".

>and Yes... IETF style application of the guidelines ("rough common 
>sense") works better than literals. :-)

In the IETF, common sense is subjective. :-)

Best regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 19 Mar 2011 15:38:54 -0700

Hi Dave,
At 12:26 19-03-2011, Dave CROCKER wrote:
>Before there was computer communications, the word protocol referred 
>to rules of conduct among people.  It is still used that way in some 
>circles.  I used the term in an attempt to invoke a well understood 
>design concept among independent participants -- human as well as 
>computer:  Failing to obtain explicit confirmation does not work, 
>for critical functions.

I tried to get the message through without any undue risk to my 
personal safety. :-)

>If there really is a time-critical aspect to the review, then it is 
>better to err on the side of sending a new query to a new reviewer 
>than to wait longer for the original reviewer to confirm. The 
>downside of contacting a new reviewer unnecessarily is two 
>reviews.  The downside of waiting too long to contact the new 
>reviewer could well be no reivews.

The explicit ACK would then mean five days for me to find a 
reviewer.  If a review has a two week deadline, it turns into one 
week to get the review out so that the Apps Area ADs can read it 
before an IESG evaluation.

The real issue here is that the review is being assigned too late in 
the process.  The time-critical aspect can be avoided by identifying 
the document to be reviewed earlier, i.e. when it is in Last Call.

>However that's different from setting expectations among all 
>participants -- that's us, in this case -- to know we have an 
>obligation to respond quickly.

I did not intend it to be viewed as an obligation.  It was meant as a 
target that I could tweak.

>If there are deeper problems with this group -- and I wasn't aware 
>there was -- then they need to be addressed directly and not through 
>bits of indirect cleverness in specified conventions.  We ain't very 
>good at subtlety around here...

There are problems in getting reviews done.  When I first took over, 
it looked like an impossible task.  Some people left the team and 
there was a shortage of XML reviewers.  Reviews requested by WG 
Chairs took months to be delivered due to reassignments.

>certainly agree it is excellent for you to do that.  (By the same 
>token, it is an extra burden for you and while it's great that you 
>are willing to carry that burden, I would not want to write it into 
>the formal job description, since the next person doing this job 
>might not be willing or able to incur that extra effort.)

I would not describe it as a burden as I signed up for it.  I would 
like to hand over a group that works to the next person doing the job.

BTW, you message to apps-review was automatically discarded.  I don't know why.

Best regards,
-sm

---

From: Pete Resnick <[email-masked]>
Date: Sat, 19 Mar 2011 14:30:27 -0500

SM suggestions look good (caveat the concerns people have about 
auto-assigning things). But I did want to ask folks about one idea that 
I had to add on a task to the Review Team's normal things:

In addition to doing Last Call reviews, I am considering asking folks on 
the review team to do the occasional preliminary early review. What I'm 
thinking of is creating a queue of documents from non-Apps WGs that 
might have Apps implications. For example, I think DNS stuff or things 
like MPTCP, which will eventually need APIs, would be likely candidates 
for things I might want to hear about, whereas BGP would probably not be 
one of these. In general, the ADs would add things to the queue that 
send up their antennae, but anyone would be welcome to throw something 
in the queue that they thought might be interesting. Every so often, 
you'd be asked to do a cursory read of the document and give a few 
sentence summary of whether or not Apps clue might need to be given, the 
size of the clue (gentle nudge or large bats), and the kinds of 
applications that would care.

So the questions for the team:

1. Is this the sort of thing you think you all would be willing to do?
2. How often would you be willing to do it? For example, is it 
reasonable to ask people to look at one document per week for this kind 
of quick review?

One of the things I've been considering coming into the AD position is 
to get more early review done (by everyone, not just me) rather than 
waiting for Last Call, but without some sort of intelligent filtering, 
that would be impossible I think.

Thoughts?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Ted Hardie <[email-masked]>
Date: Sat, 19 Mar 2011 16:15:21 -0700

On Sat, Mar 19, 2011 at 12:30 PM, Pete Resnick <[email-masked]> wrote:
> auto-assigning things). But I did want to ask folks about one idea that I
> had to add on a task to the Review Team's normal things:
>
> In addition to doing Last Call reviews, I am considering asking folks on the
> review team to do the occasional preliminary early review. What I'm thinking
> of is creating a queue of documents from non-Apps WGs that might have Apps
> implications. For example, I think DNS stuff or things like MPTCP, which
> will eventually need APIs, would be likely candidates for things I might
> want to hear about, whereas BGP would probably not be one of these. In
> general, the ADs would add things to the queue that send up their antennae,
> but anyone would be welcome to throw something in the queue that they
> thought might be interesting. Every so often, you'd be asked to do a cursory
> read of the document and give a few sentence summary of whether or not Apps
> clue might need to be given, the size of the clue (gentle nudge or large
> bats), and the kinds of applications that would care.
>

Yes.

> 2. How often would you be willing to do it? For example, is it reasonable to
> ask people to look at one document per week for this kind of quick review?
>
This seems high.  Even a cursory review takes time, and some of the
ones you mention (like the DNS sameness question or multipath) can
take some serious brain bending.  It may be obvious that apps clue is
needed, but getting to the point where you can set what sort of apps
clue is needed takes more time.  Once a month or even a hair more, on
top of the current schedule, seems reasonable.

Just my thoughts,

Ted
> One of the things I've been considering coming into the AD position is to
> get more early review done (by everyone, not just me) rather than waiting
> for Last Call, but without some sort of intelligent filtering, that would be
> impossible I think.
>
> Thoughts?
>
> pr
>
> --

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 20 Mar 2011 00:24:44 +0100 (CET)

> 1. Is this the sort of thing you think you all would be willing to do?

yes. As early to start watching a proposal, the easier it is also to 
discuss about it, avoind the "but the WG already extensively discussed 
this and agreed, why you now want to change it?" - it just happened in my 
last review for example.

> ask people to look at one document per week for this kind of quick review?

one per week (per each individual) is really a lot, expecially if it comes 
from non-apps areas. You need some time to focus what the specification 
purpouse is, ... and often the "hey but this is going to have consequences 
here!" does not come after a first reading, but after "some meditation in 
the shower", when the how water runs out :-)

The idea is a good one, but I'd say 1 doc per month is defintly more 
likely to be fulfiled.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 19 Mar 2011 16:36:08 -0700

On 3/19/2011 3:38 PM, SM wrote:
> The real issue here is that the review is being assigned too late in the
> process. The time-critical aspect can be avoided by identifying the document to
> be reviewed earlier, i.e. when it is in Last Call.

+10

> There are problems in getting reviews done. When I first took over, it looked
> like an impossible task. Some people left the team and there was a shortage of
> XML reviewers. Reviews requested by WG Chairs took months to be delivered due to
> reassignments.

my impression is that you've whipped us into much better shape, more recently...

>> certainly agree it is excellent for you to do that. (By the same token, it is
>> an extra burden for you and while it's great that you are willing to carry
>> that burden, I would not want to write it into the formal job description,
>> since the next person doing this job might not be willing or able to incur
>> that extra effort.)
>
> I would not describe it as a burden as I signed up for it. I would like to hand
> over a group that works to the next person doing the job.

One of the problems with having a particularly eager and diligent person doing a 
task is that it is easy for the rest of us to lose sight of what is reasonable 
to demand, or at least expect, for the job.  I meant "burden" as a formal 
obligation, not as something that you or your successor might or might not find 
excessive.

> BTW, you message to apps-review was automatically discarded. I don't know why.

hmmm.  might have used the wrong From: address.  this one ought to work.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 19 Mar 2011 16:41:44 -0700

On 3/19/2011 12:30 PM, Pete Resnick wrote:
> SM suggestions look good (caveat the concerns people have about auto-assigning
> things). But I did want to ask folks about one idea that I had to add on a task
> to the Review Team's normal things:
>
> review team to do the occasional preliminary early review. What I'm thinking of
> is creating a queue of documents from non-Apps WGs that might have Apps
> implications.

+10.  excellent idea.

> 1. Is this the sort of thing you think you all would be willing to do?

Definitely.

> 2. How often would you be willing to do it? For example, is it reasonable to ask
> people to look at one document per week for this kind of quick review?

Frankly, I think that one a /month/ will prove to be a lot.  In spite of 
characterizing it as "quick", meaningful review requires multiple readings and 
iterative thought, before saying anything very useful, particularly when the 
document has significant problems.

The "quick" will help avoid doing the detailed part of the review, but I find 
the difficult part of a review to be formulating coherent, summary assessments.

d/

-- 

   Dave Crocker

---

From: [email-masked] (Henry S. Thompson)
Date: Sun, 20 Mar 2011 10:12:24 +0000

Yes.

> reasonable to ask people to look at one document per week for this
> kind of quick review?

No -- 1 per month maybe, and not, of course, when a 'real' review is
also underway.

Dave CROCKER writes:

> The "quick" will help avoid doing the detailed part of the review, but
> I find the difficult part of a review to be formulating coherent,
> summary assessments.

Exactly: "I'm sorry this is so long, I didn't have time to make it shorter"

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 14:55:09 +0000

Dave CROCKER wrote:

>> auto-assigning

Agreed. Should I populate the queue with my todo list ;-)?

>> reasonable to ask
> Frankly, I think that one a /month/ will prove to be a lot.  In spite 
> of characterizing it as "quick", meaningful review requires multiple 
> readings and iterative thought, before saying anything very useful, 
> particularly when the document has significant problems.
>

+1.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 15:01:53 +0000

Claudio Allocchio wrote:

> internet on airplanes everywhere... and it might happen that we end up 
> on top of some mountain where there is no Internet connection (even 
> if, as you see, we answer email also on Saturday evening  :-)  ).
>
> only a very short urgent reviews. 2 *working* days is much more likely 
> to accomodate all.

I would even say that 3 days might be Ok, with a second reminder being 
sent after 48 hours.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 15:04:04 +0000

Dave CROCKER wrote:
 [...]

> base of factual understanding, before launching into the my opinions 
> about the quality of the content. If I have any misunderstanding of 
> the basics, it's better to surface that at the outset.  I also find 
> that the discipline of formulating the factual summary helps to 
> organize my thoughts about the draft.
>
>    3. Inline detailed comments.  For extended documents, the detailed 
> feedback is typically extensive and not subject to summarization.  I 
> frankly do not know how to break it out into clean distinctions of 
> major/minor/nits without dramatically more work.  In addition, my view 
> of major vs. minor vs. nit is likely not to match the authors'...
>

I think this is a good format and it is quite similar to what GenArt and 
SecDir teams are using.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 15:09:12 +0000

> Hello,

Hi SM,
A couple of comments:

> Alexey made some suggestions.  Please comment on the following 
> suggested changes:
>

GenArt and SecDir ask reviewers to confirm that their issues were 
addressed and/or appropriately discussed before documents are put on 
IESG telechat. Maybe we should do the same.
 [...]

> If you have any other suggestions, please send them to the list.

I also want to remind everybody that Apps Review Team reviews are 
treated as IETF LC comments and have no more weight then them. 
Sponsoring ADs should take them into considerations, but they might 
disagree with certain conclusions made by reviewers (e.g. which issues 
are major, which are minor, which are blocking, etc.).

---

From: Pete Resnick <[email-masked]>
Date: Sun, 20 Mar 2011 10:11:18 -0500

Many people wrote:
>> 2. How often would you be willing to do it? For example, is it  reasonable to ask people to look at one document per week for this  kind of quick review?
>>      
> No -- 1 per month

It's pretty funny that everyone (including Alexey when I first brought 
the idea to him) said exactly the same thing. Followup question:

Even if you were assigned one per month, what would be the amount of 
time you would want from "pickup out of the queue" until "completion of 
review"? What I worry about is the same thing SM is trying to address 
with the initial proposed changes: I don't want to wait for a month to 
find out that someone is *not* going to be able to complete a review and 
then we have to restart the month timer in the queue, especially for 
what I'm hoping is an early cursory review. Is one week enough time to 
complete a review of this sort, even if you are only asked to do one per 
month?

pr

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 20 Mar 2011 08:14:55 -0700

On 3/20/2011 8:04 AM, Alexey Melnikov wrote:
> I think this is a good format and it is quite similar to what GenArt and SecDir
> teams are using.

I hadn't thought about commonality across the IETF, but now that you've 
mentioned it, I suggest we try to get a single template defined for the entire 
IETF -- as long as it remains advisory rather than compulsory.  Reviewers need 
to be able to make the actual decisions, but it helps to present a community 
preference.

Unless someone can come up with a compelling reason for having differences, I 
think a common template would make style and expectations more consistent.

d/

-- 

   Dave Crocker

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 15:17:29 +0000

Pete Resnick wrote:

> the idea to him)

Yes, I told you so :-).

> said exactly the same thing. Followup question:

> time you would want from "pickup out of the queue" until "completion 
> of review"? What I worry about is the same thing SM is trying to 
> address with the initial proposed changes: I don't want to wait for a 
> month to find out that someone is *not* going to be able to complete a 
> review and then we have to restart the month timer in the queue, 
> especially for what I'm hoping is an early cursory review. Is one week 
> enough time to complete a review of this sort, even if you are only 
> asked to do one per month?

2 weeks should be enough. Most of IESG doing similar reviews within 1 
week, but I appreciate that people without proper "IESG training" might 
need more time.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 15:18:57 +0000

[...]

>> month to find out that someone is *not* going to be able to complete 
>> a review
>
I think the same 1-2-3 days ACK period should apply to these (as 
discussed in another thread).

>> and then we have to restart the month timer in the queue, especially 
>> for what I'm hoping is an early cursory review. Is one week enough 
>> time to complete a review of this sort, even if you are only asked to 
>> do one per month?
>
> week, but I appreciate that people without proper "IESG training" 
> might need more time.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 20 Mar 2011 08:35:33 -0700

On 3/20/2011 8:09 AM, Alexey Melnikov wrote:
> GenArt and SecDir ask reviewers to confirm that their issues were addressed
> and/or appropriately discussed before documents are put on IESG telechat. Maybe
> we should do the same.

I believe the underlying obligation is for authors to be diligent in processing 
the issues raised in reviews.  Having reviewers confirm that authors were in 
fact diligent is useful but should be secondary, IMO.

I'm one of those who believe that authors are not obligated to respond to every 
posting by anyone with a stray comment.  In fact, I think it is better for 
authors to wait until other participants have developed a comment thread.  This 
demonstrates some community consensus and it saves massive amounts of author 
time and energy.

However a formally commissioned review is different.  It has a degree of IETF 
sanctioning that ought to elevate the review, to ensure that authors attend 
careful to /all/ of its contents.

This does not, of course, mean that authors must do what the review says, merely 
that they must respond meaningful to what the review says.

Again, I believe this is not specific to AppsArea but should be IETF-wide and 
that the IESG should attempt to confirm that all commissioned reviews have been 
responded and, where reasonable, resolved.

(On the other hand, ADs have sometimes been rather mechanical about invoking a 
Discuss until a reviewer is satisfied with an author's response and I certainly 
do not want to encourage that.)

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Sun, 20 Mar 2011 14:22:31 -0700

Hi Pete,
At 08:11 20-03-2011, Pete Resnick wrote:
>address with the initial proposed changes: I don't want to wait for 
>a month to find out that someone is *not* going to be able to 
>complete a review and then we have to restart the month timer in the 
>queue, especially for what I'm hoping is an early cursory review. Is 
>one week enough time to complete a review of this sort, even if you 
>are only asked to do one per month?

The general agreement was one week for reviews going for IESG 
evaluation and two weeks for other reviews.  Here's when some reviews 
were assigned and when they were submitted:

draft-cheshire-dnsext-dns-sd            2010-12-02   2010-12-03
draft-ietf-sipcore-event-rate-control   2010-12-02   2010-12-15
draft-bryan-metalinkhttp                2011-01-22   2011-02-28
draft-ietf-hokey-ldn-discovery-06       2011-02-01   2011-02-04
draft-holsten-about-uri-scheme-06       2011-02-01   2011-02-07
draft-ietf-netconf-4741bis-07           2011-02-01   2011-02-07

Some reviewers take a week or less.  As some documents are be quite 
lengthy, the review takes more time.  There are also other factors to 
take into account, such as how familiar the reviewer is with the 
subject matter, to determine how long a review may take.

Although I mentioned it several times, team members do not generally 
ask to be put on leave.  I didn't do that last November and it caused 
some delays in posting the assignments.  It is easier for me to plan 
the work if I know about the availability of reviewers.

I suggest that we do a few cursory reviews so that the team gets a 
better idea of how it works and how much work it entails.

Best regards,
-sm

---

From: SM <[email-masked]>
Date: Sun, 20 Mar 2011 13:08:53 -0700

Hi Alexey,

As you are the outgoing Apps Area AD, I can now defriend you. 
:-)  The new Apps Area AD will be Pete Resnick.

I would like to thank you for your support and advice since I took 
over.  You have been extremely responsive.  The output of the 
Applications Area Review Team is a reflection of the work of Peter, 
you and the reviewers.  I enjoyed working with you.  You gave honest 
answers instead of the politically correct line.

>IESG telechat. Maybe we should do the same.

That's a good idea.

>disagree with certain conclusions made by reviewers (e.g. which 
>issues are major, which are minor, which are blocking, etc.).

Yes.

One suggested change that has not be discussed is the Team Lead.  The 
Team Lead should have a good relationship with the Apps Area ADs as 
he or she works under their direction.  Keeping a Team Lead for too 
long does not ensure continuity.  I would like the team to discuss 
with the Apps Area ADs when they meet in person about:

  (i)   Should the Team Lead be selected for a year only

  (ii)  Should the Team Lead have IESG experience to provide better guidance
        to reviewers

Unless there are objections, I will be updating the Applications Area 
Review Team web page to include the email address of the team 
members.  I will also be sending out individual emails on a yearly 
basis to enquire about whether the team member can still take on the 
commitment to perform Apps Area reviews.

Best regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Mar 2011 18:09:40 -0400

--On Sunday, March 20, 2011 13:08 -0700 SM
<[email-masked]> wrote:

> One suggested change that has not be discussed is the Team
> Lead.  The Team Lead should have a good relationship with the
> Apps Area ADs as he or she works under their direction.
> Keeping a Team Lead for too long does not ensure continuity.
> I would like the team to discuss with the Apps Area ADs when
> they meet in person about:
> 
>   (ii)  Should the Team Lead have IESG experience to provide
> better guidance to reviewers

One comment on that question: one of the things the IETF does
much less well than it should is to arrange things that
familiarize new people with how the system works and generally
to do leadership development.  While one might gain something in
efficiency by having a team lead who was a former AD, it would
be _far_ better, IMO, to use the position as an opportunity for
increased understanding of the community, actors, and dynamics
(as I am sure it has been for you).   As long as things are
fairly open, there will always be present and ex-ADs ready to
step in and provide that sort of guidance, perhaps even when the
team lead doesn't want it :-).  But let's not throw away the
opportunity to read more people in on the system in order to
gain small marginal efficiencies by reusing the same folks over
and over again.

    john

---

From: Eric Burger <[email-masked]>
Date: Sun, 20 Mar 2011 19:06:28 -0400

+1,000

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Mar 2011 18:02:22 +0000

>>Keeping a Team Lead for too long does not ensure continuity.
SM, I would like to know why you think that.
I don't think there is a need for changing the Team Lead every year.

>>  (i)   Should the Team Lead be selected for a year only
No, unless this is what the Team Lead candidate wants.

>>better guidance to reviewers
I don't think so.

>gain small marginal efficiencies by reusing the same folks over
+100.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Mar 2011 13:46:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Kurt Zeilenga
> Sent: Saturday, March 19, 2011 6:35 AM
> To: SM
> Cc: Pete Resnick; [email-masked]
> Subject: Re: [apps-review] Suggested changes for Applications Area Review Team
> 
> I suggest instead that after 24 hours without a response, the team lead
> either reassign (such as when time for the review is short) or give the
> assigned reviewer another 24 hours to respond.  After 48 hours of now
> response, always reassign.
> 

+1 to all points.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Mar 2011 13:57:03 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Monday, March 21, 2011 11:02 AM
> To: John C Klensin; SM

I concur.  Continuity across AD terms is a good thing.

And one other point to mention: Although we say explicitly that any of the SecDir, DNSDIR, GenArt, etc. reviews have no more weight than any other LC comments, I think it's also fair to say that this may not be the case in practice.  Most or all of the DISCUSSes I have had to handle in the past that didn't originate with the ADs themselves came from these reviews.  We may say they carry equal weight, but I for one don't buy it.  But I also don't have a problem with that; the people on these lists are experts in their fields and experienced IETF people, and their reviews are essentially solicited (indirectly) by ADs.  I think it's quite reasonable for reviewer comments to bend an AD's ear a little more than usual.

I don't know if we can/should say so in the review templates, but it does seem odd to me every time I read it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Mar 2011 13:59:59 -0700

Howdy Pete,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Pete Resnick
> Sent: Saturday, March 19, 2011 12:30 PM
> To: SM
> Cc: [email-masked]
> Subject: [apps-review] Early Cursory Reviews (Was: Suggested changes for Applications Area Review Team)
>
> [...]

Yes.

> reasonable to ask people to look at one document per week for this kind

At the level of detail you're talking about, weekly seems like an OK request to me.

-MSK

---

From: SM <[email-masked]>
Date: Mon, 21 Mar 2011 14:10:47 -0700

Hi John, Alexey,

>(as I am sure it has been for you).   As long as things are

As a general comment, I agree that the IETF does much less well that 
it comes to leadership development.

I am not going to take a stance on which option is better.  I would 
like the team to discuss the matter and decide on which option it 
prefers.  I have a better understanding than before of the community 
actors and the dynamics as Peter and Alexey have been very 
helpful.  I am sure I can learn something from Pete too.  However, 
what is good for me is not necessarily good for the IETF.

>gain small marginal efficiencies by reusing the same folks over

I am glad to see the ex-ADs on this mailing list stepping in to 
provide guidance.  In pure IETF style, people do not wait to be asked 
before giving their opinion. :-)  It was good to have people actually 
disagreeing with me on the implicit ACK.

>SM, I would like to know why you think that.

There is the continuity of the team and continuity within the 
IETF.  John explained how the position can be useful for leadership 
development.  Continuity is also about changing people with the work 
still getting done.  Such changes can be difficult when the person 
you are replacing has been in that role for a long time.

Best regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Mar 2011 14:20:44 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Monday, March 21, 2011 2:11 PM
> To: John C Klensin; Alexey Melnikov; [email-masked]
> Cc: Pete Resnick

Breadth and depth are often mutually exclusive.

And since ADs have specified terms of office, having an Apps Review Team and APPSAREA co-chairs that persist can only be beneficial.

---

From: Eric Burger <[email-masked]>
Date: Tue, 22 Mar 2011 10:05:52 -0400

As a former, inaugural director of the apps review team, SM & I are 10000% in agreement here. What we are saying is this is a very tough job that after a while you just get burned out. It is an EXCELLENT venue for leadership development - you get to look at the whole area, interact with the grey beards and bald heads, and it has a decent amount of visibility that would not go unnoticed by nomcom. However, it is very stressful. I was not nearly as conscientious as SM, and thus the times for reviews varied from 1 day to 12 weeks. The outliers required multiple prodding and even multiple reviewers to get done.

I would offer that 2 years is a good *target* for the position, possibly call it 2.5years to guarantee overlap with three AD administrations.

On Mar 21, 2011, at 5:10 PM, SM wrote:

> There is the continuity of the team and continuity within the IETF.  John explained how the position can be useful for leadership development.  Continuity is also about changing people with the work still getting done.  Such changes can be difficult when the person you are replacing has been in that role for a long time.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2011 15:31:33 +0000

>I would offer that 2 years is a good *target* for the position, possibly call it 2.5years to guarantee overlap with three AD administrations.
Do we really need to decide on a specific term length?
I would rather the Team Lead resign when she/he feels burnt out, or Apps 
ADs ask the person to step down.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 22 Mar 2011 15:44:56 +0000

On Tue Mar 22 15:31:33 2011, Alexey Melnikov wrote:
> I would rather the Team Lead resign when she/he feels burnt out, or  
> Apps ADs ask the person to step down.

A term gives the option to step down - or be asked to step down -  
with much less fuss.

I don't think there's a requirement to mandate a maximum, either - if  
someone's happy to continue for another term and the AD is willing to  
let them, then that's fine.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Mar 2011 11:48:18 -0400

--On Tuesday, March 22, 2011 15:31 +0000 Alexey Melnikov
<[email-masked]> wrote:

> I would rather the Team Lead resign when she/he feels burnt
> out, or Apps ADs ask the person to step down.

+1.  I think it is perfectly reasonable for prior team leads to
say to an incoming one "you may notice signs of burnout in a
year or two; if you do, quit before they get severe".   But
let's not spend energy making, and then trying to enforce/
interpret, specific rules.

   john

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 22 Mar 2011 10:16:12 -0700

On 3/22/2011 8:31 AM, Alexey Melnikov wrote:
> I would rather the Team Lead resign when she/he feels burnt out, or Apps ADs ask
> the person to step down.

One of the problems with having a task performed well in its early stages is 
that we tend to model this as projecting forward forever.

Waiting for someone to burn out is not a great management policy. The model also 
makes it more difficult if there is a problem with the person doing the job.

Having standardized periods for doing a task makes it easier for everyone to do 
planning, such as for the designated person to get approval from their 
management, and makes it more comfortable to replacement them if their is a problem.

In addition, the rather nice view that this activity can help as a 
stepping-stone for training new folk to take on IETF management positions 
encourage regular turnover.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Mar 2011 10:19:48 -0700

> Sent: Tuesday, March 22, 2011 8:32 AM
> To: Eric Burger
> Cc: [email-masked]

+1.

---

From: SM <[email-masked]>
Date: Tue, 22 Mar 2011 12:01:03 -0700

Hi Dave,
>A term gives the option to step down - or be asked to step down -

I avoided the word "term" as I view the selection as informal.  The 
conversation might go like this:

AD: Would you like to be team lead?  Your predecessors did the work 
for period X.

Candidate: What's the pay like?

AD: Twice as much what we pay the reviewers.

Candidate: Where do I sign up?

I'll answer the question before it gets asked; I don't feel burnt out 
yet.  I may be the last person to see the signs.  If anyone ever 
notices that, please do tell me.  I don't have any issue with 
Pete.  There couldn't be a better time to open this discussion as 
there aren't any elements that might cause a fuss.

Best regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 22 Mar 2011 12:58:33 -0700

> I'll answer the question before it gets asked; I don't feel burnt out yet. I may
> be the last person to see the signs. If anyone ever notices that, please do tell
> me. I don't have any issue with Pete. There couldn't be a better time to open
> this discussion as there aren't any elements that might cause a fuss.

And as long as we are dotting the i's and crossing the t's of delicacy and to o 
make sure there is no confusion from my side:  None of this is about you or your 
performance.  It's a design discussion purely.

As much as you all know that I hate to offer criticisms, I'm sure that were you 
doing something onerous I, or some other apps wallflower, would overcome our 
hesitance to comment on it.

If anything, as I implied in my previous note, you've distorted the discussion 
by having done such a /good/ job.  Makes it more difficult to juggle the 
possibility of the alternative...

d/

-- 

   Dave Crocker

---

From: Dave Cridland <[email-masked]>
Date: Tue, 22 Mar 2011 21:09:08 +0000

On Tue Mar 22 19:01:03 2011, SM wrote:
> I avoided the word "term" as I view the selection as informal.

Right, and for you that's a good thing.

As Dave Crocker points out, you're doing a sufficiently good job that  
you're distorting our perception of it. In addition, you're your own  
boss, which means you don't have to justify the time to anyone else,  
and nobody else is trying to do resource planning around you.

>   The conversation might go like this:

Or it might go:

Candidate: Boss, I've been asked to continue my APPs are tech review  
team lead position for another term of two years.

Boss: Okay.

Making a formal term sounds distastefully formal, I know, but it has  
the effect of being able to be presented to management .

Other conversation become easier, too:

AD: I'd like someone else to have a term of doing this, if that's  
okay?

Team Lead: OK, I'll step down at the end of the term.

Finally, a formal term may well help reduce burn-out - instead of  
"Can I do this position for another day?", the question becomes "Can  
I do this position for another term?" which is a lot easier to  
consider.

Dave.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 22 Mar 2011 14:14:42 -0700

On 3/22/2011 2:09 PM, Dave Cridland wrote:
> Finally, a formal term may well help reduce burn-out - instead of "Can I do this
> position for another day?", the question becomes "Can I do this position for
> another term?" which is a lot easier to consider.

This is a deceptively important point.  As I recall, there's all sorts of 
'psychology of decision making' research to back it up.' For those who know the 
reference to the frog in water that is gradually heated, this is a bit like that.

Making a decision to continue on a daily basis makes it more likely that there 
will be burnout than having to make it once every 2 years.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Mar 2011 18:08:40 -0400

--On Tuesday, March 22, 2011 14:14 -0700 Dave CROCKER
<[email-masked]> wrote:

>> Finally, a formal term may well help reduce burn-out -
>> instead of "Can I do this position for another day?", the
>> question becomes "Can I do this position for another term?"
>> which is a lot easier to consider.
> 
> 
> This is a deceptively important point.  As I recall, there's
> all sorts of 'psychology of decision making' research to back
> it up.' For those who know the reference to the frog in water
> that is gradually heated, this is a bit like that.
> 
> Making a decision to continue on a daily basis makes it more
> likely that there will be burnout than having to make it once
> every 2 years.

Actually, while the principle is correct (and certainly
supported by the literature to which you refer), I don't think
the "daily versus two years" inference is quite right (or
supported by the literature).    The problem with relatively
long-ish terms is that people who feel like they have signed up
for them tend to want to "keep the commitment" and tough it out,
even after burnout has clearly set in.   For examples of that,
we need look no further than a succession of ADs  who have
served extremely well for a term or two, then burned out six
months or a year into an additional term but continued to serve
(and to get harder and harder to work with) for the full
two-year period.

If you had said something that amounted to "review every six
months", I'd agree.  But, in terms of burnout risk, two years is
a long enough cycle to cause a problem different from the one
you are trying to prevent but no less of a risk.

   john

---

From: SM <[email-masked]>
Date: Tue, 22 Mar 2011 15:24:18 -0700

Hi Dave,
At 12:58 22-03-2011, Dave CROCKER wrote:
>And as long as we are dotting the i's and crossing the t's of 
>delicacy and to o make sure there is no confusion from my 
>side:  None of this is about you or your performance.  It's a design 
>discussion purely.

I am reading it as a design discussion.

>If anything, as I implied in my previous note, you've distorted the 
>discussion by having done such a /good/ job.  Makes it more 
>difficult to juggle the possibility of the alternative...

Thanks.  I'll highlight a previous comment you made "Waiting for 
someone to burn out is not a great management policy".  If everything 
is working well, is it is worth the effort to have this discussion 
and consider the alternative?  I believe it is a good time to do so 
as we can then have this light-weight discussion.

Best regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 22 Mar 2011 15:56:29 -0700

>  If everything is working well, is it is
> worth the effort to have this discussion and consider the alternative? I believe
> it is a good time to do so as we can then have this light-weight discussion.

On the average, it's better to have planning and design discussions in the 
absence of crisis...

d/
-- 

   Dave Crocker