What about extending the wiki...?

Bill Maltby, LFS Organizational bill at nospam.dot
Sat Mar 13 09:06:58 PST 2004


On Sat, 13 Mar 2004, Jeroen Coumans wrote:

> Bill Maltby, LFS Organizational said the following on 03/13/04 14:18:
> >
> > 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
> >     concept.
> >  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
> >     area;
> >  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.
>
> Except for point 2, which is a bit black/white, I agree with all of the
> above.

Yes, it is black/white. For instance, included in "unfettered update to
all areas", would be (all below either inadvertent or intentional):
 1) the overall structure, which allows removal of whole sections;
 2) "fixed content" intended by the project to be always available and
    should be modified only by project team members (e.g org docs and
    related);
 3) nav links which could be modified to suit an individual's personal
    preferences, regardless of the wisdom, experience, investigation,
    analysis, familiarity with standards, and decisions of the designer
    that considered the "universe" and product overall.

There may be more cases. The point is that there are certain things that
"define" what the project is, how it is presented, how it addresses our
community as a whole, ... that should not be subject to modification by
even the most well-intentioned participants without consultation with
the *responsible* project members. IMO, the website is a vital part and
an important product of the project. As such there are certain
*attributes* of that that should be well protected.

>
> Let me add that I *have* experience with Wiki's, although not as long as
> I would like.

Unfettered access to *all* parts by *anyone*? That was my stated
concern.

> I am impressed with the level of control it offers to
> users, and I am similarly impressed with the *minimal* abuse that this
> control has put forth in other communities much more hostile then this
> one (eg. heavily opiniated university students)
>
> Based on the above statements, it seems that you agree with my plan so
> far, with the exception that you don't want everyone to edit content.
> The four phases which I've outlined provide IMHO enough time & planning
> to build in any user authentication which *might* be required.

As long as the three items (and any others we identify) are adequately
protected, yes. But any changes that would affect the core project
related *values* (overall "look and feel", specific items that provide
*identity* of the project like org, commitments, goals, ...), core
content, etc. would be areas that require greater update control.

>
> It is not my intention to put any more burden on the project leaders
> through verification, and I think you have a valid point if we would
> require everyone to regularly verify the correctness of their pages. But
> I *do* want to test at least a fair amount of time what the benefits
> would be if we let our users improve the content of our website.

I've no objection if the items I address above (and any others I've
overlooked) are adequately secure from unauthorized change.

> By
> requiring them to sign in before they can edit, we have at least a (low)
> barrier (even more because I don't want editing controls to show up
> *unless* someone is signed in, thus casual visitors aren't even aware
> that the site is actually a Wiki). And because we always have backups &
> revision control, *anyone* can fix a page if someone vandalizes/abuses it.

That is good, but is it sufficient? The site is 24/7. How many users
might be adversely affected while awaiting discovery of corruption and
completion of restore? We can't predict that, of course. But as with
other products of the project, a goal of 100% <all good things> (which
can *never* be achieved) should define how we view these trade-offs.
We make decisions that reduce that from 100% only after *careful*
consideration of gains vs. losses. Keep in mind that the more folks that
have update ability, the more likely corruption, intentional or
otherwise.

Since we publish for *users*, we must consider the possible negatives
and their effects on those users.

>
> I'm not sure if you've read <http://c2.com/cgi/wiki?WhyWikiWorks>, but
> it's these principles that I think would work well in our community.

I've read it and generally support its concepts.

> Also, the Wiki system is not a system that is fundamentally flawed; it
> has worked for many years, producing great content such as
> <http://en.wikipedia.org/wiki/Main_Page>. Even
> http://www.freedesktop.org/ uses it as their main website, which is more
> high-profile and has a lot more zealots then LFS.

I've no doubt. I have only a question: do those sites permit absolutely
unrestricted update by *everyone* of *all* parts, including those that
define the structure and/or core values that define the project?

>
> I'm not interested in *content* management, I'm interested in giving our
> community the opportunity to *create* and *edit* content, with the ideal

With minimal restrictions, I support this. As mentioned above, the
*project* does have concern certain content management though.

