Revisions in core

[Owen Winkler]

Hey guys,

I added core code to implement revisions in API in 0.10. The basic idea is that revisions are always on within core, and plugins modify or disable that functionality and provide the otherwise non-existent UI for it.

There's a discussion going on in the issue tracker about the feature right now. Your opinions (reply here?) are appreciated.

https://github.com/habari/habari/issues/454

Thanks!

Owen

[Chris Meller]

Woo hoo!

--
--
To post to this group, send email to habar...@googlegroups.com
To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-dev
---
You received this message because you are subscribed to the Google Groups "habari-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to habari-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael C. Harris]

+1

I've seen the discussion, and this seems like a fundamental feature that other things can build on, as with other core features. 

--

Michael C. Harris

http://twofishcreative.com/michael/blog

IRC: michaeltwofish #habari

[Michael Bishop]

Interestingly enough, I was just drafting a thread for this mailing list regarding a potentially bigger philosophic discussion.

At hand is should this feature be core, and a plugin be used to turn it off, or stay true to an early mantra of Habari that core should be lean and mean, with the API to extend it to do things beyond anyone's imagination, meaning the actual revision part be a **core plugin** that requires activation.

There are always compelling arguments for both sides.

Is it possible Habari's popularity and growth were stunted because of a staunch adherence to "lean and mean core"? Could hardcore devs be turned off or alienated because features are introduced into core? The answer is probably yes to both.

Based on what I'm seeing coming back from a hiatus, I see more users, and the desire to attract more users which in turn may attract more devs & designers. I do not see a bunch of hardcore devs issuing pull requests. (This is not meant as a slight to anyone who is contributing, simply pointing out that I'm seeing more activity from end users.)

So I give a hearty +1 to basic revisions being part of core, the ability to extend that to far more advanced features in a plugin, and trust that decisions to introduce features  are not made lightly as to not deviate away from the core tenets of Habari.

~miklb

[Morgante Pell]

I am strongly opposed to adding revisions to core, for the reasons outlined in the ticket.

Furthermore, I think it is a very dangerous direction for us to be going in. Apparently we've somehow decided to abandon our roots as a lean/mean system.

This seems to me entirely unwarranted. Sure, Habari isn't incredibly popular, but is that a major problem? I know that many of us enjoy using it and building things on top of it.

If we start pandering to the lowest common denominator, that's going to be gone. (I'll also likely be leaving again soon.)

This seems like far too important of a decision to be made based solely on a few trolls in -users.

On Feb 1, 2013, at 7:32 AM, Michael Bishop <mi...@miklb.com> wrote:

