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")
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.