On Mon, Nov 26, 2007 at 03:04:15PM -0800, Stephen Lau wrote:
> It was my impression the committee was to be confined to the homepage.
>
> There are tons of changes that happen in various
> non-project-specific/non-community-specific pages (John cited some:
> Roadmap, FAQ, etc.) - it doesn't make sense to me that a committee needs
> to be in charge of voting on all these changes. It also doesn't make
So it's ok for me to go edit the FAQ to say "Is it true that
OpenSolaris rulez, GNU/Linux droolz? Yes."? Or whatever other
arbitrary changes I want to make? And since you won't know that the
page was changed (no watch functionality) or who changed it (no audit
trail), not only will you not have any opportunity to review the
change but you won't even know it was made until 6 months later when
you see someone quote the stupid/wrong/misworded material.
> sense to me to have the individual making the change make the decision
> as to whether it's a trivial change or not.
Sure it does. If there's any doubt, go to the committee. If an
individual develops a track record of poor judgment, the committee can
simply instruct that individual not to make any more changes of any
kind without express approval.
Of course, others have suggested that the code review model is more
appropriate. I can see the argument for reviewing every change but
I'm worried that the cost would exceed the benefit. The committee
will have to decide where the thresholds are and what needs to happen
when each is crossed.
> Changes to the homepage are rare enough, and important enough, that I
> think having the committee focused specifically on the homepage is
> good. Having it in charge of other pages seems to be overly heavy-weight.
> If we really do want it to be an editorial committee in charge of pages
> at large, then I would ask that it be an oversight committee that "takes
> offense" at changes rather than requiring changes be brought before them
> for approval; if that makes sense.
One of the advantages of reviewing changes before they're made is that
there won't be any finger-pointing: everyone will know who requested
the change, who approved it, and why.
It's hard to believe there's a change so urgent, the need for which is
first known so close to the time it is needed, that letting the
committee review it for a few days is too burdensome. It's also hard
to believe anything could possibly be more heavy-weight than two weeks
of nonstop heated argument among dozens of people on the mailing
lists. Surely any process is better than one that lets arbitrary
people do arbitrary things whenever they want, with no review, no
records, and huge arguments after that fact. Given the choice between
making people go through an open review committee when they want to
make a change and subjecting them to weeks of acrimony if the change
turns out to be unpopular, I'll take the committee every time. And
I'd rather we make that call now, not after an incident that involves
some page we thought wasn't important enough to warrant review. If
those pages aren't important enough to have changes reviewed and
recorded, they're also not important enough to keep.
If there's disagreement over the committee's scope, we should rewrite
its charter to be more explicit. If we do that, it should explicitly
cover everything that is not:
(1) Hidden[0], OR
(2) Part of any Group or Project sub-site
[0] A page explicitly intended as a mock-up or test, not for public
viewing. Hidden pages must be unreachable from any navigation element
or link within the site. The main landing page returned when no
directory or filename URL components are present is never a hidden
page. Additionally, hidden pages must be labeled as such when
displayed.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
