They'll have full edit permission to all writeups. Their editing will largely be doing things to make the site look prettier. Most of which will be getting rid of PRE tags, and adding CODE and READMORE tags as necessary. Most of the editors already point out these problems on the nodes to consider page. Now they'll be able to fix them. Other powers will include moving root nodes between sections, and removing items from view on the frontpage or a section page.
These powers will probably be arriving in the next few days when I get some time to sit down and code.
What about accountability for their actions? The truth is that if I thought I had to worry about the actions of any of the people in the editors group I wouldn't have chosen them. All of the chosen ones have demonstrated a good mix of the following:
|Replies are listed 'Best First'.|
Re: New site editors
by neshura (Chaplain) on Feb 21, 2001 at 04:58 UTC
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.
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!
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:
Re: New site editors
by footpad (Abbot) on Feb 21, 2001 at 04:42 UTC
A couple of tiny questions, if I may. Will the editors also be able to:
Re: New site editors
by mikfire (Deacon) on Feb 21, 2001 at 06:22 UTC
When will an editor be able to edit a node? Maybe we could raise the accountability by allowing editors to edit a node ( and I realize those so listed would probably do this anyway ) only after it has received sufficient "edit" votes in the nodes to consider page.
When a node is sufficiently marked, an editor could "take ownership" of it and it would disappear from nodes to consider and appear on a special editorial page with the volunteering editor's name associated with it. This would both clear up the nodes to consider ( which is a Good Thing ) and prevent several people from editting the same node simualtaneously.
I also like neshura's auto-notification. The editors are doing this solely as volunteer work ( unless vroom is paying them off with free perlmonks stuff :) and it should be as easy for them as possible. I can also see a situation where, despite an individual editor's best effort, said editor simple forgets to /msg the author and thereby cause some avoidable hard feelings.
If this is done, I think it is important that the /msg come from the editor, ie, it appears in the chatterbox as "editor says". The person being editting should know who changed it so they can ask questions of the editor directly.
Is there going to be a way the person being editted can find out why the node was changed? My understanding is that only monks of certain rank can see the nodes to consider. Feed back is vital here if we hope for anybody to learn what the standards are, especially if it is a user who hasn't figured out to use <code> tags yet.
I also think tye has a point in that there needs to be a "release" button - I ( although I am not an editor ) also usually need several previews before I get my posts correct enough. When an editor hits the "release" button, the /msg would be fired and the node will be re-instated to previous place ( but not form ). That should also simplify the database - it only needs to remember the before and after images of a node if a restore option is provided.
Of course, having no real clue of how E2 is coded I have no idea how hard this would be to code.
Offering my simple 0.02 USD worth,
(tye)Re2: New site editors
by tye (Sage) on Feb 21, 2001 at 12:12 UTC
A new wrinkle occurred to me... I'd really like a second "editor" password for each of the editors. This would be one that isn't stored in a cookie (at least not for longer than one editing session) so that editors have to type their second password in each time they go to edit another's node.
First of all editors will only have permission to do things that have been agreed by several others to need doing. Which limits damage largely to a limited number of nodes right there.
Secondly any damage done is readily undone. (The same principle that allows Wikis to survive despite having virtually no security checks.)
Thirdly if an editor ran amok (either through going off the deep end, or through someone stealing a password), it would quickly become both obvious and investigated by vroom.
Fourth the people who would be in a position to know about and try to take advantage of careless editors are mostly themselves members of this community. So they are people with something to lose.
Fifth, I could show up as Anonymous Monk and cause vastly wider damage to the commmunity than I could as a rogue editor. Indeed if someone wants to waste energy getting an editor account instead of just causing damage, I think that is a good thing.
I agree that only being able to edit properly "considered" nodes covers the need for a separate password. vroom's "full edit permission to all writeups" made me think that this isn't what is being proposed. My impression of what was being proposed has shifted from "special tools", to full edit of only root nodes of moderated sections after they have been properly "considered", to unfettered edit with accountability, perhaps to full edit of any considered nodes.
Personally, I'm "on the fence" as to whether full edit should only be allowed after a node has been considered (more power to quickly respond to problems vs. more possible problems with abuse, perceived abuse, or fear of abuse). I guess I'd like whatever vroom wants and could understand him feeling that unfettered editors might make his life easier and/or this site better. But I never would have advocated unfettered editors if I hadn't first gotten the impression that vroom wanted it.
Update: Another option occurred to me. Perhaps editors could edit root nodes of moderated sections without them having to be considered first (since this is really where most of the problems lie) but could only edit non-root nodes (that is, nodes that the author is already allowed to edit) after conderation and voting. I think I prefer this idea.
So, I guess that needs to be decided. I leave that decision to vroom but think he'd appreciate feedback on how other monks feel about it. Anyone who has a simple opinion on this and doesn't want to post a node on it, feel free to /msg me and I'll add your vote to this node (anonymously, if you prefer). Or a poll on something like this might be in order at some point.
As for other editor powers, here are some I'd like to see, most of them mentioned by others. I think editors should have the ability to
One power that I think editors should not have is "delete". I think the current method of deleting "bad" nodes is better, though I'd probably allow nodes with a reputation of zero to be reaped to prevent the need for downvotes on duplicates. And/or the above-mentioned enhancement to allow a person to request that their own node be reaped (perhaps via Editor Requests) would be nice.
One little technical nit: Editors need to be able to edit nodes that won't even display properly on their browser. It is still possible to compose a node that has unmatched HTML tags such that all of the edit forms below it are useless. At least for some browsers, I think you can even prevent the entire page from rendering.- tye (but my friends call me "Tye")