Subject: [appsdir] Rough notes from the App Chairs and AppsDir lunch meeting at IETF 86

From: Applications Area Directors <[email-masked]>
Date: Mon, 11 Mar 2013 13:22:53 -0400

Rough notes from the App Chairs and AppsDir lunch meeting at IETF 86,
Monday, 11 March.  Please send me corrections, additions, and comments.

*Look for chairs and appsdir members*

   - ACTION: All chairs who are not already appsdir members, please
   consider joining; see SM.
   - ACTION: All chairs, please keep an eye out in your working groups for
   active, insightful participants who can join appsdir and/or who might be
   good as new chairs.  See Barry/Pete.

*Writing quality & reviews*
Discussion of writing quality of documents, and how that affects reviews.
Note that focusing on issues is better than spending time & effort on nits.
At the same time, too many nits can make for a very hard-to-read document,
so calling that out is important.

*Document shepherds*
Brief discussion of document shepherding.

   - ACTION: When you're shepherding a document, the ADs expect you to have
   thoroughly reviewed the document.  Please post your shepherd review to the
   mailing list, so it's on record.
   - ACTION: Please have a look at draft-leiba-extended-doc-shepherd.
    Comments to Barry, and also consider following the advice described in it.

*Using the datatracker*
Brief discussion of ongoing enhancements to the datatracker.  There's a new
feature that's not quite finished, which allows submission of a document
through a tracker state change (email is triggered automatically).

   - ACTION: Chairs, please always set the shepherd field in the
   datatracker and post shepherd writeup to the datatracker.
   - ACTION: Request publication by setting document state to "Sent to IESG
   for Publication", and *also* (for now), send email to the AD noting that
   you did that.  No need to include the shepherd writeup if you have put the
   writeup into the tracker.

*DISCUSS positions to WG lists?*
Discussion of whether IESG DISCUSS positions, along with the ensuing
discussion, should be copied to the WG mailing lists.  Extended discussion
-- mostly support on the grounds of openness and accountability, but some
concern about "noise" on the mailing lists, opening old wounds, that sort
of thing.

   - ACTION: App ADs will do this on an experimental basis; if you want to
   try it for your working group, please let your AD know.

