[ckan-dev] moderated edits c(r)ep. http://trac.ckan.org/ticket/1129

[David Raznick]

On Sun, May 15, 2011 at 3:23 PM, Rufus Pollock <rufus.pollock at okfn.org>wrote:

> On 13 May 2011 16:50, Seb Bacon <seb.bacon at okfn.org> wrote:
> > Any chance of an entity diagram of some kind?  Even just a photo of a
> > sketch on a bit of paper. I'm having trouble quickly digesting all of
> > this.
>
> A nice complement to Seb's request is to summarize the high-level use
> cases and lower level requirements we have here.
>
> ## Use-case (from CEP)
>
> 1. A user comes and edits a package (or other domain object).
>
> 2. This edit generates a new revision of the object but this does not
> automatically become the 'active' revision displayed to visitors but
> instead is held until the moderator accepts it. Such revisions are
> known as Pending.
>  * The moderator is notified (?)
>
> 3. The moderator is shown a list of "revisions" (in diff-format?) and
> can choose to accept or reject.
>  * The most recent accepted revision is then the Active revision and
> it is this revision of the object which is now displayed to users.
>
> * Question: who is moderator and how are they specified (i.e. is there
> a web interface for setting moderators)?
>  * Answer (?): moderator will be the object owner/admin as defined by
> the authorization system.
>
I am happy with this for the time being.


>
> Question: is it possible for multiple 'pending' edits to a given object?
>

> Question: If yes this requires some thought: consider package X is at
> revision R1. A edits  X generating a pending revision R2. B then edits
> package X. When editing is B shown R2 or R1? If R2 the experience will
> be a bit odd (when editing the object will look different from what
> they just saw in read view). If R1 then each pending revision will be
> in isolation from each other and when a pending revision is finally
> accepted all previous pending revisions will simply be discarded (this
> could be quite frustrating: suppose I edit a package's notes to
> generate a pending revision. Just after saving I notice that I had a
> typo in notes -- I'll now need to completely reenter the notes change
> to make that one letter correction (this also begs the question: can I
> as revision creator see my pending revision or not once created?)
>

Essentially this is analogous to a branching policy.  The simplest model
would be to have two branches where

active == stable
pending == default

Anyone can add a changeset(revision) to default, however only the
moderator(maintainer) decides what goes into stable.

This would mean a community edit would always be based on others community
edits as its in the same branch.  The moderator could just accept tip of
default or go through the changsets and cherrypick the ones liked.  The
revision makers could also have the 'stable' branch to compare their edits
to and 'revert' if needed.  This would mean the community could do a lot to
help out the moderator.  I think we should start with this approach.

The other policy we could have is where every user gets their own branch.
These branches fork from the last active (stable) branch.  This means a user
can do as many changes as they like and the moderator only pulls the head of
the branch.  This is much more work for the moderator as the merging would
be messy and once one merge is accepted it is most likely there will be in
conflict with the others.


> ## Requirements
>
> This is by no means all. But this repeats one set that David mentioned
> earlier:
>
> We need to get a dict for an object (and associated objects):
>
> 1. The latest active revision.  (last approved edit)
> [ 2. The latest revision - RP: this would seem covered by either 1 or 3]
> 3. All the unapproved revisions (moderation queue).
> 4. A point in history/time or a particular revision.
>
> My comment: I wonder whether for 3 and 4 diffs would be sufficient
> rather than full objects -- that is, it is enough, for say a moderator
> be able to look at a 'dict-diff' between current active revision and
> any pending revision. Ditto for history.
>

I think if we go with proposition 2 it will be easier making the diffs only
after we collect the 'whole' object.

I mention this because this because diffs may be easier and even
> possible in circumstances where getting "dict" (at least in form
> suitable for Objectization) is not (e.g. imagine the model has changed
> and there are old dicts that haven't migrated -- could still do a
> dictionary diff but wouldn't be able to load).
>
> For proposition 1 diffs are a good the way to go.

 rufus
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110516/340b14d5/attachment-0001.html>