Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

(tye)Re2: New site editors

by tye (Sage)
on Feb 21, 2001 at 12:12 UTC ( #59880=note: print w/replies, xml ) Need Help??

in reply to New site editors

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.

This serves to remind editors of the seriousness of this task. It also prevents someone from borrowing my desktop or stealing my cookie with home-node JavaScript and then kicking off a LWP::UserAgent that munges every node it can find.

In the mean time, I suggest all editors disable JavaScript (at least for *perlmonks.{org|net|com}) and, if they hadn't disabled it before, change their password. That just seems like way too tempting of a target...

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

Replies are listed 'Best First'.
Re (tilly) 2: New site editors
by tilly (Archbishop) on Feb 21, 2001 at 18:55 UTC
    I don't believe that this will be an issue.

    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.

    All of that said, I think that turning JavaScript off is a great idea. I turned it off a long time ago from home. I have turned it off from work as well. I don't really want someone else to login and start posting as me or sending nasty chatters...

      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

      • unapprove and unfrontpage nodes (and it occurs to me now that at some point we may want to make an "editor unapprove" such that it can't be undone by the regular "approve" process given the concern over recent approving and frontpaging of questionable nodes)
      • move root nodes to other sections
      • move replies to be under another node (for duplicates where there are replies to both nodes)
      • mark a node as "in transit" such that no replies to it can be started and informing the editor of who has already started a reply and when (all replies now go through the same "comment on" code, so this should be possible -- though some work may be required to disable submission of hand-rolled replies that skip this "comment on" code); if this feature takes longer to come to be, I understand (:
      • "Clear" nodes from Nodes to Consider and Editor Requests. BTW, I think these two serve different purposes and both deserve to remain in use. If we go with fettered editors, perhaps Editor Requests could be enhanced such that "joemonk" can give editors permission to edit or delete "joemonk"s nodes by making a Request (allowing "joemonk" to put his own nodes up for consideration would also be an option [though not having to vote for such cases makes more sense to me] as long as it became possible to submit multiple requests for consideration of the same node -- a feature I'd like to see anyway so opposing comments can be added to Nodes to Consider).
      • Read-only access to any node's source text. With unfettered editors, this could be done "by hand". With fettered editors, the example goes like this: A really ugly question is posted. The node gets considered and voted on and an editor wants to update it. During this time (or even a while afterward), the new monk posts 3 new versions of the question, each with a little bit better formatting but also including correction to content. Either the "final" version of the question still isn't perfect or the first version has already been voted into the "edit" category and so became quite hard to vote into the "delete" category (which means we may want to let level 6 monks "change their vote" on Nodes to Consider), so the editor wants to take the best of the information from the "final" version and put it into the first version that will be kept. We can all cut'n'paste the rendered version but you'll lose several key sets of properties. So editors (and perhaps everyone, for that matter), should have a way to cut'n'paste the "source text" for a node.
      All of the above powers I think should be available without the need for a node to be considered and voted on. And I think all actions by editors should be logged and everyone should at least be able to view all log entries that apply to their own nodes (including which editor did it and when).

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://59880]
[atcroft]: (Full disclosure: I may have the idea right but small typographical errors, so please test any code I suggest. :) )
[atcroft]: abner: Or are you wanting to do something where you need to bind an array to a placeholder (in which case the bind_param_array method may be of use.

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2017-01-24 03:59 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (202 votes). Check out past polls.