|Problems? Is your data what you think it is?|
A good idea. I have a few more questions, and possibly some solutions to the at least tye's questions.
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,