Migrate website documentation to the Wiki

Molle Bestefich molle.bestefich at gmail.com
Mon Oct 3 16:03:24 CDT 2005

James Hawkins wrote:
> Molle Bestefich wrote:
> > Isn't there a compromise where Wiki's upfront editing capabilities can
> > be used to ensure up-to-date, dynamic content while you also make sure
> > that nobody wrecks the pages?
> >
> > I'm no wiki expert, but it seems like an obvious solution to have the
> > pages editable only by a certain class of users.  People wanting to
> > edit something could then just ask for edit access for certain pages
> > for correcting this or that on wine-devel and be granted those
> > privileges on a case-by-case basis.
> This method is already available in the form of checking out lostwages
> cvs, making changes, doing a diff, and sending in the patch to be
> accepted.  The only difference is that anyone can make changes to
> lostwages this way (assuming they get committed).

Technically speaking, perhaps.

But a wiki lends itself to editing so much better than the tardy
process of finding the right CVS server, logging in, checking out a
working copy, finding the piece of documentation that is relevant,
making a change, checking if it compiles, sending a patch to
wine-patches (that never shows up) and to wine-devel (and never
receiving a response).

Compare that to just sending a mail to wine-devel saying eg. "hey
guys, there's two <A> links with 'binary' in their name on the
download page, one of them should be 'third-party', can I get editing
rights to it?

In the concrete case of the download page the answer would probably be
"No, but we'll go fix it for you", but you get the drift.  Ahem.

For any other page the response will probably be "Sounds good, you've
got access to edit the <blah blah> section now.  Remember to click
<preview> and see if it looks good before you commit."

More information about the wine-devel mailing list