[dokuwiki] AW: Minor edits pros+cons summary
- From: Andreas.Trawoeger@xxxxxxxxxxxxxxx
- To: "dokuwiki" <dokuwiki@xxxxxxxxxxxxx>
- Date: Sun, 18 Sep 2005 13:29:14 +0200
Problem with Minor Edits done manualy is that 2 users normaly don't agree what
a minor edit is supposed to be. If you do them automatically a program can't
detect small, but important changes.
So my question is: why not simply add an 'Publish via RSS' button to a page
that either defaults to yes or no + the option to write a summary.
This way a user can decided if a change gets published or not. The main problem
with 'minor edit' is that user don't know whats the result of activating it or
not. So they tend to ignore it
or leave it untouched, because it isn't the default behaivor. Just naming it to
something like 'add to RSS Feed' would make that much more clearer.
Another thing you could probably think of is how to publish different levels of
RSS Feed eg. an ever change feed, an only major changes feed and an only new
pages feed?
The one feed fits them all aproach is always problematic and will never really
work. So if you start to classify changes it would make sense to publish
different levels of RSS feeds too.
Probably you could even combine both approaches and implement the possibility
to define different RSS feed (eg. network, server, storage) and let the user
decide to which one the change should get published.
This way on group of edititors would only get the changes via RSS they are
really interested in, but has the possibility to feed the change to another
channel if the feed concerns some other group too.
So my summery is: Would't make it more sense to think about how to support
different levels & groups of RSS feeds. Than to think how to squeze all the
needs into a single RSS feed?
If every user is happy with RSS feeds everbody will use and is motivated to
keep them usable. If only a handfull of users use them, they others won't care
and will start doing stupid things like akitivating 'minor edit' every time,
just because they see no reason to write a summary.
cu andreas
Mit freundlichen BlackBerry Grüssen
Andreas Trawöger
Stabstelle Technologie und Security
Wiener Gebietskrankenkasse
A-1103 Wien, Postfach 6000
Tel.: +43(1)60122/3664
Mobil:+43(676)8770 3664
Fax: +43(1)60122/2182
EMail: andreas.trawoeger@xxxxxxx
----- Original Message -----
From: dokuwiki-bounce
Sent: 17.09.2005 20:49
To: dokuwiki@xxxxxxxxxxxxx
Subject: [dokuwiki] Minor edits pros+cons summary
Hello caretakers of DokuWiki,
Here's a summary of all of the options we've so far considered and the pros and
cons we've named for them. I don't know if it's going to help us, but it will
certainly help people who care but who are too wise to wade through our sea of
posts. I reread all of the emails to make sure I got everything.
As we think about this, we have to decide what variations will be allowed:
- We might have only one behavior and no summaries-required toggle.
- W might have a toggle between two behaviors.
- We might restrict the user to a few pre-ordained behaviors.
- We might make the behavior pluggable so anyone can do what they want.
~joe
====== Entering a minor edit ====================
This section explores the means by which a user flags an edit as minor.
==== CHECKBOX ====
An edit is considered minor only if the user checks a checkbox.
(pro1) The user has full control over whether an edit is minor.
(pro2) The user knows whether the edit will be considered minor.
(pro3) The user can't accidentally flag a major edit as minor.
(con1) Requires an extra step to do what should be the simplest edit.
(con2) Leaves users wondering about the difference between an empty summary and
a minor edit.
If DokuWiki is configured so that summaries are required, and the user neither
checks the box nor enters a summary, we can popup a Javascript box either
telling the user to try again or asking the user to select between "save as
minor edit" and "cancel save so I can enter a summary." This eliminates con2.
==== EMPTY-SUMMARY ====
Leaving the summary empty flags the edit as minor.
(pro1) Users doing simple tweaks are already disinclined to enter a summary.
(pro2) No extra steps needed to flag a minor edit.
(con1) Users often fail to enter summaries for major edits.
(con2) Users should not have to enter summaries for major edits.
If DokuWiki is configured so that summaries are required, and the user leaves
the summary empty, we can popup a Javascript box asking the user to select
between "save as minor edit" and "cancel save so I can enter a summary." This
eliminates con1.
==== AUTO-DETECTION ====
Small changes are automatically flagged as minor edits, where the size of the
change might be measured in lines (say 1 or 2) or characters (or some such).
(pro1) No extra steps or thinking needed to flag a minor edit.
(pro2) Only edits truly minor in size are flagged as minor.
(con1) Important changes may get flagged as minor edits (e.g. event
date/time/fee changes).
(con2) Unimportant changes may be presented as major edits (e.g. multiple
spelling/grammar changes).
(con3) As a consequencce of con1 and con2, users can't control the quality of
the feed.
If we have the additional requirement that all edits with summaries are
considered major edits, we can eliminate con1.
==== MINOR-IF-LOGGED-IN ====
These embellishment can be applied to any of the above approaches. Only logged
in users would be able to post minor edits. There are two ways to accomplish
this:
(1) All anonymous users are required to always enter summaries.
(2) All anonymous edits are considered major.
This is distinct from whether logged-in or anonymous minor edits appear in the
feed, page subscription, revisions, etc.
====== Requiring summaries =======================
This section explores how we deal with empty summaries.
==== MANDATORY-REQUIREMENT ====
All users are always required to either provide a summary or flag the edit as
minor -- to provide a summary for all major edits -- and you can't configure
DokuWiki otherwise.
(pro1) All major edits are well documented (assuming that users don't just
enter 'x' or such).
(pro2) The user doesn't accidentally flag a major edit as minor.
(pro3) The revision histories on all DokuWiki wiki's are pretty comprehensive.
(pro4) On sites where feed is intended only for site consumers and not site
editors, every entry in the feed explicitly reports what about the cite changed.
(con1) All edits require the user to take extra time, resulting in fewer user
edits.
==== OPTIONAL-REQUIREMENT ====
DokuWiki can be configured to require that all major edits have summaries, but
DokuWiki can also be configured so that summaries are optional in major edits.
(pro1) The installer of DokuWiki can decide which is more important, quality of
feeds and revision history, or quantity of information in the wiki.
(con1) Many DokuWiki wiki's will contain many poorly documented edits.
==== DEFAULT-TO-HEADING ====
Esther pointed out that MediaWiki defaults the summary to the name of the
section being edited, but the feature isn't compatible with the EMPTY-SUMMARY
approach to flagging minor edits. We might think about de-activating this
feature if we also allow for summaries to be required.
(pro1) Reduces the number of entirely uninformative empty summaries.
(pro2) May provide the perfect summary for some edits.
(con1) Requires that users delete something before entering a summary.
(con2) We may get less informative summaries overall if more people settle for
the default.
====== Communicating minor edits =================
This section explores our options for communicating minor edits to users.
==== NEVER-IN-FEED ====
All minor edits are excluded from the syndication feeds.
(pro1) Feed subscribers can assume that most or all of the deltas reported in
the feed are significant (depending on the summary requirements).
(con1) Many of the minor edits may be by anonymous users posting spam, which
would not be reported via the feed. (Note that the feed already only reports
the most recent change for each page.)
==== ANONYMOUS-IN-FEED ====
Only the minor edits of logged in users are excluded from the syndication feeds
(i.e., anonymous users cannot flag an edit as minor).
(pro1) Feed subscribers can better monitor the actions of less-trusted
anonymous users. (Note that the feed already only reports the most recent
change for each page.)
(con1) True minor edits made by anonymous users will appear in the feed.
==== NEVER-IN-PAGE-SUBSCRIPTION ====
No minor edits are reported to people subscribing to the edited page.
(pro1) Page editors cannot monitor the actions of less-trusted anonymous users,
making it difficult to take ownership over the quality of the pge.
(con1) Page consumers learn are notified only when important information
changes.
==== ANONYMOUS-IN-PAGE-SUBSCRIPTION ====
The minor edits of anonymous users are reported to people subscribing to the
edited page, but not those of logged-in users.
(pro1) Page editors can monitor the actions of less-trusted anonymous users,
possibly taking ownership over the quality of the pge.
(con1) Page consumers merely subscribing to learn of changes they care about
might be overwhelmed with many notices of minor edits.
==== GRAYED-IN-REV-HISTORY ====
Each minor edit appears grayed-out in the revision history.
(pro1) It becomes easy to scan the summary language for just the major edits.
(con1) Might be unappealing to have a mangle of colors.
==== ICON-IN-REV-HISTORY ====
Each minor edit in the revision history is preceded with an icon that flags it
as such.
(pro1) Clearly assigns meaning to the minor edit line, especially if the icon
has a tooltip or links to an explanation page.
(con1) Possibly clutters the revision history page.
==== NEVER-IN-CHANGE-LOG, ANONYMOUS-IN-CHANGE-LOG, ALWAYS-IN-CHANGE-LOG ====
I think these options are self-explanatory, and right now I believe everyone is
in agreement with ALWAYS-IN-CHANGE-LOG, where we always log minor events to the
change log.
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
