Mark Martin wrote:
>> PSARC/2007/641 - Enabling built-in extensions.
>> PSARC/2007/552 - Upgrading PHP 5.2.4
>> PSARC/2007/470 - Upgrading PHP 5.2.3
>> PSARC/2007/168 - Integrating PHP 5.2.0
>> PSARC/2008/538 - Integrating PHP 5.2.6
>>
> I'm sure you mean LSARC/2008/538.. It seems odd that it switched from
> PSARC->LSARC. <shrug>. I'm still trying to figure out where that line
> is, and continue to be surprised. I'm sure I'll get it eventually.
There is intentionally a lot of overlap between the ARCs, so it's not
always "obvious" where a given project proposal belongs just on the
title or even the project details.
When we decide on an ARC to review a case, we consider several things:
- Does it look like "platform" material or like "layered" software?
(This is likely the question you were focusing on.)
- Where have other projects in this technical area been reviewed?
Does one of the ARCs have more institutional memory of the issues
than another?
- Are there other related projects (either dependent on or otherwise
entangled) that are in review now, or that are known to be in
progress, and where are those being handled? As much as possible,
we want to avoid having complex dependencies evaluated by different
ARCs, because it's likely that something will be missed. It's
better to have provider and consumer reviewed in the same ARC,
even if that forces a few projects to be reviewed by an "unexpected"
ARC.
- Are there specific people on one of the ARCs who know more about
this technical area? ARC members are expected to be generalists
to a great degree, but we obviously have different experience just
the same.
- Are there load-balancing or even cross-training issues to be
considered? Sometimes, one of the ARCs just has too many or too
few cases in line. We've even had cases where there's a long-
term plan by SAC or the ARC chairs to bring up a new ARC or shut
down a dormant one, and this causes us to move cases around for
the purpose of getting another ARC up to speed.
In short, though, it's a discussion. The initial discussion is held by
the ARC chairs when a new project 1-pager comes in. They discuss by
email which ARC it should go to. Usually, it's obvious and trivial and
matches exactly what the submitter asked for. In a few cases, it's not.
In some cases, it'll be sent to one ARC but we'll ask members from
another ARC to attend the review.
Later changes can be made as well. Sometimes, a project team will ask
to be moved from one ARC to another. Since members from one ARC will
end up visiting another, such changes likely don't accomplish much, but
there are folks who perceive differences where there are none, and it's
usually easier to accommodate such requests than to argue.
Another reason for a late change is that we discover we've made a
mistake. If a project comes in, gets assigned to PSARC (for example),
and then we discover a flurry of closely-related projects or fast-tracks
in LSARC, we'll move the original case over to be with its kin.
We don't always know what's coming at us, and project teams don't always
give us the big picture of what they're doing, so it can be hard to get
the assignment right.
Fortunately, it doesn't have to be right all the time, because at least
some review by an outside group of folks is certainly better than none,
and that's the most important part.
--
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
