What about extending the wiki...?

Bill Maltby, LFS Organizational bill at nospam.dot
Sat Mar 13 04:27:17 PST 2004

On Sat, 13 Mar 2004, Jeroen Coumans wrote:

> Anderson Lizardo said the following on 03/12/04 19:59:
> > On Sex, 12 Mar 2004 18:29:39 +0100, Jeroen Coumans wrote:
> >
> >><snip>

> > Look how Jeroen's time to maintain the website and the FAQ got reduced,
> > we must take into account that with a Wiki it will be a lot easy to the
> > visitor itself fix a typo or a mirror maintainer fix his entry on the
> > mirrors list. That is, we from the website team will be "freed" from
> > trivial changes.

I support that.

> The idea is indeed to put the burden of adding and maintaining good
> content on the community, as it should be. What if both myself and you
> disappear from the community? Currently I'm not sure who's able to fill
> the gap. I'm looking for a permanent solution which is community-based
> so it needs the least possible administration. A wiki is the natural choice.

If site you propose is to support interaction between community *users*
of the *LFS products, I can support that. I can not support its use as
the platform that presents the final products if it is open to
modification by anybody at any time.

> And I have enough trust in our userbase that they will do a great job of
> self-regulation.

Have you not been watching all the lists? This is a naive POV, IMO.

> Also, this is a chance for the community to become more
> involved into the writing in a more permanent way, just as the hints
> have encouraged people.

There is a big difference between hints and the "official" *LFS
products. Hints need have no concern for consistency of presentation or
coordination with other facets of the project. Books are different. A
website is different.

> A Wiki could even absorb the hints project (and
> perhaps the patches too). In fact, in the long run, I think it should. I
> think the Wiki is the next logical step to sustain, evolve, progress and
> consolidate our community and its knowledge more efficiently. Take the
> following bottom-to-top communication channels (bottom=user, top=leaders)
> - IRC: very fast, one-to-many communication "no" archives. Excellent for
> quickies & support
> - Mailinglist & newsgroups: low-barrier, one-to-many communication with
> archives. Excellent for extending community knowledge & discussion.
> Archives are badly navigatable though, thus community knowledge quickly
> disappears and every newcomer has to relearn everything.

No, community knowledge does not "disappear". It just must be found.
Every newcomer has to relearn, or not, regardless of the storage and
presentation structure.

> - Wiki: low-barrier, one-to-many & many-to-one communication with
> archives & easily navigatable. Excellent for extending community
> knowledge in a permanent way. Combined with the hints & patches project

Do you believe that several years of free-form
posting to a wiki will be more available to a new user? The same people
who do not read and do not use the current search facility will be using
the new facility. The ones who ask about partitioning, ISO CD, ...  will
will behave the same.

> Some information can be considered fixed and should be guarded
> carefully, for example via an ownership model which I've proposed. Each
> projectleader would regularly check his pages for accuracy.

No! That requires repetitive, mind-numbing review. It is unlikely that
such a process could ensure accuracy of content, consistency of
presentation, ... in a confident way.

This replaces a process that ensures the contents have not changed, and
requires no verification (low effort) with one that does not ensure
verification and is high-effort.

> > A CMS, althought is indeed more flexible than our current CVS/manual
> > editting, still is a maintainance burden, because we need to keep track
> > of user management, give different roles to the users allowing them or
> > not to post a news item or modify static pages. But then "fine-grained
> > permission control" is actually a feature of a CMS.
> I think that by the time our Wiki will be abused as much as the
> mailinglists, we have decent user auth in our Wiki. PHPWiki-development
> is active lately, so we have decent prospects for a great succes of this
> project.

In that case, you should *begin* with "decent user auth". Why wait until
the disease happens and then cure it? It can be prevented at the

All this proposal of zero-level authorization, a "self-managing" user
community is seriously flawed. It ignores history. It seems that an
"engineering exercise" has been undertaken here. It seems that a tool
that allows the reduction of one burden is attractive to the one
relieved of the burden and that serious analysis of the effects has not
been done.

To list all the benefits is *not* the same as serious analysis. If you
seriously consider a completely open website and related, I think you
should take a more structured approach. Establish the goals, propose the
(various) strategies, play the what-if games (taking into account the
demonstrated history), draw tentative conclusions, and present a
well-reasoned and well-structured proposal to *-dev for discussion.

To do otherwise is to do nothing more than offer a political solution to
a non-political problem.

Bill Maltby,
LFS Organizational
Use fixed above line to mail me direct

More information about the website mailing list