What about extending the wiki...?
Bill Maltby, LFS Organizational
bill at nospam.dot
Sat Mar 13 05:18:11 PST 2004
On Sat, 13 Mar 2004, Jeroen Coumans wrote:
> Bill Maltby, LFS Organizational said the following on 03/13/04 12:47:
> > At a time when security concerns are becoming constantly more important,
> > I have difficulty buying into that concept at all.
> I understand all concerns but you have a very pessimistic view on our
"Experience is the best teacher". "Those who ignore history are doomed
to repeat it".
> If our community is to survive, we have to start with a basis
> of *trust*. And if you don't trust your fellow LFS-editors you have
> bigger worries then the installation of a Wiki.
Yes, I do. And I do not wish to compound them by opening all content to
modification by all comers.
> As long as people such as yourself care about the proper contents of the
> Wiki it will be a major hit. It's exactly the proof that self-regulation
> can work.
That is not "self-regulation". "Self-regulation" means that folks do not
have to monitor the efforts of others, for the most part, because the
contributors make mostly correct judgments and always strive to "do the
right thing". The wiki could be a major hit, but not in the manner
The proposal to allow *authorized* update only of certain parts will
enhance its utility while reducing certain effort, allowing maintenance
of quality and providing a better product and "experience".
The suggestion to open it to modification by all is ... <your favorite
derogatory term goes here>.
> Anyway, all of this doesn't mean anything as long as we don't move
> forward with it. We already have a Wiki, and it's usage has been
> minimal, even though it has been pointed out multiple times. If this is
> an indicator we have nothing to worry about.
I don't understand. I gathered that you were suggesting that the wiki
become the primary website page. Did I misunderstand? If so, I apologize
for the waste of time.
Anyway, if I understood correctly, the problem with the current wiki is
that the team members and organization as a whole did not actively and
effectively promote and support it. Some due to preference by certain
editors, and other community members, to use only list for
communication. Lack of communication list<->wiki aggravated this. And,
organizationally, it was never properly handled to make it the valuable
facility it could have been.
> I propose, as Website maintainer, to do introduce the Wiki in a number
> of phases which allow us to reflect & evaluate the success/failure at
> any time.
Would it not be more efficient to do the "engineering exercise" first?
That may suggest some good possibilities, discard others with less
effort and disruption to all concerned.
> Phase 1: Move Drupal to drupal.linuxfromscratch.org. Setup PHPWiki at
> test.linuxfromscratch.org. Copy the content of the current site. Adjust
> the templates & stylesheets to resemble the current site. Allow only
> registered users access but allow self-registration. Estimated time: 1-2
> Phase 2: Advertise the Wiki on the main website and on the mailinglists.
> At this point we direct everyone at the Wiki for the latest information,
> although the main website will be sustained. Let it run for 3 months.
> Phase 3: Evaluate the progress & success/failure thus far. If the Wiki
> is abused too much at this phase, we should move back to Drupal. If not,
> move the Wiki to the main website and move the main website to
> old.linuxfromscratch.org. Let it run in the wild for another period of 3
As I mentioned, I believe the results on test will not predict the
results on a live system. This will be because lots of folks won't go to
the test site (e.g. folks looking for quick <some function here>, others
who refuse to visit the current wiki on philosophical grounds - more
effort, two places to look for things, ...).
In support of this, look at the low-response rate (in relation to
community size) when you proposed the new site design. It was mostly
positive and an excellent way to garner a small amount of feedback that
helped refine it before finalization.
If the rate of access to the wiki test is similar, it could not be
considered a statistically reliable indicator of the results of a live
> Phase 4: Evaluate. What are the opinions of admins and users? Should we
> move to more user authentication to lower maintenance burden? Should we
> completely dismiss the Wiki and move back to Drupal?
I agree with lowering the maintenance burden. But I suggest that it must
be done in such a way that lowering it for website does not increase it
for the maintainers of the sections _any_more_than_necessary_. This
means that I, if an editor, must not have to constantly check to see if
unacceptable changes have occurred. If I am *responsible*, I want
control of who and when and what. I do not want to waste my time seeing
what has happened recently.
> So you see, it will take at least 4-5 months before I consider replacing
> the website with the Wiki. This should be more then enough time to see
> if it can replace the main website.
I believe it *can*, and support its use, relying on your judgment for
that (as well as I can envision its benefits). I object *only* to
unfettered update by any and all, regardless of their affiliation,
commitment and judgment.
> I hope that everyone who has concerns about using the Wiki as our main
> website will give me the benefit of the doubt, and trust my judgment on
> my long experience with the LFS community and on the basis of my
> contributions to the project thus far. Thanks.
Should I ask you to trust my judgment for the same reasons? As you know
from my public and private posts, I believe you have made substantial
and *wonderful* contributions. But that does not support or go against
the proposal, as initially understood by me, except that we might give
more weight to an outcome you foresee. And that would indicate that you
might give more weight to an outcome that I foresee.
You ask too much *if* you say that update capability is provided to
everyone. In this I do not trust anyone's judgment, including my own. I
trust history, the analytical skills we each have, in varying degree,
and discussion, to provide indicators to possible results.
If you have not previously used wiki, allowing unfettered update, in a
project like this before, your judgment is no better or worse than any
other regarding the ultimate results of allowing unfettered update.
Your judgment that I am too pessimistic is no better(IMO) than my
judgment that you are too optimistic.
Lest my POV be misunderstood:
1) I support your proposal to investigate use of wiki at as the home
page and any and all places you see it as a good "fit"; I will, as
always, do what I can to help you investigate and develop the
2) I object to allowing unfettered update to all areas, regardless of
commitment to the community, by any and all who wish to change any
3) I support your effort to shift the burden of mundane content update
to the originators of that content, freeing you to do more creative
things and making the overall process more efficient;
4) As you believe, I also believe the current wiki is under-utilized;
that is a failing of organization, IMO;
5) I would have liked to seen the results of your and Anderson's
efforts on Drupal. From what I gleened from following your public
posts, it seemed to have a lot of capability and seemed to transefer
the burden; regardless, if restricted update capability is what will
result in the end, administration would be required.
Use fixed above line to mail me direct
More information about the website