Wiki suggestions

[Paul Frields]

On Sat, Feb 7, 2009 at 6:24 AM, Leam Hall <leam at reuel.net> wrote:
> Christopher Beland wrote:
>
>> Anyone who agrees to the contributor license can sign up for an account
>> automatically and start editing the wiki.  I did that, and I didn't see
>> any admonitions to discuss all changes before making them.  If new
>> people aren't supposed to jump right into editing, maybe they should
>> only have permission to edit the Discussion pages.
>
> I'm happily reading O'Reilly's "Information Architecture for the world wide
> web", and happy someone else sees a few of the same issues that bug me. The
> wiki is great for draft content but unless it is kept to some structure it
> devolves to something even old time users have to use the search feature on.
>
> For example, i've posted a page and noted that it is very much in draft. Fee
> free to edit it as you see fit! When it looks good we'll work towards
> integrating it into a more fixed location and document.
>
> My opinion, for what it's worth, is moving towards a CMS. The wiki is great
> for collaborative thinking but there does need to be a more guided  hand on
> the presentation to the users. We are currently having to deal with one
> wiki-mess and I'd prefer to learn our lesson now that just repeat the
> problem behavior.

A CMS is good for a document like a general QA guide for users -- i.e.
something that helps people get started with the team, understand the
terminology, how to set up a testing environment, and so on.  Those
details largely won't change between releases so it's easy enough to
keep the document in sync with reality, especially if you give broad
editing rights to the QA group so that people can help.

However, the Docs Project has learned through *long* experience that
the wiki encourages more, and more frequent, contribution from
volunteers.  Other open source projects have also proven this model,
including Mozilla. There is always a place for controlled development
of canonical documents like a "Getting Started with the <Foo> Team,"
but I would warn you most gravely against thinking that a CMS will
solve all content problems.  Anywhere barriers are erected against
immediate participation becomes a serious threat to growing a sizable
community.

Having said that, the Docs Project is looking at a CMS for purposes of
canonical documentation, and a "Getting Started with Fedora QA" guide
fits very neatly into that model.

> Think of it as a process flow. On IRC and the e-mail list pretty much anyone
> can suggest anything. Some brave soul takes those notes and suggestions and
> writes the draft wiki page. Others comment, critique, and correct. Near the
> end of term Marketing, Docs, and Graphics teams are engaged to help the soon
> to be birthed page fit into the existing schema and docs process. Finally
> the page is moved to a CMS where some few QA folks have edit rights if
> errors or issues are found.
>
> From the outside, a potential volunteer looks at Fedora QA and sees a
> coherent, easy to learn from, and easy to use web presence that let's them
> quickly come up to speed on putting their skills and interests to work.

As long as this model is limited to canonical docs with a very low
rate of change, this should work OK.

> In the past week I have connected with 2 different coders who were looking
> to donate some time and expertise. Awesome! Do we really have a web site
> that makes their transition as fast and painless as possible so they can
> come on in and get to work?
>
> So here's a confession; I make the same mistakes on the pages I create. A
> few people have come back with questions or pointing out unclear wording.
> Thanks! If one person doing a single short page needs help; how much more do
> we as a team need the same for the entire QA web presence?
>
> I strongly urge us to keep the openness of the wiki for collaboration but
> move to some organized stability on the external web presence.

The wiki is just as much an external web presence as a CMS.  It's
intended to provide resources for anyone who wants to participate in
our community efforts.  The external web presence we have is primarily
aimed at people who are *consumers* of Fedora and don't intend to
participate.  The CMS vs. wiki debate has been had so many times in
other teams over the years in Fedora that we probably ought to have a
FAQ on the wiki about it! :-)  If the process pages for the team
itself need changing, I'd say, do it on the wiki first.  The CMS
doesn't make that work any easier.

My concern is that the CMS doesn't necessarily fix problems with not
keeping up content properly. In fact, it will make that job *harder*
because now anyone who wants to help with the maintenance needs
special approval to do so.  I merely want to caution folks against
deciding that because the bumper's dented and a headlight's out, it
makes sense to just sell the car. :-)

Paul