-----Original Message----- From: Todd Allen [mailto:toddmallen@gmail.com] Sent: Wednesday, May 23, 2007 08:13 PM To: 'English Wikipedia' Subject: Re: [WikiEN-l] BLP, and admin role in overriding community review
David Gerard wrote:
On 24/05/07, Ron Ritzman ritzman@gmail.com wrote:
On 5/23/07, David Gerard dgerard@gmail.com wrote:
The point is that isn't particularly fame. The incident is famous, the person's pretty much only famous in association with the incident.
Could some argue that based on this [[Monica Lewinsky]] should be deleted?
I'm sure they could argue anything they got it into their heads to, particularly for the sake of a querulous argument. And, on Wikipedia, probably have.
- d.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Which is exactly why we -shouldn't- give a blanket license stating "Do whatever you want, and you're not subject to community censure or an overturn by consensus, only if someone cares enough to take it to ArbCom -and- manages to get it accepted." At the very least, if the ArbCom is going to set itself up as an arbiter of BLP disputes, it should be -required- to accept any such case (especially if the threat of anyone who acts without ArbCom's blessing is banning or desysopping, in this case, ArbCom effectively sets itself up as the only way the matter -can- be resolved.)
I'm not really sure this is the most efficient way to deal with that. The community deals with a lot of things on its own. Sometimes, we need the ArbCom to sort out a particularly nasty mess. More often, consensus swings pretty clearly one way or the other. Taking an -entire class- of articles out of the hands of the community (and don't be fooled, if this does become policy, any edits to BLP's will depend on who first yells "It's a BLP issue!" and becomes immune to reversal until the ArbCom can get around to saying it's not) is a major shift in policy, practice, and basic philosophy, and I think (with all due respect) that such a shift requires more than Fred Bauder saying "I said it's so, now deal with it."
I think you've won the point, now tell us how you suggest dealing with the problem.
Fred
Fred Bauder wrote:
-----Original Message----- From: Todd Allen [mailto:toddmallen@gmail.com] Sent: Wednesday, May 23, 2007 08:13 PM To: 'English Wikipedia' Subject: Re: [WikiEN-l] BLP, and admin role in overriding community review
David Gerard wrote:
On 24/05/07, Ron Ritzman ritzman@gmail.com wrote:
On 5/23/07, David Gerard dgerard@gmail.com wrote:
The point is that isn't particularly fame. The incident is famous, the person's pretty much only famous in association with the incident.
Could some argue that based on this [[Monica Lewinsky]] should be deleted?
I'm sure they could argue anything they got it into their heads to, particularly for the sake of a querulous argument. And, on Wikipedia, probably have.
- d.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Which is exactly why we -shouldn't- give a blanket license stating "Do whatever you want, and you're not subject to community censure or an overturn by consensus, only if someone cares enough to take it to ArbCom -and- manages to get it accepted." At the very least, if the ArbCom is going to set itself up as an arbiter of BLP disputes, it should be -required- to accept any such case (especially if the threat of anyone who acts without ArbCom's blessing is banning or desysopping, in this case, ArbCom effectively sets itself up as the only way the matter -can- be resolved.)
I'm not really sure this is the most efficient way to deal with that. The community deals with a lot of things on its own. Sometimes, we need the ArbCom to sort out a particularly nasty mess. More often, consensus swings pretty clearly one way or the other. Taking an -entire class- of articles out of the hands of the community (and don't be fooled, if this does become policy, any edits to BLP's will depend on who first yells "It's a BLP issue!" and becomes immune to reversal until the ArbCom can get around to saying it's not) is a major shift in policy, practice, and basic philosophy, and I think (with all due respect) that such a shift requires more than Fred Bauder saying "I said it's so, now deal with it."
I think you've won the point, now tell us how you suggest dealing with the problem.
Fred
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
I have a few different suggestions. They're just brainstorming of a sort, so I'm not even necessarily saying they're great, but they might make a good starting point. They're also not all necessarily mutually exclusive, a lot could probably be used together.
1. Set up some kind of secondary arbitration committee, which deals solely with BLP-type issues.
Pros: This won't put more load onto an already heavily-burdened ArbCom, and could be a good way to resolve such matters without them blowing up (like they tend to do now.)
Cons: Since we do have so many living bios, a body like this could still become overwhelmed if it's responsible for all such disputes. It also takes a lot of decision-making out of the hands of the community at large, which I imagine a lot of people would object to.
2. Leave it as-is. (That's always an option, after all.)
Pros: Doesn't really require any change at all. We can always hope the community will, with time, come to some sort of agreement or consensus.
Cons: "As-is" seems to be causing a lot of heated disagreements between very sincere editors, and many argue that it's also resulting in (take your pick) the retention of a lot of unacceptable BLP articles, or alternatively in the deletion of a lot of perfectly acceptable ones.
3. Ask OFFICE (Jimbo or the Foundation) to take a more active role.
Pros: These are people who are generally highly-trusted for good judgment, and really do have the authority to act unilaterally if they believe it to be necessary. When OFFICE takes an action, there's absolutely no doubt-you don't touch it until and unless you talk to them and they say it's alright.
Cons: Wouldn't scale well. Those responsible for implementing office actions have a lot of other responsibilities as well, and it would probably become an inordinate demand on their time to ask them to deal with all such cases. Also takes a lot of decision-making power out of the hands of the community, which again, may become controversial.
4. Clarify the BLP policy. There seems to be a serious dichotomy between those who interpret it largely as written ("unsourced or poorly-sourced controversial information about a living person should be removed on-sight, and if that's all there is and has ever been to an article, it should be deleted at once") and those who seem to interpret an extended version of it ("we shouldn't have negative biographies of living persons, even if that really -does- reflect the balance of coverage by reliable sources.")
Pros: I think, no matter which one of the other solutions we choose, we should do this. More than anything, the problem seems to be between those who say "BLP means what the BLP page says it means" and those who say "Well, there's more to it than that." If there is more to it than that, it should lay that out explicitly.
Cons: Such a discussion would probably be a heated, difficult one, as we've seen. However, I think it's necessary, even so-better to have one such discussion than rehash it again and again every time such an issue comes up.
5. Change AfD to default to "delete" if a discussion on a BLP comes out no consensus and the nomination was based on BLP concerns. A clear consensus to keep would be required to keep in such cases.
Pros: This was suggested before, and seemed to have at least a decent degree of support. Could ease some concerns about marginal bios being kept. Leaves the decision in the hands of the community (it just changes what the default is if the community comes to no clear decision).
Cons: Might not be able to achieve a genuine consensus. Could also result in good bios being discarded, especially when (as often happens) an article is greatly improved midway through an AfD, resulting in earlier arguments leaning toward "delete" and later ones toward "keep", and the whole thing coming out with no clear consensus.
That's a start anyway. As I said, any of these may be anywhere from helpful to utterly stupid, but I hope they'll at least be a good starting point for the thought process.
On 5/23/07, Todd Allen toddmallen@gmail.com wrote:
Cons: Might not be able to achieve a genuine consensus. Could also result in good bios being discarded, especially when (as often happens) an article is greatly improved midway through an AfD, resulting in earlier arguments leaning toward "delete" and later ones toward "keep", and the whole thing coming out with no clear consensus.
Anybody who would delete an article after counting votes and disregarding the one user who says "Keep. The article has been improved. The reasons given to delete it are no longer valid." should not be closing AFDs, ever.
—C.W.
On 5/23/07, Charlotte Webb charlottethewebb@gmail.com wrote:
On 5/23/07, Todd Allen toddmallen@gmail.com wrote:
Cons: Might not be able to achieve a genuine consensus. Could also result in good bios being discarded, especially when (as often happens) an article is greatly improved midway through an AfD, resulting in earlier arguments leaning toward "delete" and later ones toward "keep", and the whole thing coming out with no clear consensus.
*Anybody who would delete an article after counting votes and disregarding the one user who says "Keep. The article has been improved. The reasons given to delete it are no longer valid." should not be closing AFDs, ever.*
—C.W.
Thank you. KP
On 24/05/07, Todd Allen toddmallen@gmail.com wrote:
version of it ("we shouldn't have negative biographies of living persons, even if that really -does- reflect the balance of coverage by reliable sources.")
The problem is that having a Wikipedia article about you is in most cases a curse.
That's why we marked AFD "noindex" - for too many people, the first Google hit on them was their Wikipedia AFD.
Just because an article *can* be written doesn't mean one *should*.
This has been a consideration since the introduction of WP:BLP - that page is basically an attempt to reconcile neutrality, verifiability and no original research with not actively fucking up people's lives just because we can.
- d.
On 24/05/07, David Gerard dgerard@gmail.com wrote:
On 24/05/07, Todd Allen toddmallen@gmail.com wrote:
version of it ("we shouldn't have negative biographies of living persons, even if that really -does- reflect the balance of coverage by reliable sources.")
The problem is that having a Wikipedia article about you is in most cases a curse. That's why we marked AFD "noindex" - for too many people, the first Google hit on them was their Wikipedia AFD.
(aaand the devs have already said "wtf, no way" to selective noindexing of pages)
- d.
On 5/23/07, Fred Bauder fredbaud@waterwiki.info wrote:
I think you've won the point, now tell us how you suggest dealing with the problem.
Starters, more admins, but RFA is borked beyond borked, and will until people just fixit and get the RFA trolls out. Next, something simple. The current system works mostly, it just doesn't scale because there aren't enough people to do it. Don't treat BLPs for deletion any different than anything else. If it's a flagrant attack article ("JOE SUCKS, FRED SUCKS, etc") nuke under CSD. For stuff like Crystal Gale, scrub, stub. Leave history for people to work off. Protect, get it rebuilt right. Leave history for a while. Let admins rebuild the shell under protection like Ron Jeremy and that Scientology lady's one was. Once the article is fixed, nuke the original history to clean it up for good.
For DRV, maybe a good idea would be a simple limit: no article by name more than twice per month?
Regards, Joe http://www.joeszilagyi.com
On 5/23/07, Joe Szilagyi szilagyi@gmail.com wrote:
If it's a flagrant attack article ("JOE SUCKS, FRED SUCKS, etc") nuke under CSD. For stuff like Crystal Gale, scrub, stub. Leave history for people to work off.
Indeed, learning to distinguish between these scenarios is the first step.
Protect, get it rebuilt right. Leave history for a while. Let admins rebuild the shell under protection like Ron Jeremy and that Scientology lady's one was. Once the article is fixed, nuke the original history to clean it up for good.
Generally speaking, that would violate the terms of the GFDL, which requires us to maintain documentation of all changes that are made.
Sometimes sloppy workarounds are used, such as pasting a dump of the edit history (really just a list of usernames/IPs, timestamps, and edit summaries) in a prominent location, such as the talk page (this is usually used for pages that get transwikied to another project). This is believed to satisfy our legal requirement to adequately give attribution to all users who contributed to the article.
There are also a practical argument. Back to your [[Joe Szilagyi]] article example. Bob writes an article about you. Alice adds several more paragraphs. Zachary writes "Szilagyi was also one of the hobos on the grassy knoll." Sam fixes some of Alice's typos . John re-writes the third paragraph. Kim writes "lol kimberly was here". Max reverts Kim. Larry adds a paragraph about your guitar collection. Jack removes the grassy knoll bit. Others make more edits.
Robert reads the history and blocks Zachary for "libelous additions to BLP articles". James takes it upon himself to "nuke" all revisions containing the grassy knoll libel
Months later, Zachary says he's been busy in real life and wants to know why he was blocked. Zachary's bad edits have been deleted/oversighted, so nobody can figure it out why he was blocked. Robert can't be contacted because he has quit the project.
Zachary is unblocked and proceeds to disrupt other articles. Fred discovers that the guitar paragraph is bullshit and you've never owned a guitar. He interrogates Jack who now appears to be the one who added the false information. Jack can't easily prove otherwise.
The [[Joe Szilagyi]] article is later included in a popular DVD package. Sam and John, who made good-faith contributions, are justifiably upset for not being credited.
Seriously, there's got to be a better way than this.
—C.W.
On May 24, 2007, at 3:34 AM, Charlotte Webb wrote:
Generally speaking, that would violate the terms of the GFDL, which requires us to maintain documentation of all changes that are made.
Sometimes sloppy workarounds are used, such as pasting a dump of the edit history (really just a list of usernames/IPs, timestamps, and edit summaries) in a prominent location, such as the talk page (this is usually used for pages that get transwikied to another project).
For this reason, I advocate deleting and rewriting from scratch in cases where we feel some significant portion of the history is problematic.
We do have the ability to write an amazing amount of material really really quickly. The feeling that we have to carefully save every word forever is outdated.
--Jimbo
On 5/23/07, Joe Szilagyi szilagyi@gmail.com wrote:
On 5/23/07, Fred Bauder fredbaud@waterwiki.info wrote:
I think you've won the point, now tell us how you suggest dealing with the problem.
Starters, more admins, but RFA is borked beyond borked, and will until people just fixit and get the RFA trolls out.
This last month gives me hope. We've seen a bunch of esentially unopposed successful RFA's nearly in a row; the only major controversies were low-edit-count people and one guy who canvassed his RFA a bit and got bit by it (I actually think he'll make a good admin and hope he's nominated again in a couple of months).