On Sat, Aug 13, 2011 at 9:45 AM, TJ Frazier <tjfraz...@cfl.rr.com> wrote: > On 8/13/2011 08:37, Rob Weir wrote: >> >> On Sat, Aug 13, 2011 at 6:11 AM, TJ Frazier<tjfraz...@cfl.rr.com> wrote: >>> >>> On 8/12/2011 08:47, Nóirín Plunkett wrote: >>>> >>>> 2011/8/12 Jürgen Schmidt<jogischm...@googlemail.com>: >>>>> >>>>> On Fri, Aug 12, 2011 at 12:19 AM, Simon Phipps<si...@webmink.com> >>>>> 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. >
Yes, a wiki makes it easier/faster to make corrections. But it also makes it easier/faster to enter errors. And a wiki that is wide open to allow anyone to enter fixes is also wide open to allow anyone to enter errors, or spam. A wiki as technology is neutral with respect to quality. Think of it this way, if you take typing lessons, that would make it easier/faster for you to program. But would that make the quality of the code better? Of course not. If the goal is to improve the quality of the wiki, then let's start a thread on that. We can learn a lot from Wikipedia there. Things like bad links and spelling and structural errors are often dealt with by bots. Humans are best used for higher level tasks, like finding subtle bugs in the logic of a program, or rewriting a poorly written wiki page to make it clearer. >> >>> [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/ > >
