henrik at bechmannsoftware.com
Mon Nov 28 11:47:49 CST 2005
Re: The scenarios that you describe, I guess my basic answer (and I
don't mean to trivialize it -- see below) is that those are Bob and
Alice's problems, and they are problems that Bob and Alice can easily
deal with. But I have underlying assumptions to this:
- with PmWiki there is always (certainly where drafting capability is
selected) a small group working in any page group with a PmWiki
installation, and these people can talk to each other to set
expectations and administrative protocol.
- You could place a notice on top of the edit page: THIS IS A DRAFT or
- Once a user has submitted an edit or higher authorization you could
have (through <!--DraftInformation-->) a notice on the display page
(THERE IS A PENDING DRAFT) or even a "See Draft Version" Button.
- You could include the most recent author (with perhaps an email
address/contact method?) at the top of the edit page.
Are these fair assumptions?
Here's my real problem, let's call it Scenario C (to your first two A
Alice is working on a complicated draft that she's been working on for a
couple of hours, but it is still incomplete, and to publish it would be
inappropriate. She gets called to an important meeting, and wants to
return in a couple of hours to complete her work. If she saves the draft
text to an external text file, and Bob comes along in the meantime and
makes some changes (not knowing that Alice has an important version
change pending) then Alice has to start all over again.
This is quite real for me, I've already encountered it in my most recent
installation, only days old. The material on my website is complex, and
posted by relatively non-technical volunteers. At the moment I have to
tell them that they have to finish each unit of work at one sitting, no
matter how complex. This can become a BIG disincentive to posting
(particularly when they are just learning), which in my submission, in
this scenario, defeats or at least dilutes the purpose (and perhaps the
philosophy) of PmWiki.
And I submit that Scenario C is far more difficult to deal with than
Scenarios A or B. If Bob sees that Alice has something in the works (by
seeing that a DRAFT comes up when he goes into edit), he can wait a
couple of hours to find out what's going on; much less risky in terms of
Did I say "please"? <grin>
Here's a couple of scenarios that concern me:
1. Both Alice and Bob are authors. Alice makes some substantial edits
to a page but doesn't release them (i.e., we have a released version
and a pending version). Bob then comes to the web site, and notices
a small typographical error in the released version. He presses "edit"
(getting the pending version with Alice's changes), fixes the typo,
and releases the updated page, but never noticed Alice's edits.
Both Bob and Alice are then surprised when Alice's draft edits have
suddenly become released edits.
2. Both Alice and Bob are authors. Alice makes some substantial edits
to the entire page, so that it looks almost nothing like the original,
but doesn't release them. Bob comes to the same page and decides to
update it, but when he presses "edit" he gets something that looks
nothing like what he was trying to edit. As a result he's confused
and convinced that there must be something wrong with the system because
he keeps getting a version of the page other than the one he's
able to see on the web site.
Patrick R. Michaud wrote:
>On Mon, Nov 28, 2005 at 12:21:22AM -0500, Henrik Bechmann wrote:
>> I think the simplext would be if everyone would see the released version,
>> and authors would have to go to the edit page to see the pending version
>> in the preview portion of the form.
>My comment that authors could get confused by hitting edit on the
>released version and then see a somewhat different pending version
>Here's a couple of scenarios that concern me:
>1. Both Alice and Bob are authors. Alice makes some substantial edits
> to a page but doesn't release them (i.e., we have a released version
> and a pending version). Bob then comes to the web site, and notices
> a small typographical error in the released version. He presses "edit"
> (getting the pending version with Alice's changes), fixes the typo,
> and releases the updated page, but never noticed Alice's edits.
> Both Bob and Alice are then surprised when Alice's draft edits have
> suddenly become released edits.
>2. Both Alice and Bob are authors. Alice makes some substantial edits
> to the entire page, so that it looks almost nothing like the original,
> but doesn't release them. Bob comes to the same page and decides to
> update it, but when he presses "edit" he gets something that looks
> nothing like what he was trying to edit. As a result he's confused
> and convinced that there must be something wrong with the system because
> he keeps getting a version of the page other than the one he's
> able to see on the web site.
>>>One option is to configure the system so that edits always take
>>>place on "-Draft" versions of pages, and then provide an easy way
>>>to replace the released version with the -Draft text.
>>But many people may not want this, so making it an option (off by default)
>>would certainly suffice.
>Oh, for any of these scenarios I'm definitely talking about something
>that is optional and off by default. I like PmWiki's current edit
>semantics just fine.
>>>Another option is to create a special "released.d/" directory for
>>>released versions of the pages, while edits always take place on
>>>the pages in the "wiki.d/" directory.
>>I don't know that a full blown versioning system is necessary. You might
>>consider a 'pending' subdirectory for in-process pages, if that makes it
>Oh, I wasn't going to a full-blown versioning system, but we do have
>to have some way of distinguishing releases versus drafts (pending).
>I was thinking of "wiki.d/" above as being the pending subdirectory
>(i.e., it's the one containing the latest edits) while "released.d/"
>contains the pages that have actually been released.
>But ultimately we have to have somewhere to mark the differences.
>I'm guessing we can do this in the page files themselves, in the
>the page names ("-Draft"), or by holding the released versus pending
>pages in separate subdirectories.
>> The suffix approach may cause problems with searches etc.
>We have trouble even with the non-suffix approaches. When doing
>a search, PmWiki searches the most recent version of the markup
>text -- we'd have to build in something special to get it to
>search only the released version of the text. Or we have to keep
>around two copies of the text, and either the edit modules or
>the search modules (or both) have to be aware of the two versions.
>This is why doing it by name "-Draft" might be nice -- the name
>makes it clear to an author that they're working on a draft
>(pending) version, and there's little confusion about who sees
>what. It's easy to exclude page names ending in "-Draft" from
> $SearchPatterns['default'] = '!-Draft$!';
>All that would need to be done to make this work is to have
>"?action=edit" be smart enough to read from a "-Draft" version of
>a page if available, to have "Save" always mean "Save as draft",
>and add a "release" option that saves the contents to the original
>location instead of the draft (and eliminates the "-Draft") page.
>This also makes it easy to see which pages have outstanding
>drafts (have a "list=draft" option to pagelist, or use "list=all"),
>and it separates draft edit histories from page edit histories.
>> ... all I'm suggesting is
>> that once you throw a switch, then all edit operations take place on a
>> single copy (say in a pending dir) until the pending copy over-writes the
>> previous version, and is then deleted. Of course the person making the
>> edit would have the option of releasing the edit immediately (ie. not
>> making a pending copy).
>The difficulty is knowing when to create the pending copies, and
>getting the different actions (?action=source, ?action=diff, ?action=attr,
>?action=search) to know when to use the pending copy versus the released copy.
>> I would say if there is a simple way for you to do this (not time
>> consuming, perhaps even a recipe to try it out) then that would probably
>> be the right way.
>If there was a simple and obvious way to do it, I probably would've
>done it by now. So it's not exactly a trivial fix, although the
>discussion above has helped me to clarify the issues in my head. :-)
>> Does this help?
>Yes, it helps a bunch.
More information about the pmwiki-users