What about extending the wiki...?

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


On Sat, 13 Mar 2004, Jeroen Coumans wrote:

> Bill, you make so many points that I can't get myself to discuss
> everyone of them! :-)

Always been a strength (or weakness) of mine. I matured in a programming
environment when things were slow and expensive. So we were taught a
quite rigorous methodology, all oriented towards reducing expense.

> I see that you have not familiarized yourself
> enough with Wiki to take away all concerns (or perhaps just the opposite
> ;-).

Absolutely correct! I've learned enough to do what I need to do and
devoted my remaining time to other things. This means that I waste your
time with some questions, but I have to make trade-offs too. :( For that
I can only apologize, but I can't see a way to learn everything I desire
(there's just so *much*).

> Some guarantees though:
>
> * pages can *never* be completely removed by non-admin users
> * everyone can revert to a previous version of a wikipage thanks to
> virtually unlimited revision control
> * we can mix non-editable content (such as navigation structure) with
> editable content.
> * we can lock pages completely.

Well, my concerns about those things are put to rest. I'm glad I asked!
:)

>
> For the record:
> Will you endorse at least phase 1 and 2 of my initial proposal? Thus, to
> setup a Wiki which has decent user auth (thus not PHPWiki, yet) and
> promote it as the main website (though not actually replacing it until
> phase 3)?

I certainly support phases 1 and 2. To forestall early complaints about
the team/user issues regarding list<->wiki, and possibly unwarranted
resistance to "first impressions", I would advertise it as an R & D
effort to see if could be suitable as a website replacement. This opens
the door for you to request that even those opposed to it out-of-hand
visit it and offer constructive criticism and, maybe more importantly,
suggestions for solving those issues that are raised.

It also allows for early mention of already identified issues that must
be resolved to the satisfaction of the community overall before the next
step is taken. This lets those opposed-in-advance see that you have
considered some of their objections already and may allow them to be
more open-minded.

My hope is that we can generate an initial attitude in all the users of
"let's see if we can make this thing work regardless of our
preconceived resistance" instead of "they're shoving it down my throat"
(even though we know this is not true, some will view it that way).

Regardless of what is done, someone will certainly say "I don't want to
learn a new tool (now?)". I don't know how to address this except to
emphasize how easy it is for casual users to do *basic* operations and
note that frequent users will be able to quickly(?) acquire the needed
skills.

OT: I would like to see org docs and mission statements published before
this effort sucks all your available time. My reasons should be obvious,
so I'll forego mentioning them. I know it would be easier to just put
them in the new wiki, but...

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



More information about the website mailing list