Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^3: The ability to delete

by Joost (Canon)
on Oct 22, 2005 at 16:08 UTC ( #502221=note: print w/ replies, xml ) Need Help??


in reply to Re^2: The ability to delete
in thread The ability to delete

Your making the assumption that emptying a node is responsible behaviour. It is not.

Considering a writeup for being a duplicate will usually result in a fairly quick deletion, If the author has other reasons for wishing the post to be retracted, they'd better be very good - IMO it's usually better to update the node (by adding a statement, crossing out lines, whatever) than clearing it out or deleting it.


Comment on Re^3: The ability to delete
Re^4: The ability to delete
by kiat (Vicar) on Oct 22, 2005 at 16:28 UTC
    I think you might have misread my post above. I don't think I implied that "emptying a node is a responsible behaviour". What I said was, when you give the user the power to edit, you're potentially giving her the power to remove the entire content of the post - not deleting the post and making the node (id) disappear but emptying its content. So the question is, why empower the person to potentially remove a post's entire content and yet not allowing her to delete it?
      I know what you meant, but it's a question of perspective: if the ability to edit a node comes with the assumption you won't remove the content (because that's not responsible behaviour), why add the ability to remove the node?

      The only reason to use it would be an accidental double-posting. It's possible to prevent most of those programmatically and I think that would be more productive than adding a delete button that in effect should only be used for just that occasion.

        Just a small observation: I've noticed that many of the senior monks here must be mathematicians. In that many people point out that "the right way" is some solution X, which never gets implemented, while a lesser, but wildly more implementable, solution Y gets ignored in favour of X.

        Mathematicians seem to prefer proving that it can be done rather than doing it, too ;-)


        I can buy that "solution Y" is bad because of a, b, and c. But saying that there is a better solution (which isn't going to be implemented in anyone's spare time any time soon) is misleading. Thus, in our current thread, saying, "We're actually trying to close those loopholes, not open them up," is a completely valid, plausible, accurate, direct response. Saying, "A better solution is..." is just misleading. Misleading in that there's an implication that it's not only on the to-do list of the pmdev, but that someone may actually work on it some time in the near future (where "near" is relative, but likely within the next month or two). While you may not have meant that implication, I hope you can at least see how others may infer it (incorrectly), and that's how it becomes misleading.

        Even though I'm a firm absolutist, I can still see how perception colours reality - as someone who is still a relative newbie on PM, I can see how some may infer these things. So I'd encourage the more senior monks to be aware of the inferences others may draw, and try to help them not make those inferences.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://502221]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (2)
As of 2014-08-31 01:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls