On 8/13/2011 08:37, Rob Weir wrote:
On Sat, Aug 13, 2011 at 6:11 AM, TJ Frazier<[email protected]> wrote:
On 8/12/2011 08:47, Nóirín Plunkett wrote:
2011/8/12 Jürgen Schmidt<[email protected]>:
On Fri, Aug 12, 2011 at 12:19 AM, Simon Phipps<[email protected]> wrote:
Maybe. But I see no reason why this list needs the protection of being
on a
controlled access page and would suggest doing so is what needs
justifying.
I have not seen a reasoned counter to my proposal for it to be on the
community wiki, so will probably create such a page soon (unless someone
else wants to).
I think Rob has already pointed out why the list of tags besides the
mailing
list is a good idea and i support it.
Just so that silence isn't assumed to be assent, I think both Rob and
Simon have good points, but I support the idea of putting the list of
tags in a location that's more accessible to new contributions (ie,
the wiki), even if that means it has to be one extra click for folk
who visit the website.
Noirin
The recent changes to the ML page provide an accidental illustration of why
most things belong on the wiki: web pages tend to get shabby and
out-of-date.
The ML page[1] changes were very nicely done. Following the "these
guidelines" link like a good little newbie led me to the ASF page[2] on
email tips. In the "Other email guidelines" section, I also followed the
links; one[3] gave me a 404 error. Link rot.
My hypothesis — I call it the Curse of the Web Page — is that such decay is
inevitable in a high-barrier-to-change environment, without a dedicated
corps of maintainers (a dull job). Old hands (who could fix things) are
unlikely to access the page at all (they already know this stuff), or
they're looking for something specific and wouldn't notice problems
elsewhere. Newbies, mousing around, /will/ notice, but can't fix it. The
Curse is not limited to links: typos, spelling, and other infelicities are
all evident on Apache pages; they need a little TLC.
The way to deal with dead links is to run a link checker on the site
occasionally. That does far better than a casual user will do to find
these kinds of issues. Then you can fix them all in one batch. I
assume OO.org already did something like this? Even major sites that
depend on crowd sourcing editing, like Wikipedia, rely on bots to
detect dead links.
Think of it this way: You've heard of Linus's Law : "given enough
eyesballs, all bugs shallow", right? But that doesn't mean that you
ignore compiler warnings. Automated checking has an important role as
well.
On a wiki, the technically adept newbie might fix the problem right there;
others would just leave a note on the Talk page.
How would you fix it in this case? Our page links to a valid page
outside our project, right? And then that external page has a broken
link. Even if our project used a wiki for our mailing list page,
there is no way we could fix this problem from within our wiki.
The Curse applies not just to AOOo, or the Incubator, but to the whole
ASF — and so do the hallowed rites of propitiation. That is, their page
should have been on /their/ wiki, for easy fixing / noting.
Dead links are only one problem. Some of the other glitches are subject
to automatic detection: spelling, for example. I don't know what the CMS
editor offers; the MW editor does pretty well. Still, it is amazing how
many people ignore spell-checkers, even in their email clients.
Other glitches still need eyeballs: there / their / they're, &c. (The
grammar-checking folks are working on this, but ...) My point is that
newbie eyeballs are most likely to see glitches, and newbies should have
an easy way to fix or note the glitch. A wiki provides this.
[1] http://incubator.apache.org/openofficeorg/mailing-lists.html
[2] http://www.apache.org/dev/contrib-email-tips.html
[3]
http://cocoon.apache.org/community/contrib.html#Contribution+Notes+and+Tips
(busted link, 404)
--
/tj/
--
/tj/
"Dun stopper torque wet strainers." /Ladle Rat Rotten Hut/
