Re: [Icar] Input based on SIRS experience

(How embarrassing.  I've no idea why my previous posting wrapped so 
strangely, other than the quirkiness of a new mail client.  Here's an 
attempt to re-post, maybe without the problem... /d)

Adding my own thoughts to the archive, since the topic came up, and with 
the hope it can added to the discussion:

-    It was not much effort to get a core of reviewers signed up.

This suggests a good core of community motivation to help.  We have not 
needed more, so we do not know whether an effort like this can attract 
_enough_ qualified reviewers.

-    I am not sure how to interpret the low number of review requests.

It is easy to say that it is due to lack of community awareness or 
interest or trust in the SIRs effort.  Certainly we have not done as 
much marketing as we might have wished. However this view is confounded 
by the very slow metabolic rate of the IETF and the fact that the effort 
began at the beginning of a summer. 

No doubt there probably are other factors.  Cliches like 'tipping point' 
and 'crossing the chasm' were created for just this sort of issue in 
adopting change. For example, it may be that it is more difficult to 
change existing working group efforts than it is to get integrated in 
with new(er) ones. Certainly we have not done any serious, sustained 
effort to get working groups to request reviews.

On doing the administrative side of this effort, there are some things 
that I suspect are strategic, besides the relatively obvious fact that 
this really does take some ongoing, administrative effort, more than I 
had expected. (But, then, I always underestimate these things.)

-    It needs to be easy to have a record of the review process for a
     document and, by derivation, an ability to see the whole set of 
     review efforts.  

-    There should be a central point for tracking review efforts and a 
     central point for accessing reviews.

Besides the obvious, local and tactical benefit to the individual 
working group, this permits the community to get the ability to review 
the _set _of reviews and get a sense of the effort and result of doing 
reviews.  In other words, it has marketing value.  It makes it easy for 
others to see that there is review activity and it makes it easy for 
them to evaluate the nature and quality of those reviews.  This will 
make them more comfortable getting reviews for their own efforts and 
will help them decide on what reviewers to ask for. Whether this needs 
to be a permanent, formal archive, like RFCs, an ephemeral, formal 
archive, like I-Ds, or an unofficial, ephemeral archive like a WG 
mailing list, has not been resolved.

My own thought is that formal publication (RFC and even I-D) is far too
much overhead.  The only existing mechanism is the mailing list. 
Creating a new mechanism strikes me as too much effort, and added effort 
is a very large barrier to adoption of this process.

Opening up the IETF Tracker to working group chairs, and adding the 
review construct and/or allowing free-form entries would help this 
enormously. (Free-form means that the IETF does not have to formally 
adopt the thing being tracked.)  This means reviews -- and other 
activities -- could be tracked much sooner than would be possible if we 
first have to get IETF-wide approval of the review process.

-    I am not sure whether selection of reviewers, by requesters,  needs 
     to be different than we set up.

A web page with a list of bios, and a mailing list for sending requests
to is probably fine.

The public discussion about reviewing shows that the community is still 
working on clarifying what types of reviews are needed, when, and how to 
use them.

-    There is also the small matter of the SIRS reviews that have been 
     done.

Have they been they type that are needed?  Should they be done 
differently? We have not tried to assess this. Certainly we cannot 
expect regular, widespread use of a review process until working groups 
know what to ask for, or at least what to expect they will get and how 
they should use the results.

d/

--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>

_______________________________________________
Icar mailing list
Icar@ietf.org
https://www1.ietf.org/mailman/listinfo/icar