[arc-discuss] ARC Community organization

[James Carlson]

Darren Reed writes:
> Is there a list of "informal rules" that govern ARC cases?

The lack of a list is sort of what makes them informal ...

> How would an outsider to this process become aware of
> this and other such "informal" rules in order to gain better
> understanding of what they see or correctly interact with
> the process?

Either by asking or by participating long enough, I think.

> >> To me this expectation seems to be abuse of the PSARC meeting
> >> as a way to have fast tracks approved more quickly than they
> >  
> > I think this is a rather extreme accusation to be making.  I'd like
> > you to specify exactly *who* you think is abusing the system and when
> > and where this was done so that we can take corrective action.
> 
> 
> It's not any one person, but more of an observation of the way
> in which people (in general, so perhaps all of ON) use the process.
> Now obviously maybe it's me who's the odd one out here, but
> how many fast tracks have their timers expire vs are approved
> early?  The point here being that if the ARC behaves in a manner

Most are approved early -- but only after noting that some time has
elapsed, there seems to be either consensus or no commentary at all on
the list, and (importantly!) that nobody with an interest has bothered
to show up at ARC business and ask questions.  We review all of this
during ARC business.

I know that there was an effort at one point in the past to gather
detailed statistics on ARC operation -- John Plocher probably has the
details on that.  Time-to-approval is one of the key metrics.

> that undermines its own process then people will continue to
> expect that - or to put it differently, I believe the ARC is digging
> itself into a hole here that may be hard for it to get out of.

I think that accusing the folks involved of digging holes or abusing
the process does much more to undermine the process.  If you're going
to make such accusations, I think it would help everyone to cite
specific cases that concern you so that we can dissect them and find
out what went wrong.

Talking about this in generalities does _nothing_ to help and merely
serves to spread fear, uncertainty, and doubt.  That's not progress.

> To invent some numbers, if 60% of fast tracks are approved
> without running to the full extent of their timeout, is that an
> indication that:
> a) the default timeout is too long
> b) people are incorrectly filing things as fast tracks that should
>    be closed/approved automatic
> c) we're approving things too quickly
> d) none of the above

I'd vote for:

	(e) the process is working exactly as intended.

> >However, the ARC process is open, and it's the responsibility of
> >everyone interested in architecture to watch the cases being reviewed.
> >If you see one go by that you might be interested in, but can't review
> >or comment right away, then (a) request more time and (b) specify some
> >_reasonable_ date when you'll be able to provide comments.
> >  
> >
> 
> I'm unclear as to why the latter half is required for a case that
> will be closed/approved prematurely as surely the definition of
> the process means that a "reasonable" date is the expiration
> date, which is 7 days after the case is filed.

Because the ARC meeting itself is used as a checkpoint.  If you have
any issues with any proposal that's before the ARC then _show up_.

The timer is the point at which the case is automatically approved if
nothing else happens.  It's not a grant to wait on a review.

> >Both the submitter of the fast-track and the sponsor are on the hook
> >to make sure that the changes listed conform with the expectations of
> >a fast-track.  That means that they're "obvious" and
> >"non-controversial."  If they're anything else, then they should end
> >up derailed for a full review.
> >  
> >
> 
> On the other side of fast tracks, I'd like to see more exploration
> and understanding of what it means for cases to be considered
> candidates for automatic approval.

"Automatic" approval -- a special case that I think does get used far
too often -- is for things on which no discussion ought to be
required, but that are being recorded via the ARC for posterity.  An
example of a reasonable "automatic" approval might be a simple change
to a Project Private interface with no contracts or change in overall
architecture.

Fast-tracks are things that are (as I mentioned) "obvious" and
"non-controversial."  Things that aren't obvious or have real
controversy around them need to be reviewed as full cases.

> i.e. if a submitter expects a case to be "approved" in 24-48 hours,
> is it really a fast track?  or should it be closed approved-automatic?

Certainly not.  It has nothing to do with how quickly the submitter
needs to have it approved.

It's entirely reasonable for the sponsor to ask for quick turn-around
based on external issues, such as a hot bug fix or the pending closure
of an important build.  Sometimes, those cases get short timers.

It's _not_ reasonable to adjust the type of review based on the
expected turn-around time.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677