(tye)Re: New site editors

[tye]

I agree that accountability is important. Perhaps even more important to me is communication so that people know that their node was editted, by who, why, and what to do it they have a problem with it.

But there are also a lot of practical details to deal with. If each edit is going to generate an automatic /msg and some DB entry recording the change so that it can be undone, then I think we'll have a real problem with 4 editors all changing the same <pre> to <code> at nearly the same time generating a very confusing situation for the author of the node (and probably for the database and site engine as well).

Don't get me wrong, I really like what neshura has proposed and I think it is important. I'm just trying to analyze it carefully enough so that we have a good chance of a workable implementation. I'm also trying to anticipate how hard different approaches will be for vroom to hack into place and then to get working reliably.

Then there is the fact that it can sometimes take me 14 rounds of edit and submit before I get my simple change right (not usually, but on rare occasions). I'd hate to be generating 14 "tye editted id 1234" /msg's to some poor monk's inbox and filling the DB with 14 copies of the node.

For everything but root nodes of unmoderated sections, the "petition for undo" seems nearly (though not completely) pointless since the author could simply edit the node (unless an editor editing a node changes the ownership of the node -- which I would be against since it leads to little problems like the node not showing up in that user's list of nodes, just like happens with Categorize Q+A nodes now]).

Perhaps much of this can be done, at least at first, with more human work and less automation. For example, I'd be fine with a policy that states that editors should:

• /msg the author when they change a node
• include an unobtrusive link (or even HTML comment) at the start of the editting process that just notes which editor is changing the node so that other editors are less likely to duplicate the effort and leave but update the link/comment when done, if nothing else, in case they introduced a typo

as long as this is augmented by at least a log of which editor changed which node and when. As the process matures and time passes, more automation can be introduced.

        - tye (but my friends call me "Tye")

[tilly]

Why not just force editors to go through a preview, submit process identical to what people do in normal posts? Until you hit "submit", no message is sent. You can "preview" as much as you want with no visible change other than "being edited by foo"...

[tye]

Yes, that would certainly cut down on the problem. It seems like the current preview code for new nodes would be fairly easy to adapt for modifying existing nodes. But it poses its own set of problems.

So the preview would automatically add the "being edited by foo", I guess. What happens when two editors edit the same node? If there is a lock to prevent that, how do you break it? Don't forget to add a "Cancel" button so that you can change your mind and restore the node to its original state without triggering too much of the automated accounting.

And I don't think that solves the problem with providing an "undo". I'd love to have the pre-edit node text saved (for say, one week) when an editor makes a change. But I'm not sure trying to automate the restoration is a good idea, at least at this point.

And, despite how it sounds, I'm not really trying to shoot down this idea. I just want to make sure we've kicked it around enough before the task is undertaken.

I don't see this as a trivial problem to solve. Currently, if I "SoPWify" a Categorized Q+A while someone is in the middle of composing an ansewer, then a node that looks like a Categorized Q+A answer gets posted as if it were a regular reply (owned by Q+A Editors but hopefully with the votes going to the actual author, though I haven't looked into that). The same race happens when I delete a question. Plus I can delete a question without deleting the answers and leave a bunch of headless answers around. Plus it is actually possible to edit your own root nodes even though you aren't supposed to be able to.

Not that those types of bugs would necessarilly be a huge problem in the first implementation of this. I guess I'd like the effort to be concentrated on getting the logging and security really solid before trying to make too fancy of a tool.

        - tye (but my friends call me "Tye")