Bill Sommerfeld wrote:
> On Mon, 2007-11-26 at 14:17 -0800, John Plocher wrote:
>> Derek Cicero wrote:
>>> What is the threshold for changes? (I assume we can fix typos w/o
>>> approval?)
>>
>> What sort of editorial policy are you expecting?
>>
>> My hope is that the team would come up with some triage
>> mantra like the ARCs use:
>>
>> If it is not likely to be controversial, and it is an
>> obviously right thing to do, then just do it.
>
> I think code review is a better model for website changes..
I agree - for a few key pages. For the majority, though, no - its not
worth it.
Code reviews happen because the cost of not having them (and having
to go back and fix things) is large. I'd argue that on a web site, the
cost of fixing something is much smaller than for OS/Net kernel code;
for things other than a couple of main pages, it is close to zero. This
is why we can and do delegate page editorship to project leads, it is
also why public wikis (www.genunix.org...) work so well.
Communities are built out of people, and people work best when they are
given responsibility, which implies trust. Requiring everything to be
code reviewed by N+1 brains implies an unreasonable level of distrust.
There must be a middle ground - such as the following:
80% being just-do-it obvious
15% being N>=2 code review
5% being committee review
> I would hope that at the very least there would be an N-brain rule (with
> N starting somewhere around 2 or 3): at least N people (including the
> person working on the change) have to understand and agree with the
> proposed change before it can be put into effect.
You won't find N+1 brains to do ALL that work - at least not for
the majority of the content work that is actually done. All such
a blanket requirement will do (IMO) is discourage most everyone
from trying to help.
-John
