Re: Fwd: Editing in the Wiki

Comments inline.

<snip>

> >
> > A reaonable editing system would have *at least* the following changes
> > from the Wiki editing system:
> >
> > - A user-entered description of the changes would be *required* for
> > each
> >  change.
> > - The "minor edit" flag would have to be entered for each change.
> > - Change descriptions could be changed after the fact.
> > - Speculative changes (i.e., a different branch) would be possible,
> > and
> >  could be merged into the main branch.

That's the stuff that people at MIT make their theses about ;-) [1] Not sure 
whether any stable system with this capability exists, but asking the author 
would be an option.


> > - Diffs could be generated based on a set of changes.
> > - Diffs would be insensitive to non-visible changes in whitespace.
> >  (Unfortunately the Wiki language makes determination of non-
> > visibility
> >  hard.)

Yes, that's exactly the problem.

> >
> >
> > If the first two changes above were made to the Wiki editing system
> > then
> > the WG could proceed in the following limping manner:
> >
> > - Each change would be for a particular purpose.
> > - Changes related to an issue would have the issue number in their
> >  description.
> > - Changes made solely for editorial reasons would so state, and
> > would be
> >  flagged as minor.
> > - Other changes would have a description of the purpose of the change.
> > - Issue resolutions would just point to which documents were changed.
> > - Publication would be approved for a document and not a particular
> >  version of a document.  Non-minor changes to a document during the
> >  publication process would have to be approved by the WG chairs.
> >
> > This proposed process is definitely not ideal, but appears to me to be
> > acceptable and needs only minor changes to the Wiki editing system.
> >
> > (It turns out that it is possible for the WG to partly "implement" the
> > first change, by requiring that all WG members change their
> > Preferences
> > -> Editing -> Prompt me when entering a blank edit summary to on.
> > Unfortunately, the way this preference works is particularly annoying,
> > and much too easy to bypass.)

To make this a default for new users, add 

 $wgDefaultUserOptions['forceeditsummary'] = true;

to LocalSettings.php. 

But to really force it upon everybody without allowing people to turn it off, 
two patches to MediaWiki are needed. First, change the file inlcudes/User.php 
by modifying the function getOption(). E.g. one could just replace 

  1560:   return trim( $this->mOptions[$oname] );

by

  1560:   return ($oname == 'forceeditsummary')?true:trim( 
$this->mOptions[$oname] );

Second, to make it impossible for people to override this by saving again, 
change includes/EditPage.php 

  573: $this->allowBlankSummary = $request->getBool( 'wpIgnoreBlankSummary' );

to 

  573: $this->allowBlankSummary = false;


In this case, you should also edit the page MediaWiki:missingsummary to show 
an adjusted warning message.

-- Markus


[1] http://wikimania2007.wikimedia.org/wiki/Proceedings:BMH1

-- 
Markus Krötzsch
Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
mak@aifb.uni-karlsruhe.de        www  http://korrekt.org