incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Making mailing lists useful (was Re: [Proposal])
Date Sat, 13 Aug 2011 12:37:18 GMT
On Sat, Aug 13, 2011 at 6:11 AM, TJ Frazier <> wrote:
> On 8/12/2011 08:47, Nóirín Plunkett wrote:
>> 2011/8/12 Jürgen Schmidt<>:
>>> On Fri, Aug 12, 2011 at 12:19 AM, Simon Phipps<>  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 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

> 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.

> [1]
> [2]
> [3]
>  (busted link, 404)
> --
> /tj/

View raw message