*Target audience, who understands the doc?*
WGs often respond to cross-area questions by saying that anyone who works
in this space would understand this.  But is that really true?  Where do we
find the balance between saying too much (we can't explain *everything*)
and not saying enough (and getting bad implementations because people *don't
* really understand)?

--
Barry

---

From: SM <[email-masked]>
Date: Mon, 11 Mar 2013 13:01:42 -0700

At 10:22 AM 3/11/2013, Applications Area Directors wrote:
>Writing quality & reviews
>At the same time, too many nits can make for a very hard-to-read 
>document, so calling that out is important.

Barry, thanks for the notes.

There is currently a section for nits in the template ( 
http://trac.tools.ietf.org/area/app/trac/wiki/template ).  I suggest 
removing that section so that nits are not part of AppsDir 
review.  The reason is as explained above.  If you have any opinion 
please post them to the mailing list.

Best regards,
-sm

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 11 Mar 2013 16:19:05 -0400

On Mar 11, 2013, at 16:01, SM <[email-masked]> wrote:

> opinion

As I said in the meeting, in addition to taking out the section from the template there should be a suggestion to send any nits collected right to the authors, and an admonition to only do this where the substance of the document is not touched.

Grüße, Carsten

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 12 Mar 2013 14:23:11 +0900

I think different reviewers deal different with nits. Some reviewers 
just read over them, without noticing. Some others may notice them, but 
don't care too much. Some may not feel okay if they don't report the 
nits they have seen.

I personally belong into the last category. Carsten's proposal to send 
nits separately would only create more work for me.

I have nothing against saying somewhere that reviewers should focus on 
issues rather than on nits, but I don't think it's necessary to dictate 
how the reviewers have to do the reviews; they should be allowed to do 
what works best for them.

Regards,   Martin.

On 2013/03/12 5:19, Carsten Bormann wrote:
> On Mar 11, 2013, at 16:01, SM<[email-masked]>  wrote:
>
>> opinion
>
> _______________________________________________
> appsdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/appsdir
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Mar 2013 09:09:33 -0400

> issues rather than on nits, but I don't think it's necessary to dictate how
> the reviewers have to do the reviews; they should be allowed to do what
> works best for them.

No one is "dictating" anything; we're talking about suggestions and
general guidelines.

The bottom line is that we very much appreciate the reviews, and we
thank the reviewers for taking the time and trouble to do them.

Barry

---

From: SM <[email-masked]>
Date: Tue, 12 Mar 2013 06:38:53 -0700

At 01:19 PM 3/11/2013, Carsten Bormann wrote:
>As I said in the meeting, in addition to taking 
>out the section from the template there should 
>be a suggestion to send any nits collected right 
>to the authors, and an admonition to only do 
>this where the substance of the document is not touched.

Thanks for the feedback.  I should have mentioned 
the above.  At least we have a mailing list so 
that we can discuss about the pros and cons with everyone.

At 10:23 PM 3/11/2013, Martin J. Dürst wrote:
>I think different reviewers deal different with 
>nits. Some reviewers just read over them, 
>without noticing. Some others may notice them, 
>but don't care too much. Some may not feel okay 
>if they don't report the nits they have seen.
>
>I personally belong into the last category. 
>Carsten's proposal to send nits separately would only create more work for me.
>
>I have nothing against saying somewhere that 
>reviewers should focus on issues rather than on 
>nits, but I don't think it's necessary to 
>dictate how the reviewers have to do the 
>reviews; they should be allowed to do what works best for them.

Reviewers already focus on issues.  As a quick 
comment for context, Pete mentioned that he might 
be distracted by the nits and miss the issues 
mentioned in the review.  The suggestion was to 
remove the nits section from the template.  That 
does not mean that you should not include 
nits.  The template is a guidance; i.e. it's 
there to make the life of the reviewer easier.

Best regards,
-sm

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Mar 2013 09:49:57 -0400

On 12 Mar 2013, at 01:23, "Martin J. Dürst" <[email-masked]> wrote:

> I think different reviewers deal different with nits. Some reviewers just read over them, without noticing. Some others may notice them, but don't care too much. Some may not feel okay if they don't report the nits they have seen.
> 
> I personally belong into the last category. Carsten's proposal to send nits separately would only create more work for me.
> 
> I have nothing against saying somewhere that reviewers should focus on issues rather than on nits, but I don't think it's necessary to dictate how the reviewers have to do the reviews; they should be allowed to do what works best for them.

+1!

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 12 Mar 2013 18:29:06 +0100 (CET)

>> I have nothing against saying somewhere that reviewers should focus on issues rather than on nits, but I don't think it's necessary to dictate how the reviewers have to do the reviews; they should…

same for me!

------------------------------------------------------------------------------
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: Tim Bray <[email-masked]>
Date: Tue, 12 Mar 2013 10:34:14 -0700

The template is perfectly clear. Important stuff first, nits later.  This
makes the task straightforward for:
- the reviewer - keep one review doc open as you read, pour comments into
the appropriate section
- IESG other content-oriented readers of the review - stop reading when you
get to “nits”
- doc editors - you have to read the review end-to-end

It ain’t broken, don’t fix it. -T

On Tue, Mar 12, 2013 at 6:38 AM, SM <[email-masked]> wrote:

>> As I said in the meeting, in addition to taking out the section from the
>> template there should be a suggestion to send any nits collected right to
>> the authors, and an admonition to only do this where the substance of the
>> document is not touched.
>>
>
> Thanks for the feedback.  I should have mentioned the above.  At least we
> have a mailing list so that we can discuss about the pros and cons with
> everyone.
>
>> I think different reviewers deal different with nits. Some reviewers just
>> read over them, without noticing. Some others may notice them, but don't
>> care too much. Some may not feel okay if they don't report the nits they
>> have seen.
>>
> Reviewers already focus on issues.  As a quick comment for context, Pete
> mentioned that he might be distracted by the nits and miss the issues
> mentioned in the review.  The suggestion was to remove the nits section
> from the template.  That does not mean that you should not include nits.
>  The template is a guidance; i.e. it's there to make the life of the
> reviewer easier.
>
> Best regards,
> -sm
> ______________________________**_________________
> appsdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/appsdir<https://www.ietf.org/mailman/listinfo/appsdir>
>

---

From: SM <[email-masked]>
Date: Mon, 18 Mar 2013 21:54:40 -0700

At 10:34 12-03-2013, Tim Bray wrote:
>The template is perfectly clear. Important stuff first, nits 
>later.  This makes the task straightforward for:
>- the reviewer - keep one review doc open as you read, pour comments 
>into the appropriate section
>- IESG other content-oriented readers of the review - stop reading 
>when you get to "nits"

I like the above. :-)

>It ain't broken, don't fix it. -T

I'll leave the template unchanged.

Best regards,
-sm