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

[Seb Bacon]

On 17 May 2011 14:18, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> On 16 May 2011 00:35, David Raznick <kindly at gmail.com> wrote:
>> On Sun, May 15, 2011 at 3:23 PM, Rufus Pollock <rufus.pollock at okfn.org>
>> wrote:
> [...]
>>> 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.
>
> Great. Only concern UX issue mentioned above but that should not be a
> problem (we could in banner saying: you are viewing latest edit not
> the active version being currently shown or similar.
> [...]

I think there are some other UX issues to explore but they shouldn't
impact on the database models.  I will aim to start a thread about
them today or tomorrow...

>>> 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.
>
> To clarify: i think we are already agreed to go with option 2 and
> forget ChangeObject model for time being (i.e. go with your preferred
> option). May still be some discssion re interesting proposal to make
> 'Revision' central (and downplay or even remove continuity).

Been meaning to do a longer post but looking short on time, so just to
say yes, but I think that David's point about doing the queries using
date ranges on revisions is spot on the money (and portable between
databases).  It should allow for efficient querying of the state of
entire object graphs and be portable between databases.

Seb