Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: New site editors

by neshura (Chaplain)
on Feb 21, 2001 at 04:58 UTC ( #59813=note: print w/ replies, xml ) Need Help??


in reply to New site editors

My big concern is accountability -- not that I don't trust fellow editors, just that I believe it is of paramount importance.

In terms of the technical and social approach to implementing checks and balances on the editing process, I would like to see something along the lines of the following.

  • The node should go "live" immediately on editing
  • If a person's node is edited, they should be autonotified in the chatterbox.
  • If the author feels that the editing has been done in error or with no regard for content/intent, there should be an option easily accessible from that node called "Petition to Restore".
  • When a petition is made (and I imagine this will be quite rare, since the vast majority of edits are due to the newness of the user), at most ONE editor should be required to approve it in order for the node to be restored to its original glory.
    • Point: The original intentions of the poster ought to be given a great deal more weight than the wishes, however well-intentioned, of the editors.
    • Effect: Edits would be essentially an assumed unanimous agreement by the editors group. For a petition to be denied (and an edit permanent), every editor must deny it
    • Why "petition" and not just "restore"? Users who have not bothered to figure out the correct tags to wrap code in will also not bother to figure out what the "Petition to Restore Node" button does before clicking it. And since there will be users that will click it without useful intent, the hard work of the editors should be protected at a minimum level.

It should also be noted somewhere which editor is responsible for changed nodes as well, so that they may be queried as to the logic behind the changes.

That is all I have thought of at the moment.

Update: I should clarify my assumption that for any of the above to work, node-level locking is a required technology. Thanks tye!

e-mail neshura


Comment on Re: New site editors
(tye)Re: New site editors
by tye (Cardinal) on Feb 21, 2001 at 05:49 UTC

    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")
      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"...

        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")

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://59813]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2014-12-25 03:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (159 votes), past polls