in reply to Considering NTC and approval nodelet

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.

  • Comment on Re: Considering NTC and approval nodelet

Replies are listed 'Best First'.
Re^2: Considering NTC and approval nodelet
by Aristotle (Chancellor) on Jul 19, 2002 at 19:50 UTC
    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.