Considerations can be either delete requests or edit requests. They can never be both. In that case, why allow approvers to vote 'delete' against an edit request, or 'edit' against a delete request?
For the simple reason that Consideration is "first consideration comment in wins". If someone submits a comment to the effect that a node should be deleted for no Perl content, but I look at it and decide that the node doesn't need to be deleted, but does need a formatting edit, I want to vote to that effect, rather than waiting some indeterminant time for the delete vote to settle, so that I can reconsider the node with a "this needs an edit" comment. If enough people agree with one side or the other, it'll be reflected in the vote.
For edit reqests, why not get the approver to do the changes and submit his/her edit for approval? This could be displayed in NTC in its raw pre-markup form, either with changes highlighted, or as a diff listing.
This could lead to gridlock. It assumes that the approver agrees that the edits need to be done. Our current system, where an editor volunteers to make the fix, works fine.
| [reply] |
If someone submits a comment to the effect that a node should be deleted for no Perl content, but I look at it and decide that the node does, but needs a formatting edit, I want to vote to that effect, rather than waiting some indeterminant time for the delete vote to settle, so that I can reconsider the node with a "this needs an edit" comment.
I don't like the idea. Voting edit to have the formatting fixed when someone asked for it to be deleted is just weird; and the editor has to guess at what you wanted fixed. Title? Formatting? Something else? Voting delete when someone only considered for editing is outright bad: the edit reason will show up as delete reason on the reaped node.
A better idea that begs the question whether it can be added to the current system easily:
To be able to consider a node separately for both editing and deletion at the same time with different reasons. A node considered for deletion would not offer a vote for edit, and vice versa. If someone does consider it for editing, it then offers to vote edit for the edit reason, delete for the delete reason, or a blanket "keep".
Makeshifts last the longest.
| [reply] |
I like #1. I don't like #2 or #3.
WRT #2: if the reasons are at all useful, it's likely people will simply pick whichever default comes closest and leave it at that, rather than spell out his concern. Though considering the valid reasons would probably be something like "Trolling / Excess profanity / Yes, there really is another reason to delete:" (last one for supplying a freeform reason), we might see less misconsidered nodes so I'd be all for it. *grin* For editing, preset reasons don't offer much either: most editing considerations seem to be for markup fixes and title changes. But in case of retitling, it is a good idea to propose a new title with the reason, so the dropdown would only contain "fix markup" which seems like a waste..
WRT #3: Most of the time, retitling requests already include a new title in the consideration reason. The only real change would be voting on edited content proposals, and I expect that will lead to occasionally having to keepvote against a bad proposition before someone else can reconsider with a better edit. In contrast, I trust the editors to do a good job of editing nodes that need fixing without trial and error. Voting for actual edits might have merit if it was felt that the editors are overburdened, but I don't see that.
Bunch of updates later: I hope this post is actually coherent now..
Makeshifts last the longest.
| [reply] |