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 On 2 Feb 2013, at 22:40, ringmaster wrote: > 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 > > > -- > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
