Keith M Wesolowski wrote: > 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. > I guess I trust the current people editing website content to not post that kind of stuff. They haven't in the past and I don't expect them to in the future. I agree that if any arbitrary person could edit those pages then a more rigorous process would be necessary, but I don't see that need now. >> 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 > But what if the individual doesn't have doubt - but others do? It's entirely subjective. > 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. > Fair enough. > 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. > I think the code review model is too heavy-weight. The cost would entirely exceed the benefit, imho. >> 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 > To be fair, it's not arbitrary people doing arbitrary things whenever they want. The Indiana homepage fiasco aside, I think the process driving all the other web content updates (roadmap, no_source, and download pages come to mind) have been frequent, responsible, and accurate. > 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. > I agree a committee is needed when there are contentious or high-visibility/impacting changes - but the truth is, we don't see those things except for on the homepage. I think this committee should thus explicitly be focused on the homepage, and have its responsibilities expanded on an as-needed basis. > 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. > > Off-topic thought... one thing that is really pointing out is the need for these sorts of things to be under a proper CMS with an accounting/audit trail.
cheers, steve -- stephen lau | stevel at opensolaris.org | www.whacked.net