> goal that we will all learn more from eachother and will fix eachothers
> mistakes. I think the great majority of people who are attracted by LFS
> are intelligent and enthousiastic Linux-geeks, coming to learn and
> eventually contribute. They do not come with bad intentions or to
> destroy the community. That may be naive or optimistic, but if this
> isn't the view of most people in the LFS community, we wouldn't care so
> much about it.

I am not concerned only about black-hats. My concern is with those whose
intentions are good in their POV, but their implementation of those
intentions fly in the face of generally accepted protocol, standards,
mistakes, and such. As long as the effects of those sorts of things are
reduced in certain areas by having only team members authorized, I feel
supportive.

>
> Just one more clarification: somewhere I got the impression that you
> thought I proposed we put *all* LFS products under a Wiki-wrapper. Let
> me assure you that I do *not* intend such a model and would be strongly
> opposed. The only things I want to put under a Wiki at this point is the
> website and the FAQ.

IMO, the website is a *vital* and *core* product. It is the primary
"portal" to the books and related products, provides the first
impression of the project and has a major role in the overall "LFS
experience". With such a POV, you can see why certain aspects of
structure and certain content should be protected from casual update IMO.

I see the FAQ similarly , but it is less a "determinant" of overall
product definition. As such, I can see it being updated ad-hoc with less
concern. Plus ad-hoc update offers *major* potential benefits in
timeliness and comprehensiveness with reduced team workload. My only
concern there would be removal of "outdated" items: too soon and users
of older books (e.g. LFS 4.*) are left without a FAQ entry; too late and
users of newer books *may* be led astray (of course, this really depends
on the completeness of information of a particular FAQ item). I don't
know that there is a good resolution to this sort of thing other than to
have a team member who constantly checks for that stuff (no different
than now, AFAICT).

> Should this prove succesful (and there are lots of
> arguments and examples that it has a very real chance of becoming
> succesful) we can consider replacing/moving the hints and perhaps even
> the patches to the Wiki, which is IMHO only a natural step, but also not
> my decision to make.

I can only envision a few objections. Standard format, need for hint
authors to learn something they may not be interested in learning, who
is allowed to update hints which have peoples names on them, ...

>
> Also, to lessen your concerns, let me assure you that we can always, no
> matter how far in the process we are, lock pages or impose user
> restrictions on the Wiki. But I don't want to lock pages before we have
> at least tried it. Remember, I lose the most if the Wiki fails, because
> not only will my efforts so far be useless, I also have to invest a fair
> amount of time in Drupal or the static pages. But the way I see it,
> there is not much to lose because of the built-in revision control &
> backups.

See comments above. As to failure, it should not occur for the same
reasons as the current wiki's failure, I think. But this means that the
concerns of team members and users that could be affected need to be
obtained and addressed to avoid that point of failure. Several have
expressed concerns with searching multiple locs for info, learning
something new, ... I think that was one of the reasons the current wiki
received so little support.

I feel you increase the chance of success if you can address those
issues at startup, rather than having to come back later and "fix" them.
I also had made a brief attempt at getting the wiki better supported
organizationally, but had not been able to pursue it. If there are
certain parts of the proposed one that should have more active team
involvement, identifying and addressing those up-front would also help
ensure success.

Keep in mind that many of our users will endorse or denigrate the
component based on first impression. So even considering test-only mode,
the major concerns that they may have should be addressed, if possible,
at first exposure. this argues for a test that initially cimprises a
small set of supportive users who are willing to alos paly "opponent for
a day" to see what valid objections can be identified, whcih can be
resolved and which must be left unresolved. Then a wider exposure would
be likeley to garner more widespread support from the community in
general.

BTW, you'll notice that I used wiki, in all my ignorance, for both the
org docs and mission statements (at your request). I also like the
potential it offers. But I *did* visit those pages frequently to to
assure myself that all was as it should be. We may have some areas where
the responsible parties are not willing to do that. If those concerns
are adequately addressed, I feel resistance should be minimal.

As a last thought, one of the concerns is caused by a lack of linkage of
list contents and wiki. Some wanted only to receive automatic mailings.
If wiki updates automatically fired off a list posting, and a list
posting automatically caused a wiki update, this concern could be
alleviated. However, I see a lot of technical hurdles and important
design decisions if this is attempted.

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



More information about the website mailing list