I do not see a bunch of hardcore devs issuing pull requests. (This is not meant as a slight to anyone who is contributing, simply pointing out that I'm seeing more activity from end users.)

Really? Where are all these new users? I count exactly one "user" complaining about Habari's usefulness.

The rest of us are still using it, and building functionally on top of it.

The fact that not many pull requests are issued is a testament to the fact that Habari's core is lean and mean enough that most things can be done with plugins.

[Owen Winkler]

I really like the idea of providing all of the underlying tools that integrators might need to build sites on top of Habari. Revisions seem to me like a missing component, as did taxonomy, which allowed us to build pluggable features on top, like menus. There is currently no underlying, unifying data structure that could be used for revision or workflow features, so I think this is a good and welcome addition. 

As to the greater point of addressing user concerns, I agree. I think it's important to have a useful, competitive tool that also provides a robust framework on which to build. I'd like to discuss other features related to this, specifically WYSIWYG and the recent auto-install ideas from IRC, but under different cover.

The only argument I've heard against revisions so far that seems valid is that it may increase default storage requirements for users with many revisions. This may be true. I could be persuaded to consider storing revisions being disabled by default, but the argument against seems more about the code being "lean and mean" than storage requirements. I don't think this feature causes feature/code bloat; rather, I think it's an expected essential capability for baseline blogging today.

Owen

[Matt Read]

Just looking at my database sizes. One DB, that contains 5 different
sites, is 454MB with 301 MB free space.

+--------------------+----------------------+------------------+
| Data Base Name | Data Base Size in MB | Free Space in MB |
+--------------------+----------------------+------------------+
| dropoid | 0.0288 | 0.0000 |
| habari | 434.3509 | 301.0794 |
| information_schema | 0.0078 | 0.0000 |
+--------------------+----------------------+------------------+

EEKK! after an optimize, I get that down to 131MB:

+--------------------+----------------------+------------------+
| Data Base Name | Data Base Size in MB | Free Space in MB |
+--------------------+----------------------+------------------+
| dropoid | 0.0288 | 0.0000 |
| habari | 131.0390 | 0.0000 |
| information_schema | 0.0078 | 0.0000 |
+--------------------+----------------------+------------------+

interestingly, this "extra" space seems to be mostly from comments, logs
and sessions. sessions, and somewhat logs, grow quickly. But little data
is used. Overtime it adds up though.

Investigating further, this 131MB is from old installs with massive log
size, one at 70MB the other at 42MB.

So, just my main up-to-date install:

SELECT table_schema "Data Base Name", SUM( data_length + index_length) /
1024 / 1024 "Data Base Size in MB" FROM information_schema.TABLES WHERE
table_name like 'habari__%' GROUP BY table_schema;
+----------------+----------------------+
| Data Base Name | Data Base Size in MB |
+----------------+----------------------+
| habari | 0.90812397 |
+----------------+----------------------+

barely 1 MB for a site with: "Matt Read, Weblog has been active for 9
years, 3 weeks and 5 days. The 2 authors have published 211 posts with
1119 comments and 74 tags"

My posts table is even smaller:
| habari__posts | 0.22566223 |

While someone else's on my server, let's call him Mick:
| habari__posts | 1.41213608 |


When I think about writing a post, especially a long one. I click save
many times. let's say I click save 10 times on each post. As it stands,
if my quick glance at the code is right, this would essentially make
revisions take up, roughly, 10 times my posts table's current size; 2MB.
And Mick's would be 14MB.

This is not unreasonable. Although garbage collection may be in order.

Now I'll talk crazy. Remember that update/date feed position thing and
minor edits? This could come into play here too? /me runs away from that
one.

[Owen Winkler]

On Fri, Feb 1, 2013 at 9:32 AM, Matt Read <ma...@mattread.com> wrote:

When I think about writing a post, especially a long one. I click save many times. let's say I click save 10 times on each post. As it stands, if my quick glance at the code is right, this would essentially make revisions take up, roughly, 10 times my posts table's current size; 2MB. And Mick's would be 14MB.

This is not unreasonable. Although garbage collection may be in order.

It should be possible to include in a plugin a thing that purges revisions since the last publish, or something like that.

 

Now I'll talk crazy. Remember that update/date feed position thing and minor edits? This could come into play here too? /me runs away from that one.

Yeah, it should totally be possible to change prior revision data on minor edits, rather than creating whole new revision records.

Owen

[Chris J. Davis]

I have been mostly out of this thread, since I don't think I have anything constructive to add, but I thought I would chime in on this.

While I agree that this change seems to fly in the face of the original vision that we founded Habari on, the most important tenant of Habari is that we are a project that is driven by our community. Things have been done in core, and added to core that I was not excited about, but the community spoke and we listened. If we stop doing that, then I don't really see a reason for the project to continue.

Owen has put the question to the community and from them we will see if having this in core is right for Habari or not. If there is overwhelming hatred of this move, then we know we have done something wrong, if there is support then we know it was right.

I would urge you to remember what Habari was really founded on, which is the concept that the community is king, and not leave because the project has grown up into something other than what is started as. All children do that, we shouldn't abandon them just because the look different today than when they were born.

Just my 2c.

[Chris Meller]

On Fri, Feb 1, 2013 at 8:32 AM, Matt Read <ma...@mattread.com> wrote:

When I think about writing a post, especially a long one. I click save many times. let's say I click save 10 times on each post. As it stands, if my quick glance at the code is right, this would essentially make revisions take up, roughly, 10 times my posts table's current size; 2MB. And Mick's would be 14MB.

This is in line with my math, too. I have about 650 posts in my table and it's a whopping 2.5mb. That's about 4k each, so I could save revisions over and over and over before it ever amounted to anything substantial.

[rick c]

On Thursday, January 31, 2013 10:12:14 PM UTC-5, ringmaster wrote:

I've been watching the comments on #454 and this thread with interest, mostly because my immediate thought was "Why do we need this? How will it help me?" Because at first blush, it won't. As others have said, it's yet another feature, yet more code, yet a bigger database.

After thinking about it, I have no strong feelings one way or another. I've been using Habari several years, and haven't really missed the feature. The same can be said of many things that are already in Habari, though, such as ACL. It is a lot of code that adds to the database that I, as the single user of my sites, have no use for, that I know of.

But I'm just one user, and not necessarily representative. For example, I like HiEngine. From what I can see, I'm the only one who likes, or uses, HiEngine. It could probably go away and no one but me would miss it.

There are many other uses cases for Habari than the single user site, though. Many people would, or would like to, use it commercially or on multiuser sites. ACL, for example, is a necessity in such cases. It does nothing for a single user site From what I can see, revision control is just as necessary for a multiuser site as ACL,

As far as database bloat goes, I can't see that as a major problem. Revisions, unless the post content is the part of the post being changed, will be relatively small. Logging adds much more to the size of the database than revisions will due to the sheer number of things we log, enough so that with SQLite I can't wait for the cronjob to truncate the log table and have to do so manually.

In terms of code bloat, from what I've seen this changes adds somewhere around 100 lines of code, counting blank lines and comments. This isn't a horrible amount of code bloat If you look at Ohloh, over the past four years code size (counting  only lines of actual code) has increased approximately 50% ( https://www.ohloh.net/p/habari ), from approximately 33K lines of code to 49K lines of code. That's 4K lines of code a year added that would include many features which not everyone is going to use, but which many people will see as a requirement to make the software minimally useful. Compare that to WordPress with 177K lines of code, Drupal with 865K lines of code, Typepad with 6600K lines of code, or Joomla with 1265K lines of code. Those comparisons tell me Habari is still lean and mean.

Rick

[Chris Meller]

On Sat, Feb 2, 2013 at 9:12 AM, rick c <rickc...@gmail.com> wrote:

Logging adds much more to the size of the database than revisions will due to the sheer number of things we log, enough so that with SQLite I can't wait for the cronjob to truncate the log table and have to do so manually.

Totally off topic: Out of curiosity, what all is getting logged (are there actual errors?) and any idea why SQLite can't handle it? What happens if you don't manually empty it? Not sure why your log would be growing so much between cron runs that it would negatively impact anything.

[Chris J. Davis]

Just as an aside, none of my sites/apps that are built on habari ever have their log tables truncated. I have to manually empty them periodically. Might just be my stuff though, since I am wont to do odd things.

[Chris Meller]

I've spun off the log-related discussion into ticket #457, if you two would care to join me.

[Philip Buckley]

As an end-user rather than a developer, I must admit I don’t really understand the significance of “in core” versus “in a core plugin”.

I find Owen’s comparison of Revisions with Taxonomy intriguing. Taxonomy, as I understand it, is in the abstract about how you group things (in the case of Habari those things are posts) and Revisions, one could say, in the abstract are about how you deal with the history of something (in the case of Habari a post) If the logic is that taxonomy (the abstract) is in core and concrete things can be done with it in plugins, e.g. a menus plugin or a categories plugin, then I can see the logic of Revisions in core that can be used via plugins to do concrete things, e.g. build a wiki or an editorial workflow. Is that the logic?

One thing that has been mentioned in the course of the discussion is the potential of building an editorial workflow on Habari with Revisions. This is something I have thought about before, and I am very excited by the potential. What I have thought about before is an editorial workflow in a multi-user setup, and the one fundamental thing I would need is a way to prevent 2 people editing the same post at the same time. If I understand correctly how Owen has implemented revisions, the revisions made by 2 people of a post would result in each of their revised versions being stored, so one could always go back to one or other person’s version. However, for what I have in mind I would really need a single post that was edited by person A, then by person B (or vice versa, by person B, then by person A), but not by the two simultaneously. Does anyone have any thoughts how theoretically this could be implemented? And whether it would be a difficult or easy thing to implement?

Philip

[Chris Meller]

Currently if Person A and Person B both are editing a post and Person A saves their changes, then Person B tries to save their changes, Person B will get an error indicating it has been modified by another person and *lose their changes*.

Revisions would allow us to significantly improve that experience.

--

[Chris J. Davis]

What it sounds like is that you would have a plugin that gave you extended permissions on posts.

You would be able to "assign" a post to a user, and while it is assigned to them, only they, and any super admins, could access and make changes. Once they are done, the post could then be assigned to the next person in line, etc.

There are already plugins that allow for this workflow of assigning post objects to people, with corresponding permissions tokens. Having revisions would allow you to revert a change that User A made while they had access, for instance.

[John Edmondson]

Those of you who frequent the irc channel know i have been redesigning the scouts website. I plan on it becoming a multi user site with the scouts editing and posting posts / pages. Revisions would be a useful tool to have. As is the Menu plugin that's available in core.

So a +1 from me.

--
==========About============
www.john.edmondson-uk.com
skype is john.j.edmondson
========================

[Morgante Pell]

While I remain unconvinced that this should exist in the core code, I'm willing to concede that I'm in the minority and give in to the majority.

Given that the general consensus seems to be in favor of core revisions, I look forward to seeing how this feature can be used.

In fact, I just took over the website management of a small newspaper and will shortly be implementing a plugin to manage a complex user editorial flow (basically, managing a story from its first pitch through all edit checks and eventual publication). If anyone else has been working on this, let me know.

~Morgante

[ringmaster]

Hi Philip,

Let me see if I can sort some things out from your message:

On Saturday, February 2, 2013 12:51:42 PM UTC-5, Philip Buckley wrote:

As an end-user rather than a developer, I must admit I don’t really understand the significance of “in core” versus “in a core plugin”.

There are three "conditions" code can be in:

1. Core Code -- Core code is any part of Habari that is not a plugin or theme that is packaged in the release.  If you download Habari, most of it is "core".

2. A non-core plugin or theme -- A non-core plugin or theme (usually just "plugin" or "theme") is something you download from somewhere after you've installed Habari.  It does not come with the main distribution package.

3. Core Plugin -- A core plugin or theme is a plugin or theme that comes with the core distribution package.  These addons are slightly different than ones you get separately for three important reasons:

a. Everyone gets core plugins whether they want them or not, because they're within the core download package.

b. Core plugins are maintained along with Habari's core code itself.  They're expected to be regularly maintained, and excised if they're not.

c. If you install a vanilla Habari, the core plugins always appear in the list of plugins to activate in the installer, and some of them are even marked *by default* for activation.  This is to remove as much configuration as possible from the process of installing a baseline useful Habari, while still allowing advanced users to remove those basic features either to replace them with something more advanced or omit them from their specialized installs.

A core plugin example is the autop plugin, which converts double line-breaks in your post content into paragraphs in HTML automatically.  I routinely disable this plugin in my installations to replace it with my custom plugin, selectivep, which lets me only apply autop to specific types of posts.

 

I find Owen’s comparison of Revisions with Taxonomy intriguing. Taxonomy, as I understand it, is in the abstract about how you group things (in the case of Habari those things are posts) and Revisions, one could say, in the abstract are about how you deal with the history of something (in the case of Habari a post) If the logic is that taxonomy (the abstract) is in core and concrete things can be done with it in plugins, e.g. a menus plugin or a categories plugin, then I can see the logic of Revisions in core that can be used via plugins to do concrete things, e.g. build a wiki or an editorial workflow. Is that the logic?

Yes, exactly!  As another example of how this division of labor is quite common in Habari, take the autop vs selectivep example from above.  Both plugins apply paragraph tags to post content.  The selectivep applies it only to some posts, and the autop applies it to all posts.  But the filter functionality that creates the paragraphs is itself part of core.

It's very likely, as a result of revisions being added to core that a core plugin will emerge that provides basic access to the revision data that Habari is storing.  Admins are welcome to disable that plugin and instead use something more robust.

 

One thing that has been mentioned in the course of the discussion is the potential of building an editorial workflow on Habari with Revisions. This is something I have thought about before, and I am very excited by the potential. What I have thought about before is an editorial workflow in a multi-user setup, and the one fundamental thing I would need is a way to prevent 2 people editing the same post at the same time. If I understand correctly how Owen has implemented revisions, the revisions made by 2 people of a post would result in each of their revised versions being stored, so one could always go back to one or other person’s version. However, for what I have in mind I would really need a single post that was edited by person A, then by person B (or vice versa, by person B, then by person A), but not by the two simultaneously. Does anyone have any thoughts how theoretically this could be implemented? And whether it would be a difficult or easy thing to implement?

This is a complex problem.  As Chris Meller points out, 0.9 can handle this situation, but it does so in a surprising and poor manner.  If users A and B begin editing the same post, and user A saves their version before user B, user B is informed that the post was changed in the interim, but user B's version is lost.  This is a problem.

There are many ways to try to solve this problem, but what is the best thing to do?  What should appear when user B tries to save?  Should they see their version?  User A's?  Should it show a comparison of both versions to the original?  What if user C also saves a version in the interim?  Or should it lock user B out of editing until user A is done?  But then what if user A abandons editing and leaves the post locked?

At worst, storing revisions would prevent data loss.  Data loss has always been a no-no for Habari, so this seems like a big win.  Then, figuring out a way to make revisions useful for the kind of collisions you're talking about will be possible.

I hope I've explained that all well.  Maybe you can help describe what Habari or a plugin should do with all this?

Owen

[Philip Buckley]

Hi,

Thankyou very much, Chris Meller, Chris Davis and Owen for your comments on my email. Thankyou, Owen, for the explanation of the "conditions" code can be in - that makes it very clear.

As regards, the particular use for revisions in an editorial workflow that I am thinking about, this is the scenario . . .

My company produces documents in languages for print (or for the web in the form of PDFs). The documents are laid out by us in InDesign. Translators and editors edit the translations in Word. We use a system I have developed that lets us, in effect, synchronise the text from the Word files with the text in the InDesign files. So at present the workflow goes something like this. . . We put up on our ftp site “Proof A” PDFs of of all the language-version InDesign files and corresponding “Proof A” Word files. Country editors (from the offices of the client we are working for) log in and download their particular country files. They indicate layout changes in the PDFs and make text corrections in the Word files. They return the files to us as “Proof Arev” (A revised). We implement the requested changes (including tidying up the Arev Word files) and put up on the ftp site “Proof B” PDFs and Word files. So it goes on, until approval.

In many ways it works very well. In particular, having the editors make their changes in the Word files is efficient because of how we can synchronise them with InDesign. However, their are some downsides. With large projects the number of files flying about can take some managing (sometimes we might be doing 30, even 40, language versions of a document, each of those going through perhaps half-a-dozen revision rounds). Also the country editors can do silly things, in particular they sometimes make their revisions in an old version of their Word file (e.g. at Proof D they send us back revisions made to Proof B again).

So for a long time I have pondered whether the country editors could edit their translations online. I really, really like Habari. So I have imagined a site built on Habari where the country editors log in, are presented with a list of the current projects and the posts they need to edit (posts replacing the Word files of our current system). They would make their changes, saving as they go along, and when they had made all their changes would press a button indicating that they were finished (perhaps equivalent to the Publish button). We would receive a notification that they were finished, take the finished (published) post and implement the text changes in InDesign.

The reason I was asking about 2 or more people simultaneously editing a post is that whilst most countries will have just one person responsible for editing a particular country’s files, some countries have 2 or 3 people. At present we just put one set of files up on the FTP site and, in effect, say to that country editors “sort it out amongst yourselves (as to who reviews first etc), just make sure you only give us back one set of files” - which is OK as far as it goes.

Using Habari with Revisions but no checks at all, I could imagine person A and person B starting to edit at roughly the same time, person B finishing, then person A finishing. Person’s A revisions would be the “latest” version, whilst person B’s revisions would be in the history but not incorporated in the latest version. This is what would be unsatisfactory.

I think having the fact that 2 people were editing at the same time flagged at the point where either one clicked the Save button would be a jarring user experience (e.g. showing at that point revisions made/being made by the other person).

Locking out everyone else at the point when person A starts to edit is appealing as a solution (because It would, I think, be a relatively simple solution to implement), but as you say, Owen, “what if user A abandons editing and leaves the post locked?”. It *would* rely on the editors finishing editing properly, and that can’t be guaranteed given the stateless nature of things on the web. Person A might abandon editing and forget to finish off, or person A might lose his/her internet connection halfway through and - through no fault of their own - be unable to finish off properly.

I think that probably your suggestion, Chris Davis, of a plugin to control the assigning of posts to individual people is the *safest* way to go. It would be very smart if, in the case of a single country editor they would simply have a Finish button, whereas in the case of multiple country editors they would see either the Finish button or have the choice to, as it were, ‘pass the post on’ to one of the other 2 or 3 editors for that country - a Pass On button with a dropdown showing the other people responsible for reviewing that country’s material. That would be smart but maybe complicated to implement! 

Anyway, again, thankyou very much for all your comments on this issue. It is all very valuable food for thought.

Philip 

[Owen Winkler]

On 2/4/2013 7:54 AM, Philip Buckley wrote:
>
> I think that probably your suggestion, Chris Davis, of a plugin to
> control the assigning of posts to individual people is the *safest* way
> to go. It would be very smart if, in the case of a single country editor
> they would simply have a Finish button, whereas in the case of multiple
> country editors they would see either the Finish button or have

> the choice to, as it were, �pass the post on� to one of the other 2 or 3

> editors for that country - a Pass On button with a dropdown showing the

> other people responsible for reviewing that country�s material. That

> would be smart but maybe complicated to implement!

This actually doesn't seem that complicated. Whatever the editorial
workflow, the most complicated part seems to be sorting out the workflow
itself. Implementing it is academic after you have that.

In this case, you'd probably also want a thing that marks a post as
being edited by whoever first grabs it. So if you try to edit a post
that you're not "active" on, it'll throw a big warning up at the top of
the page, telling you something like, "Bob started editing this 50
minutes ago." That way, if you see something like "Bob started editing
this 4 days ago", then you know that you should ask Bob if he's done or
what. The message may not prevent you from editing, just tell you to
beware.

The workflow would probably also track who has already edited it, so
that you know who is left and whether a review is complete. This would
be pretty simple with the new revisions functionality; I can think of a
couple of different ways to implement it.

Owen

[Philip Buckley]

Hi Owen,

On 4 Feb 2013, at 14:10, Owen Winkler wrote:

> On 2/4/2013 7:54 AM, Philip Buckley wrote:
>>
>> I think that probably your suggestion, Chris Davis, of a plugin to
>> control the assigning of posts to individual people is the *safest* way
>> to go. It would be very smart if, in the case of a single country editor
>> they would simply have a Finish button, whereas in the case of multiple
>> country editors they would see either the Finish button or have

>> the choice to, as it were, ‘pass the post on’ to one of the other 2 or 3

>> editors for that country - a Pass On button with a dropdown showing the

>> other people responsible for reviewing that country’s material. That

>> would be smart but maybe complicated to implement!
>
> This actually doesn't seem that complicated. Whatever the editorial workflow, the most complicated part seems to be sorting out the workflow itself. Implementing it is academic after you have that.

In practice we are simply told by the client who in the countries needs to be notified when the files for that country are available. So we might be told that for Germany we are to notify Andreas, for Spain Pablo, for Norway Hedda and Helga. It might be that Hedda and Helga both want to review the Norwegian documents or it might be that they both need to be notified because one or other of them will do the review (perhaps whichever is available at the time will pick it up and act on it - from our end it doesn't matter and we don't really need to know).

> In this case, you'd probably also want a thing that marks a post as being edited by whoever first grabs it. So if you try to edit a post that you're not "active" on, it'll throw a big warning up at the top of the page, telling you something like, "Bob started editing this 50 minutes ago." That way, if you see something like "Bob started editing this 4 days ago", then you know that you should ask Bob if he's done or what. The message may not prevent you from editing, just tell you to beware.

Ah, I like that. That's a different and a potentially much easier way of doing it than I had thought about. I had thought it would need to be a hard "lock-out", so if person A started editing no-one else could edit until that first person had finished (which would raise the problem already discussed of the abandoned post or disconnected user and maybe require an admin user or the original editor intervening to "unlock" a post). But if it was simply that the second user was told by a message as soon as they started editing that the first user had started editing before - the "Bob started editing . . ." message - then they could make their own decision as to how to proceed: OK I'll come back in an hour's time when Bob has finished or OK, I know Bob has made all the changes he wanted to 4 days ago because I have spoken to him since then, so I'll just carry on. If the second user is not prevented from editing, then they are not held up and can use their discretion whether to edit or not. Very nice! :-)

> The workflow would probably also track who has already edited it, so that you know who is left and whether a review is complete. This would be pretty simple with the new revisions functionality; I can think of a couple of different ways to implement it.

In the Hedda/Helga example we don't know (or need to know) whether actually both or just one of the two will do the review, therefore as far as knowing whether a review is complete, I think all that's needed is a clear "Finish and Stop" button (that they know means "all the revisions have now been made by everyone for this country in this round of revisions").

Where tracking would be very useful and important is, as sometimes happens, something goes wrong and it needs to be established who requested a change and when . . . Helga requested such and such a change on such-and-such a date. For that situation the revisions history would be great.

I am getting very excited about the possibilities here! :-)

Philip

[Konzertheld]

So, reading back all the discussion, it seems to me the next step in revisions should be a core plugin that makes use of the new functionality, so users can, but do not have to, actively use it without downloading a plugin from somewhere else. I opened a ticket for that so we can have a separate discussion on what should be included in this core plugin, and I'd like ringmaster to contribute as I know he somewhen (at least briefly) wrote some code for that.