Hi all, in two years of looking for solutions to the BLP issues have finally stumbled upon an idea that hasn't been raised before. Basically it's this: *Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
Best regards, Durova
2009/6/4 Durova nadezhda.durova@gmail.com:
Hi all, in two years of looking for solutions to the BLP issues have finally stumbled upon an idea that hasn't been raised before. Basically it's this: *Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
Best regards, Durova
Been suggested before. Answer is either:
No what search engines do with wikipedia content is none of our business.
No the subjects of articles have no right to determine wikipedia behavior
Of course it could also be argued that effectively making a public record of people who are sensitive about their bios it's exactly an improvement on the current situation.
These policy pages seem to imply otherwise:
http://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons#Presump... "Presumption in favor of privacy"
Wikipedia articles that present material about living people can affect their subjects' lives. Wikipedia editors who deal with these articles have a responsibility to consider the legal and ethical implications of their actions when doing so. It is not Wikipedia's purpose to be sensationalist, or to be the primary vehicle for the spread of titillating claims about people's lives. Biographies of living persons must be written conservatively, with regard for the subject's privacy. http://en.wikipedia.org/wiki/Wikipedia:DEL#Deletion_discussion
"Discussions on relatively unknown, non-public figures, where the subject has requested deletion and there is no rough consensus may be closed as delete."
On Thu, Jun 4, 2009 at 2:40 PM, geni geniice@gmail.com wrote:
2009/6/4 Durova nadezhda.durova@gmail.com:
Hi all, in two years of looking for solutions to the BLP issues have
finally
stumbled upon an idea that hasn't been raised before. Basically it's
this:
*Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
Best regards, Durova
Been suggested before. Answer is either:
No what search engines do with wikipedia content is none of our business.
No the subjects of articles have no right to determine wikipedia behavior
Of course it could also be argued that effectively making a public record of people who are sensitive about their bios it's exactly an improvement on the current situation.
-- geni
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
2009/6/4 Durova nadezhda.durova@gmail.com
Wikipedia articles that present material about living people can affect their subjects' lives.
Trouble is, even if you NOINDEX so it can't find it in google, they could still find it in the wikipedia or via inbound links.
So, although, the proposal could (at best) conceivably improve things, it would ultimately solve nothing.
-----Original Message----- From: Ian Woollard ian.woollard@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 3:32 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
2009/6/4 Durova nadezhda.durova@gmail.com
Wikipedia articles that present material about living people can
affect
their subjects' lives.
Trouble is, even if you NOINDEX so it can't find it in google, they could still find it in the wikipedia or via inbound links.
So, although, the proposal could (at best) conceivably improve things, it would ultimately solve nothing.>>
And I would like to add that anyone could simply repost the information, point at the Wikipedia article as the source, obeying the GFDL considerations effectively eliminating any benefit from Noindex. Which basically is what mirrors accomplish anyhow.
Any mirror can repost any manually crawled content without regard to Noindex. Noindex is not a requirement that anyone is bound to obey.
Will Johnson
Mirrors don't get such high search rank as Wikipedia. Most people who search Google never look past the first 10 entries (if they even scroll down to number 10, which many don't).
Noindexing is a distinct advantage in situations such as job searches or business contract bids where one competitor might stoop to tactically damaging another candidate's biography. Yes, the information remains available, but deliberate misinformation doesn't shoot to the top position instantly.
On Thu, Jun 4, 2009 at 4:22 PM, wjhonson@aol.com wrote:
-----Original Message----- From: Ian Woollard ian.woollard@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 3:32 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
2009/6/4 Durova nadezhda.durova@gmail.com
Wikipedia articles that present material about living people can
affect
their subjects' lives.
Trouble is, even if you NOINDEX so it can't find it in google, they could still find it in the wikipedia or via inbound links.
So, although, the proposal could (at best) conceivably improve things, it would ultimately solve nothing.>>
And I would like to add that anyone could simply repost the information, point at the Wikipedia article as the source, obeying the GFDL considerations effectively eliminating any benefit from Noindex. Which basically is what mirrors accomplish anyhow.
Any mirror can repost any manually crawled content without regard to Noindex. Noindex is not a requirement that anyone is bound to obey.
Will Johnson
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-----Original Message----- From: Durova nadezhda.durova@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 4:33 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
Mirrors don't get such high search rank as Wikipedia. Most people who search Google never look past the first 10 entries (if they even scroll down to number 10, which many don't).
Noindexing is a distinct advantage in situations such as job searches or business contract bids where one competitor might stoop to tactically damaging another candidate's biography. Yes, the information remains available, but deliberate misinformation doesn't shoot to the top position instantly.>> ---------------------------------------------
If you noindex, then Wikipedia's entry doesn't appear at all. Some of our mirrors do have relatively high rankings, appearing on the first page. This is especially true of the more comprehensive, but obscure entries. Such as you might find say, with a University professor or second-tier author. We write up a full biography, noindex it, and our mirrors end up on the first page of Google hits.
I fail to see the actual damage caused. Competitors already try to damage each other, if bids are based on Wikipedia entries, then it's doubtful that the businesses are really doing any sort of due diligence in the first place. All businesses have complaints lodged against them. If you don't have at least a few detractors, then you must have just started.
I'd like to see some concrete examples of real damage, before such a sweeping modification is instituted.
Will Johnson
Obviously the bids don't cite Wikipedia. It's not uncommon, though, for the decision maker to run a quick Google search. Now if exploitation is going to happen, Wikipedia happens to be one of the easiest platforms to exploit. Wikipedians try to manage our BLP problems, but very often we fail. Do we shrug off legitimate complaints as easily as you advise? Perhaps this is a philosophical/ethical difference. I say we look for solutions.
On Thu, Jun 4, 2009 at 4:40 PM, wjhonson@aol.com wrote:
-----Original Message----- From: Durova nadezhda.durova@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 4:33 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
Mirrors don't get such high search rank as Wikipedia. Most people who search Google never look past the first 10 entries (if they even scroll down to number 10, which many don't).
Noindexing is a distinct advantage in situations such as job searches or business contract bids where one competitor might stoop to tactically damaging another candidate's biography. Yes, the information remains available, but deliberate misinformation doesn't shoot to the top position instantly.>>
If you noindex, then Wikipedia's entry doesn't appear at all. Some of our mirrors do have relatively high rankings, appearing on the first page. This is especially true of the more comprehensive, but obscure entries. Such as you might find say, with a University professor or second-tier author. We write up a full biography, noindex it, and our mirrors end up on the first page of Google hits.
I fail to see the actual damage caused. Competitors already try to damage each other, if bids are based on Wikipedia entries, then it's doubtful that the businesses are really doing any sort of due diligence in the first place. All businesses have complaints lodged against them. If you don't have at least a few detractors, then you must have just started.
I'd like to see some concrete examples of real damage, before such a sweeping modification is instituted.
Will Johnson
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-----Original Message----- From: Durova nadezhda.durova@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 4:55 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
Obviously the bids don't cite Wikipedia. It's not uncommon, though, for the decision maker to run a quick Google search. Now if exploitation is going to happen, Wikipedia happens to be one of the easiest platforms to exploit. Wikipedians try to manage our BLP problems, but very often we fail. Do we shrug off legitimate complaints as easily as you advise? Perhaps this is a philosophical/ethical difference. I say we look for solutions.>> ---------------------
I do not disagree that we should look for solutions. I just believe those solutions are on a case-by-case basis, and specific to the case involved, not general and sweeping.
Will Johnson
2009/6/5 Durova nadezhda.durova@gmail.com:
Obviously the bids don't cite Wikipedia. It's not uncommon, though, for the decision maker to run a quick Google search. Now if exploitation is going to happen, Wikipedia happens to be one of the easiest platforms to exploit. Wikipedians try to manage our BLP problems, but very often we fail. Do we shrug off legitimate complaints as easily as you advise? Perhaps this is a philosophical/ethical difference. I say we look for solutions.
I say you still haven't provided an example of the problem.
- f.
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Rand_Fishkin
One of several BLPs I've nominated for deletion upon request from the subject. He's notable basically for two things: owning a business and having proposed to his wife at a professional sporting event.
When he first discovered someone had created a biography on Wikipedia he was flattered. After a few months, though, it became burdensome to check every week and see whether it had been altered. He began to worry--since his business is a service industry--what would happen if one of his competitors vandalized it strategically while he competed for a contract.
He wasn't famous enough to be on many watchlists. If the vandalism occurred the day after he checked the page it'd be six days more before he spotted it, and longer while OTRS processed his request. In that time, would a potential client be misled? Would he lose out on a contract and have to lay off good employees? Overall it simply wasn't worth it.
This was one biography that got deleted upon request; many others don't. And that's partly because of opinions that have appeared in this thread: *Some Wikipedians believe that the subject of a BLP should never have a voice in editorial decisions at all. *Some Wikipedians argue that it's easy enough to Googlebomb people by other means, so Wikipedia shouldn't erect any barriers either. *Other Wikipedians believe every instance should be handled "case by case", which means we can never give a simple and direct answer to a BLP subject who raises legitimate concerns.
I don't like *any* of those solutions. When I call the phone company with a complaint about my bill, I want to know what the rules are in plain English--I want an outcome that's understandable and consistent. And even if the answer is no, I want a simple plain and direct no.
There's no excuse for giving another human being the run-around when we can prevent it.
On Thu, Jun 4, 2009 at 5:02 PM, David Gerard dgerard@gmail.com wrote:
2009/6/5 Durova nadezhda.durova@gmail.com:
Obviously the bids don't cite Wikipedia. It's not uncommon, though, for
the
decision maker to run a quick Google search. Now if exploitation is
going
to happen, Wikipedia happens to be one of the easiest platforms to
exploit.
Wikipedians try to manage our BLP problems, but very often we fail. Do
we
shrug off legitimate complaints as easily as you advise? Perhaps this is
a
philosophical/ethical difference. I say we look for solutions.
I say you still haven't provided an example of the problem.
- f.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-----Original Message----- From: Durova nadezhda.durova@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 5:16 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Rand_Fishkin
One of several BLPs I've nominated for deletion upon request from the subject. He's notable basically for two things: owning a business and having proposed to his wife at a professional sporting event.
When he first discovered someone had created a biography on Wikipedia he was flattered. After a few months, though, it became burdensome to check every week and see whether it had been altered. He began to worry--since his business is a service industry--what would happen if one of his competitors vandalized it strategically while he competed for a contract.
He wasn't famous enough to be on many watchlists. If the vandalism occurred the day after he checked the page it'd be six days more before he spotted it, and longer while OTRS processed his request. In that time, would a potential client be misled? Would he lose out on a contract and have to lay off good employees? Overall it simply wasn't worth it.
This was one biography that got deleted upon request; many others don't. And that's partly because of opinions that have appeared in this thread: *Some Wikipedians believe that the subject of a BLP should never have a voice in editorial decisions at all. *Some Wikipedians argue that it's easy enough to Googlebomb people by other means, so Wikipedia shouldn't erect any barriers either. *Other Wikipedians believe every instance should be handled "case by case", which means we can never give a simple and direct answer to a BLP subject who raises legitimate concerns.
I don't like *any* of those solutions. When I call the phone company with a complaint about my bill, I want to know what the rules are in plain English--I want an outcome that's understandable and consistent. And even if the answer is no, I want a simple plain and direct no.>>
--------------
That's a bit evasive. Your example was handled the way you think it should be, so where is the problem? You say there are other examples where this didn't happen. What are they?
The rules are clear. The outcomes are not clear. This is because we write imperfect rules. They don't cover every single case, nor should they.
That is why we're asking for examples where you think the outcome *does not* represent what you think it should have.
His bio was not deleted because he asked for it to be. That's not the entirely of what occurred. We do allow subjects to speak on their bios. We do it all the time. We just don't allow them to have veto power.
Will
On Thu, Jun 4, 2009 at 19:16, Durova nadezhda.durova@gmail.com wrote:
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Rand_FishkinIf the vandalism occurred the day after he checked the page it'd be six days more before he spotted it, and longer while OTRS processed his request.
...but under your proposal OTRS would be the ones handling the noindex request.
As several others have mentioned, noindexing won't prevent vandalism, won't prevent mirrors from showing the hidden content, and won't prevent direct visits to the hidden content. Additionally, as I mentioned in a comment on your blog, most BLP-related complaints on OTRS are more concerned with the vandalism itself or with the wiki-nature in general - Google doesn't really enter the picture unless their cache is outdated.
I'm always eager to hear new ideas on keeping BLPs neutral, but I'm afraid this one won't cut it. Sorry.
On Jun 5, 2009, at 9:47 AM, Jim Redmond wrote:
As several others have mentioned, noindexing won't prevent vandalism, won't prevent mirrors from showing the hidden content, and won't prevent direct visits to the hidden content.
Pardon the dumb question, but do we have a "{{nomirror}}" or similar feature? If so, some combination of {{noindex}}, {{nomirror}}, and flagged revisions might be a temporary panacea...
Philippe
Perhaps I should have thought of this example sooner: one extreme instance that comes to mind is the following biography:
http://en.wikipedia.org/wiki/Matt_Sanchez
Which was nominated for deletion three times and kept: http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Matt_Sanchez http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Matt_Sanchez_(2...) http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Matt_Sanchez_(3...)
and caused an arbitration case: http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Bluemarine
The biography subject was the target of a long term harassment and impersonation campaign across multiple sites on the Internet, which spilled over onto Wikipedia, and during the arbitration that harassment culminated in his computer getting hacked and his bank account getting emptied. The offsite harassment continues, although fortunately (after about two years of volunteer effort) its effects on Wikipedia have been minimized.
The subject himself is no boy scout. When he gained attention a ghost from his closet emerged, and his attempts to deal with the resulting problems at Wikipedia were so counterproductive that he got sitebanned. Wjhonson (who posts actively to this list) was also active in that dispute and our perspectives on it differed, so I hope this amounts to a brief neutral summary. For purposes of this thread, that's background. Here's the substance:
BLP vandalism at Wikipedia is not all random one-offs. It also consists of persistent or strategic damage. Wikipedia does a much poorer job at handling the latter problems.
In this instance the article subject was completing his education and looking for work while Wikipedia's article persistently violated BLP, RS, V, and NPOV. A series of experienced volunteers were unable to resolve the problems without arbitration. The net result was two editors sitebanned, one indefinitely blocked, and another topic banned.
Looking back on that long ordeal, that dispute might not have grown so long and bitter if it were possible to noindex that BLP while the problems were getting addressed.
-Lise
Now as an act of good faith I'm going to offer to initiate a request to have that topic ban lifted. It's been about a year and the editor otherwise had a good onsite record.
On Fri, Jun 5, 2009 at 10:47 AM, philippe philippe.wiki@gmail.com wrote:
On Jun 5, 2009, at 9:47 AM, Jim Redmond wrote:
As several others have mentioned, noindexing won't prevent vandalism, won't prevent mirrors from showing the hidden content, and won't prevent direct visits to the hidden content.
Pardon the dumb question, but do we have a "{{nomirror}}" or similar feature? If so, some combination of {{noindex}}, {{nomirror}}, and flagged revisions might be a temporary panacea...
Philippe
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Fri, 5 Jun 2009, Jim Redmond wrote:
As several others have mentioned, noindexing won't prevent vandalism, won't prevent mirrors from showing the hidden content, and won't prevent direct visits to the hidden content. Additionally, as I mentioned in a comment on your blog, most BLP-related complaints on OTRS are more concerned with the vandalism itself or with the wiki-nature in general - Google doesn't really enter the picture unless their cache is outdated.
The Google problem usually shows up in situations where it's hard to prove-- prospective employer Googles subject, turns up inaccurate Wikipedia article about subject, rejects subject for job without ever mentioning the Wikipedia article.
2009/6/4 Durova nadezhda.durova@gmail.com:
These policy pages seem to imply otherwise:
The BLP policy page is a broken mess of pseudo policy written by people looking to forward their positions.
It has no place in rational discussion of the BLP issue.
On Thu, Jun 4, 2009 at 3:34 PM, geni geniice@gmail.com wrote:
The BLP policy page is a broken mess of pseudo policy written by people looking to forward their positions. It has no place in rational discussion of the BLP issue.
If you were motivated to do so, how would you go about fixing it?
OT: BTW, how are those "replace this image" things working out?
-Steven
2009/6/5 stevertigo stvrtg@gmail.com:
On Thu, Jun 4, 2009 at 3:34 PM, geni geniice@gmail.com wrote:
The BLP policy page is a broken mess of pseudo policy written by people looking to forward their positions. It has no place in rational discussion of the BLP issue.
If you were motivated to do so, how would you go about fixing it?
It can be fixed until we can get an agreement on what BLP should actually be doing. Once that is done w can make progress.
OT: BTW, how are those "replace this image" things working out?
Pretty much dead
1. We exist in the real world, where about 15% of WP traffic comes from search engines. We cannot operate in ignorance of how they operate. The NOINDEX mechanism was devised specifically to permit control of the interface: we decide what they are permitted to crawl, and they respect it. There is no reason to refrain from using it. There are more intrusive ways they control our behavior. They emphasize the words in the titles, & perhaps especially the beginnings of the titles, and we let this affect how we title the BLPs. Tellingthem what to index is not their affecting our beahvior, but us affecting theirs'.
2. Much better letting people control the external indexing, than control the content. I have always strongly objected to letting subjects have a say on whether or not there should be an article, but in comparison, this is harmless.
A more substantial problem is that BLP appears elsewhere than in biographical articles, and biographical articles cover persons other than the primary subject.
David Goodman, Ph.D, M.L.S. http://en.wikipedia.org/wiki/User_talk:DGG
On Thu, Jun 4, 2009 at 5:40 PM, geni geniice@gmail.com wrote:
2009/6/4 Durova nadezhda.durova@gmail.com:
Hi all, in two years of looking for solutions to the BLP issues have finally stumbled upon an idea that hasn't been raised before. Basically it's this: *Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
Best regards, Durova
Been suggested before. Answer is either:
No what search engines do with wikipedia content is none of our business.
No the subjects of articles have no right to determine wikipedia behavior
Of course it could also be argued that effectively making a public record of people who are sensitive about their bios it's exactly an improvement on the current situation.
-- geni
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
2009/6/4 David Goodman dgoodmanny@gmail.com:
- We exist in the real world, where about 15% of WP traffic comes
from search engines. We cannot operate in ignorance of how they operate. The NOINDEX mechanism was devised specifically to permit control of the interface: we decide what they are permitted to crawl, and they respect it. There is no reason to refrain from using it. There are more intrusive ways they control our behavior. They emphasize the words in the titles, & perhaps especially the beginnings of the titles, and we let this affect how we title the BLPs. Tellingthem what to index is not their affecting our beahvior, but us affecting theirs'.
The problem with trying that line of argument is that if we admit that we are actively hiding stuff from search engines with the express intention of prevention them from hiding it we are censoring information.
- Much better letting people control the external indexing, than
control the content. I have always strongly objected to letting subjects have a say on whether or not there should be an article, but in comparison, this is harmless.
Nope you rejected the harmless position in your argument above. Since you took the position that we should consider what search engines do you are now advocating that wikipedia abandon the core part of it's mission of making information widely available.
On Fri, Jun 5, 2009 at 6:59 AM, Durovanadezhda.durova@gmail.com wrote:
*Suppose we noindexed biographies of living persons, upon the subject's request.*
As has been already mentioned, this has all been discussed before, but:
NOINDEXing BLPs does nothing to stop vandalism of them. All it can hope to do is sweep it under the rug, which is exactly the wrong thing to do, as vandalism can only be fixed once it has been noticed. The Siegenthaler incident was so bad because the vandalism went unnoticed (or at least, uncorrected) for so long.
On Fri, Jun 5, 2009 at 8:26 AM, Durovanadezhda.durova@gmail.com wrote:
http://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons#Presump... "Presumption in favor of privacy"
Those ideas are about what types of content are accepted into BLPs (and what types of sources are used), and under what circumstances will we have or not have a BLP. Anyone who cares about these issues should put their efforts into working on those ideas, as well as on ideas about improving dealing with vandalism as it happens, instead of working towards futile obfuscation.
Incidentally, NOINDEXing requires no developer assistance:
http://en.wikipedia.org/wiki/Template:NOINDEX
The proposal is to noindex upon the subject's request. Isn't it best to let the people who live with the consequences weigh those pros and cons? If the main thing they want is to get Wikipedia off the top Google result, then it may be worth it to them. On principle, I'm not keen on paternalism.
On Thu, Jun 4, 2009 at 5:38 PM, Stephen Bain stephen.bain@gmail.com wrote:
On Fri, Jun 5, 2009 at 6:59 AM, Durovanadezhda.durova@gmail.com wrote:
*Suppose we noindexed biographies of living persons, upon the subject's request.*
As has been already mentioned, this has all been discussed before, but:
NOINDEXing BLPs does nothing to stop vandalism of them. All it can hope to do is sweep it under the rug, which is exactly the wrong thing to do, as vandalism can only be fixed once it has been noticed. The Siegenthaler incident was so bad because the vandalism went unnoticed (or at least, uncorrected) for so long.
On Fri, Jun 5, 2009 at 8:26 AM, Durovanadezhda.durova@gmail.com wrote:
http://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons#Presump...
"Presumption in favor of privacy"
Those ideas are about what types of content are accepted into BLPs (and what types of sources are used), and under what circumstances will we have or not have a BLP. Anyone who cares about these issues should put their efforts into working on those ideas, as well as on ideas about improving dealing with vandalism as it happens, instead of working towards futile obfuscation.
Incidentally, NOINDEXing requires no developer assistance:
http://en.wikipedia.org/wiki/Template:NOINDEX
-- Stephen Bain stephen.bain@gmail.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Fri, Jun 5, 2009 at 10:43 AM, Durovanadezhda.durova@gmail.com wrote:
The proposal is to noindex upon the subject's request. Isn't it best to let the people who live with the consequences weigh those pros and cons? If the main thing they want is to get Wikipedia off the top Google result, then it may be worth it to them. On principle, I'm not keen on paternalism.
My concern is editors wasting their time and effort offering placebos when there is medicine to be made.
Penicillin may be great for strep throat, but that's no argument against chicken soup. Especially when the pharmacy's supply of penicillin is in back order. ;)
On Thu, Jun 4, 2009 at 5:45 PM, Stephen Bain stephen.bain@gmail.com wrote:
On Fri, Jun 5, 2009 at 10:43 AM, Durovanadezhda.durova@gmail.com wrote:
The proposal is to noindex upon the subject's request. Isn't it best to
let
the people who live with the consequences weigh those pros and cons? If
the
main thing they want is to get Wikipedia off the top Google result, then
it
may be worth it to them. On principle, I'm not keen on paternalism.
My concern is editors wasting their time and effort offering placebos when there is medicine to be made.
-- Stephen Bain stephen.bain@gmail.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
So far as I am aware, they already can add {{NOINDEX}} to the article and it will, if nobody else reverts the edit disappear from google.
I must confess that I don't think it fixes anything worth fixing though.
2009/6/5 Durova nadezhda.durova@gmail.com
The proposal is to noindex upon the subject's request. Isn't it best to let the people who live with the consequences weigh those pros and cons? If the main thing they want is to get Wikipedia off the top Google result, then it may be worth it to them. On principle, I'm not keen on paternalism.
On Thu, Jun 4, 2009 at 5:38 PM, Stephen Bain stephen.bain@gmail.com wrote:
On Fri, Jun 5, 2009 at 6:59 AM, Durovanadezhda.durova@gmail.com wrote:
*Suppose we noindexed biographies of living persons, upon the subject's request.*
As has been already mentioned, this has all been discussed before, but:
NOINDEXing BLPs does nothing to stop vandalism of them. All it can hope to do is sweep it under the rug, which is exactly the wrong thing to do, as vandalism can only be fixed once it has been noticed. The Siegenthaler incident was so bad because the vandalism went unnoticed (or at least, uncorrected) for so long.
On Fri, Jun 5, 2009 at 8:26 AM, Durovanadezhda.durova@gmail.com wrote:
http://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons#Presump...
"Presumption in favor of privacy"
Those ideas are about what types of content are accepted into BLPs (and what types of sources are used), and under what circumstances will we have or not have a BLP. Anyone who cares about these issues should put their efforts into working on those ideas, as well as on ideas about improving dealing with vandalism as it happens, instead of working towards futile obfuscation.
Incidentally, NOINDEXing requires no developer assistance:
http://en.wikipedia.org/wiki/Template:NOINDEX
-- Stephen Bain stephen.bain@gmail.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- http://durova.blogspot.com/ _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-----Original Message----- From: Durova nadezhda.durova@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, 4 Jun 2009 5:43 pm Subject: Re: [WikiEN-l] A new solution for the BLP dilemma
The proposal is to noindex upon the subject's request. Isn't it best to let the people who live with the consequences weigh those pros and cons? If the main thing they want is to get Wikipedia off the top Google result, then it may be worth it to them. On principle, I'm not keen on paternalism.>>
President Obama has asked us to noindex his page. Do we do it? I'm hoping that you will agree that we do not.
Will Johnson
On Fri, Jun 5, 2009 at 6:59 AM, Durovanadezhda.durova@gmail.com wrote:
Hi all, in two years of looking for solutions to the BLP issues have finally stumbled upon an idea that hasn't been raised before. Basically it's this: *Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
This has been considered before:
http://en.wikipedia.org/wiki/User_talk:Cool_Hand_Luke/Archive_8#Preemptive_e...
A WR thread largely about it:
http://wikipediareview.com/index.php?showtopic=23060
And a wiki proposal about the general problem domain:
http://en.wikipedia.org/wiki/Wikipedia:Search_engine_indexing
On Fri, Jun 5, 2009 at 10:38 AM, Stephen Bainstephen.bain@gmail.com wrote:
Incidentally, NOINDEXing requires no developer assistance:
That template does not work on mainspace. Specifically my comment here:
http://wikipediareview.com/index.php?showtopic=23060&st=20&p=157928&...
For those that don't want to go to WR, roughly quoting my post:
The code is here
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/OutputPage.p...
It says:
if( is_null( $wgExemptFromUserRobotsControl ) ) { $bannedNamespaces = $wgContentNamespaces; } else { $bannedNamespaces = $wgExemptFromUserRobotsControl; }
The settings are
'wgContentNamespaces' => array( 'default' => array( 0 ), ... ),
However $wgExemptFromUserRobotsControl is not defined. Theoretically, we could ask the devs to add
'wgExemptFromUserRobotsControl' => array( 'enwiki' => array () )
That would effectively mean there no namespace is exempt from user control, and the NOINDEX in db-spam and db-attack would start working.
--
If we do allow user control of mainspace, a dedicated categories could track them, and I am sure there will be many folk policing them to ensure that the article meet the conditions.
At the same time as the WR discussion, there was some onwiki discussion on improving the template, and some suggestions were implemented.
http://en.wikipedia.org/wiki/Template_talk:NOINDEX
-- John Vandenberg
On Fri, Jun 5, 2009 at 1:38 AM, Stephen Bainstephen.bain@gmail.com wrote:
<snip>
Incidentally, NOINDEXing requires no developer assistance:
One good use of the NOINDEX template, IMO, is to hide userfied drafts of BLP articles. When undeleting an article and placing it in userspace, a NOINDEX template should be used if the article is a BLP.
Carcharoth
Okay, if I hav this straight, then wikipedia should not index the article, either. In other words, you would not find some people from their family name or stage name, unless they issue some form of approval. Those who are interested in getting their facts acceptable would know exactly where the article is, so they can keep working on it, and links to the subject from categories and from other articles would not function: You would still be able to get there if you type out the URL. The noindex and nofollow directives in a robots.txt file (and something like them on each web page in meta tags) are nearly standard, because some people want to keep their writing projects under the scrutiny of a few friends before any spider finds it.
A simpler option would be password-protecting an article, along with the names of people who can offer the password. Once you explain your purpose, you should be able to get the password by e-mail. There was once a popular disclaimer on web pages "Under Construction". It is almost certainly still around, because it is the nature of the web to provide volatile information or incorporate feedback.
So, the protection levels for an article COULD be: Deleted -- Subject made application to oversight committee. Protected -- sysop only. Moderated -- Edits go through moderators; identical to proxied edits. Password protected -- Primarily for biography under construction. Not Indexed -- Hard, and not impossible to find -- fails approval from subject. Semi-protected -- Contentious subjects demand a degree of identification. Open -- Not a debatable topic. (So far, nobody is trying to tell user:cluebot that wikipedia is not censored) _______ Yo momma so fat she had to go to Sea World to get baptized
"Durova" nadezhda.durova@gmail.com wrote in message news:a01006d90906041359p5465d053w10bdd7fffb71aa01@mail.gmail.com...
Hi all, in two years of looking for solutions to the BLP issues have finally stumbled upon an idea that hasn't been raised before. Basically it's this: *Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
Best regards, Durova -- http://durova.blogspot.com/ _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Um, that's an attempt at humor right?
On Thu, Jun 4, 2009 at 10:48 PM, Jay Litwyn <brewhaha@freenet.edmonton.ab.ca
wrote:
Okay, if I hav this straight, then wikipedia should not index the article, either. In other words, you would not find some people from their family name or stage name, unless they issue some form of approval. Those who are interested in getting their facts acceptable would know exactly where the article is, so they can keep working on it, and links to the subject from categories and from other articles would not function: You would still be able to get there if you type out the URL. The noindex and nofollow directives in a robots.txt file (and something like them on each web page in meta tags) are nearly standard, because some people want to keep their writing projects under the scrutiny of a few friends before any spider finds it.
A simpler option would be password-protecting an article, along with the names of people who can offer the password. Once you explain your purpose, you should be able to get the password by e-mail. There was once a popular disclaimer on web pages "Under Construction". It is almost certainly still around, because it is the nature of the web to provide volatile information or incorporate feedback.
So, the protection levels for an article COULD be: Deleted -- Subject made application to oversight committee. Protected -- sysop only. Moderated -- Edits go through moderators; identical to proxied edits. Password protected -- Primarily for biography under construction. Not Indexed -- Hard, and not impossible to find -- fails approval from subject. Semi-protected -- Contentious subjects demand a degree of identification. Open -- Not a debatable topic. (So far, nobody is trying to tell user:cluebot that wikipedia is not censored) _______ Yo momma so fat she had to go to Sea World to get baptized
"Durova" nadezhda.durova@gmail.com wrote in message news:a01006d90906041359p5465d053w10bdd7fffb71aa01@mail.gmail.com...
Hi all, in two years of looking for solutions to the BLP issues have finally stumbled upon an idea that hasn't been raised before. Basically it's
this:
*Suppose we noindexed biographies of living persons, upon the subject's request.* This would require developer assistance, and require a bit of structure to make sure the ability doesn't get misused. An initial draft proposal is at my blog. Am interested in thoughts and suggestions.
http://durova.blogspot.com/2009/06/biographies-of-living-persons-ingenius.ht...
Best regards, Durova -- http://durova.blogspot.com/ _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
That proposal isn't one that I'm comfortable wit. It seems to encourage sweeping problematic BLPs under the carpet by reducing the probability that they'll be viewed. I'd rather we rolled up our sleeves and strategically tackled troublesome content. Perhaps enabling flagged revisions for BLPs as an interim step, until we get on top of the problem, would be useful.
AGK
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control: R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become authorized and get a special stamp of approval from the subject of the biography. Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits everyone to write to it. An edit war breaks out, so the sysop (sysops always hav power to permit, as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress. No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by reading three months of history.
The idea of restricting asrticle writing to a small group ("experienced article writers" "admins" "veterans" "blp specialists endorsed by the community") has been raised before. In principle if the group is made large enough to not be owned by some small clique and with a suitable policy guiding how it works and its responsiveness, it's viable without undermining NPOV and openness.
The crunch point is "open to editing by all", and a large number of users take that aspect seriously and literally. Philosophically once "open to all" is drawn back, the same logic applies to any type of article where a person or group might be unhappy with editing, and there's also a risk that groups once created tend to gravitate to their own internally developed norms or to become slightly separated.
Open editing is a major safeguard against Wikipedia being able to be monopolized by some special interest group, or affected by censorship of some minority or externally imposed stance. Add a means to limit article control to some group, and there's always a risk it can be used in future in other ways.....
Not agreeing or disagreeing, more just outlining the perceived pros cons and issues.
FT2
On Tue, Jul 21, 2009 at 4:05 AM, Jay Litwyn <brewhaha@freenet.edmonton.ab.ca
wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control: R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become authorized and get a special stamp of approval from the subject of the biography. Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits everyone to write to it. An edit war breaks out, so the sysop (sysops always hav power to permit, as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress. No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by reading three months of history. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
In brief, any solution that narrows down how articles are edited, needs to consider extremely carefully whether it truly keeps article writing open to "the world" -- ie
- any good faith editor may contribute to articles with as few exceptions and restrictions as possible - good faith editors with different views can stand as "equal editors" in the discussion - censorship is kept "difficult" under the new method (no "bottleneck" that makes it easy for a minority view to apply control) - the potential for the editorial environment of these articles to diverge over time from the project's general community environment is low (would tend to keep community aligned, porous, and with widely accepted norms)
FT2
On Wed, Jul 22, 2009 at 1:39 PM, FT2 ft2.wiki@gmail.com wrote:
The idea of restricting asrticle writing to a small group ("experienced article writers" "admins" "veterans" "blp specialists endorsed by the community") has been raised before. In principle if the group is made large enough to not be owned by some small clique and with a suitable policy guiding how it works and its responsiveness, it's viable without undermining NPOV and openness.
The crunch point is "open to editing by all", and a large number of users take that aspect seriously and literally. Philosophically once "open to all" is drawn back, the same logic applies to any type of article where a person or group might be unhappy with editing, and there's also a risk that groups once created tend to gravitate to their own internally developed norms or to become slightly separated.
Open editing is a major safeguard against Wikipedia being able to be monopolized by some special interest group, or affected by censorship of some minority or externally imposed stance. Add a means to limit article control to some group, and there's always a risk it can be used in future in other ways.....
Not agreeing or disagreeing, more just outlining the perceived pros cons and issues.
FT2
On Tue, Jul 21, 2009 at 4:05 AM, Jay Litwyn < brewhaha@freenet.edmonton.ab.ca> wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control: R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become authorized and get a special stamp of approval from the subject of the biography. Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits everyone to write to it. An edit war breaks out, so the sysop (sysops always hav power to permit, as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress. No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by reading three months of history. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
The way I look at it, there already is one in group, and one out. Admins can theoretically read and write anything. Other users can block creations with {{db-nonsense}}, and only admins can over-ride the decision. Keep in mind that BLP is a specific issue, and one that Wales said we should moderate. So, perhaps admins should be told that moderation should never be done in haste. For the vast majority of articles, comments about current events in politics on [[coliseum]] would be normal. For high-traffic articles in sex, such comments would be downright mind-numbing. In BLP, though, an admin raises a "Flags" tab on the page and enables write access for group, then disables it for EveryOneElse -- at the first edit war (or anything like it). That is how it is with semi-protected, already -- no IP#s. My proposal would hav more groups created. There could be a bot-approved application process to be a group member in quiz form -- you can't get in until you get 100%. If you do not know, then you ask somebody who does, because it's a pass or fail test with no score. The objective is to reduce actions like blocks, which is about the fourth group that already exists in [[category:blocked users that are not dicks]].
My rule for sporadic moderation on USENET is only "If it sells something and it does not relate to the group, then ask (probably abuse@groups.google.com) for it to be deleted". I gather that it is more complicated, here. ________ Clarke's Third Law: Any sufficiently advanced technology is indistinguishable from magic.
"FT2" ft2.wiki@gmail.com wrote in message news:e71d9fab0907220539v256537e7we70cf4ff7570f43e@mail.gmail.com...
The idea of restricting asrticle writing to a small group ("experienced article writers" "admins" "veterans" "blp specialists endorsed by the community") has been raised before. In principle if the group is made large enough to not be owned by some small clique and with a suitable policy guiding how it works and its responsiveness, it's viable without undermining NPOV and openness.
The crunch point is "open to editing by all", and a large number of users take that aspect seriously and literally. Philosophically once "open to all" is drawn back, the same logic applies to any type of article where a person or group might be unhappy with editing, and there's also a risk that groups once created tend to gravitate to their own internally developed norms or to become slightly separated.
Open editing is a major safeguard against Wikipedia being able to be monopolized by some special interest group, or affected by censorship of some minority or externally imposed stance. Add a means to limit article control to some group, and there's always a risk it can be used in future in other ways.....
Not agreeing or disagreeing, more just outlining the perceived pros cons and issues.
FT2
On Tue, Jul 21, 2009 at 4:05 AM, Jay Litwyn <brewhaha@freenet.edmonton.ab.ca
wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control: R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become authorized and get a special stamp of approval from the subject of the biography. Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits everyone to write to it. An edit war breaks out, so the sysop (sysops always hav power to permit, as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress. No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by reading three months of history. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
OK - so I think a fair summary of this proposal (correct me if I'm wrong) is: We should create a group of experienced BLP editors (or similar) to edit a BLP that has been the subject of an edit war. The page would be protected from editing by other (non-sysop) users. This would form an alternative to or replacement for page protection, and would hopefully lead to more editing than page protection. We should also allow users to create draft articles in their userspace that are (by default) protected from editing by other non-sysops.
I share FT2's concerns about the need to avoid creating a BLP cabal with the first point, and I also have concerns about the second point - it could lead to POV forks and encourage people to hide an imperfect article in their userspace rather than it being more visible and publically editable, which will lead to faster improvement. It could also lead to greater feelings of article ownership - if you grew an article to (say) A-class in your userspace before moving it to article space you'll probably have greater feelings of ownership than if it was in publically editablearticlespace from the start.
On Tue, Jul 21, 2009 at 04:05, Jay Litwynbrewhaha@freenet.edmonton.ab.ca wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control: R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become authorized and get a special stamp of approval from the subject of the biography. Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits everyone to write to it. An edit war breaks out, so the sysop (sysops always hav power to permit, as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress. No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by reading three months of history. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
I have had an idea how we could help resolve POV and sourcing wars, that would fit very well with Wikipedia philosophy. I might dust it off some time. The mood in the community is such that few proposals are welcomed by sufficient users to get accepted, and at the same time the problems persist and are critiqued.
Anyone else notice that?
FT2
On Wed, Jul 22, 2009 at 3:00 PM, Jonathan Hall sinewave@silentflame.comwrote:
OK - so I think a fair summary of this proposal (correct me if I'm wrong) is: We should create a group of experienced BLP editors (or similar) to edit a BLP that has been the subject of an edit war. The page would be protected from editing by other (non-sysop) users. This would form an alternative to or replacement for page protection, and would hopefully lead to more editing than page protection. We should also allow users to create draft articles in their userspace that are (by default) protected from editing by other non-sysops.
I share FT2's concerns about the need to avoid creating a BLP cabal with the first point, and I also have concerns about the second point
- it could lead to POV forks and encourage people to hide an imperfect
article in their userspace rather than it being more visible and publically editable, which will lead to faster improvement. It could also lead to greater feelings of article ownership - if you grew an article to (say) A-class in your userspace before moving it to article space you'll probably have greater feelings of ownership than if it was in publically editablearticlespace from the start.
On Tue, Jul 21, 2009 at 04:05, Jay Litwynbrewhaha@freenet.edmonton.ab.ca wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a
preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control:
R W P e r e a i r d t m e i tOwner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only
one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows
does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become
authorized and get a special stamp of approval from the subject of the biography.
Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits
everyone to write to it.
An edit war breaks out, so the sysop (sysops always hav power to permit,
as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress.
No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by
reading three months of history.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- 1001010 1001000110000111011001101100
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Maybe the ideas aren't good enough? :-)
Carcharoth
On Wed, Jul 22, 2009 at 5:04 PM, FT2ft2.wiki@gmail.com wrote:
I have had an idea how we could help resolve POV and sourcing wars, that would fit very well with Wikipedia philosophy. I might dust it off some time. The mood in the community is such that few proposals are welcomed by sufficient users to get accepted, and at the same time the problems persist and are critiqued.
Anyone else notice that?
FT2
On Wed, Jul 22, 2009 at 3:00 PM, Jonathan Hall sinewave@silentflame.comwrote:
OK - so I think a fair summary of this proposal (correct me if I'm wrong) is: We should create a group of experienced BLP editors (or similar) to edit a BLP that has been the subject of an edit war. The page would be protected from editing by other (non-sysop) users. This would form an alternative to or replacement for page protection, and would hopefully lead to more editing than page protection. We should also allow users to create draft articles in their userspace that are (by default) protected from editing by other non-sysops.
I share FT2's concerns about the need to avoid creating a BLP cabal with the first point, and I also have concerns about the second point
- it could lead to POV forks and encourage people to hide an imperfect
article in their userspace rather than it being more visible and publically editable, which will lead to faster improvement. It could also lead to greater feelings of article ownership - if you grew an article to (say) A-class in your userspace before moving it to article space you'll probably have greater feelings of ownership than if it was in publically editablearticlespace from the start.
On Tue, Jul 21, 2009 at 04:05, Jay Litwynbrewhaha@freenet.edmonton.ab.ca wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a
preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control:
R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only
one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows
does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become
authorized and get a special stamp of approval from the subject of the biography.
Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits
everyone to write to it.
An edit war breaks out, so the sysop (sysops always hav power to permit,
as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress.
No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by
reading three months of history.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- 1001010 1001000110000111011001101100
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Maybe. But innovation is no bad thing, and if a disproportionate number of ideas are rejected too early rather than explored or trialled, perhaps some that would find value will be lost.
It's easy to forget that a wide range of processes and tools we take for granted today started off being considered questionable at their proposal.
FT2
On Wed, Jul 22, 2009 at 5:15 PM, Carcharoth carcharothwp@googlemail.comwrote:
Maybe the ideas aren't good enough? :-)
Carcharoth
On Wed, Jul 22, 2009 at 5:04 PM, FT2ft2.wiki@gmail.com wrote:
I have had an idea how we could help resolve POV and sourcing wars, that would fit very well with Wikipedia philosophy. I might dust it off some time. The mood in the community is such that few proposals are welcomed
by
sufficient users to get accepted, and at the same time the problems
persist
and are critiqued.
Anyone else notice that?
FT2
On Wed, Jul 22, 2009 at 3:00 PM, Jonathan Hall <sinewave@silentflame.com wrote:
OK - so I think a fair summary of this proposal (correct me if I'm
wrong)
is: We should create a group of experienced BLP editors (or similar) to edit a BLP that has been the subject of an edit war. The page would be protected from editing by other (non-sysop) users. This would form an alternative to or replacement for page protection, and would hopefully lead to more editing than page protection. We should also allow users to create draft articles in their userspace that are (by default) protected from editing by other non-sysops.
I share FT2's concerns about the need to avoid creating a BLP cabal with the first point, and I also have concerns about the second point
- it could lead to POV forks and encourage people to hide an imperfect
article in their userspace rather than it being more visible and publically editable, which will lead to faster improvement. It could also lead to greater feelings of article ownership - if you grew an article to (say) A-class in your userspace before moving it to article space you'll probably have greater feelings of ownership than if it was in publically editablearticlespace from the start.
On Tue, Jul 21, 2009 at 04:05, Jay Litwynbrewhaha@freenet.edmonton.ab.ca wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a
preacher's words. If you hav ever right-clicked on a file that you
uploaded
to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags,
all
within your control:
R W P e r e a i r d t m e i tOwner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the
only
one that the system would let you own. Admins would be owners of all
pages
in main: and user: on wikipedia. That way, if you you refused to comply
with
one rule or another concerning how user space is used, then an admin
would
permit everyone to also be able to write to your space, so that a
volunteer
could show you his ignorance of those rules :-) I can almost see the
author
of "vandalproof" hanging his head and asking why he did not think of
that.
group permission is a special feature of protected file systems.
Windows
does not hav group permission in XP, TMK, and it does let you protect
shared
objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop
would
let you write files in a particular project, because you were a member
of
the required group.
In a series of occurances, here is how a biography might become
authorized and get a special stamp of approval from the subject of the biography.
Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits
everyone to write to it.
An edit war breaks out, so the sysop (sysops always hav power to
permit,
as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress.
No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by
reading three months of history.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- 1001010 1001000110000111011001101100
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
It is an old idea that ran on IBM 370s in 1990. On them, what I am describing is child's play. On them I could also give you permission to read a file, and only with a certain program. "run only" for example was so common that it had an abreviation: "permit bugs run unsp:disasm" (permit user:bugs to run disasm as written in the filespace of user:unsp)-- and different permission for any user who asked. That means I can't debug it, I can't read it, and I certainly can't write it. Michigan Terminal System was so cheap with file space in those days, that I could not even expand it -- writing a file and expanding it were different things. Today, a gigabyte is quite a bit less than a dollar. Back then, you could not get drives that big. Even though the system had a few terabytes of disk space, it was composed of *many* drives. Old idea. What wikipedia would need for using it is already a part of the file system that it runs on. I am trying to give it new wings.
My impression of file ownership on wikipedia is that the more effort you put into it, and how long, is the main predictor of much you do not feel like giving up on it -- no matter what the policy on ownership...well, inevitably there are articles out there superior to wikipedia because an author did take a point of view, and it happens to be more correct than anything you could find in the middle. Hey. You know what. I do not think policy changed when the permission controls were added, so that file in someone else's space for which everyone had unlimited access could've been bait. _______ Does a Cheshire cat drink evaporated milk?
"FT2" ft2.wiki@gmail.com wrote in message news:e71d9fab0907221039vacb4be9g410afec43ab6c144@mail.gmail.com...
Maybe. But innovation is no bad thing, and if a disproportionate number of ideas are rejected too early rather than explored or trialled, perhaps some that would find value will be lost.
It's easy to forget that a wide range of processes and tools we take for granted today started off being considered questionable at their proposal.
FT2
On Wed, Jul 22, 2009 at 5:15 PM, Carcharoth carcharothwp@googlemail.comwrote:
Maybe the ideas aren't good enough? :-)
Carcharoth
On Wed, Jul 22, 2009 at 5:04 PM, FT2ft2.wiki@gmail.com wrote:
I have had an idea how we could help resolve POV and sourcing wars, that would fit very well with Wikipedia philosophy. I might dust it off some time. The mood in the community is such that few proposals are welcomed
by
sufficient users to get accepted, and at the same time the problems
persist
and are critiqued.
Anyone else notice that?
FT2
On Wed, Jul 22, 2009 at 3:00 PM, Jonathan Hall <sinewave@silentflame.com wrote:
OK - so I think a fair summary of this proposal (correct me if I'm
wrong)
is: We should create a group of experienced BLP editors (or similar) to edit a BLP that has been the subject of an edit war. The page would be protected from editing by other (non-sysop) users. This would form an alternative to or replacement for page protection, and would hopefully lead to more editing than page protection. We should also allow users to create draft articles in their userspace that are (by default) protected from editing by other non-sysops.
I share FT2's concerns about the need to avoid creating a BLP cabal with the first point, and I also have concerns about the second point
- it could lead to POV forks and encourage people to hide an imperfect
article in their userspace rather than it being more visible and publically editable, which will lead to faster improvement. It could also lead to greater feelings of article ownership - if you grew an article to (say) A-class in your userspace before moving it to article space you'll probably have greater feelings of ownership than if it was in publically editablearticlespace from the start.
On Tue, Jul 21, 2009 at 04:05, Jay Litwynbrewhaha@freenet.edmonton.ab.ca wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a
preacher's words. If you hav ever right-clicked on a file that you
uploaded
to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags,
all
within your control:
R W P e r e a i r d t m e i tOwner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the
only
one that the system would let you own. Admins would be owners of all
pages
in main: and user: on wikipedia. That way, if you you refused to comply
with
one rule or another concerning how user space is used, then an admin
would
permit everyone to also be able to write to your space, so that a
volunteer
could show you his ignorance of those rules :-) I can almost see the
author
of "vandalproof" hanging his head and asking why he did not think of
that.
group permission is a special feature of protected file systems.
Windows
does not hav group permission in XP, TMK, and it does let you protect
shared
objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop
would
let you write files in a particular project, because you were a member
of
the required group.
In a series of occurances, here is how a biography might become
authorized and get a special stamp of approval from the subject of the biography.
Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits
everyone to write to it.
An edit war breaks out, so the sysop (sysops always hav power to
permit,
as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress.
No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by
reading three months of history.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- 1001010 1001000110000111011001101100
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Creating essentially invisible articles in userspace already has at least one example, and seemingly within [[category:hated people]]. I guess that they could go straight into mainspace, suffer there, get moved into someone's user space for protection that is like vandal proof, then once admins take sides on which edits were bad without taking sides on which editors are bad -- once admins know what BLP means in terms of examples explained, then it could be moved into mainspace again, where it can still be deleted, and where ten or twenty people who actually interacted with the subject had their say.
sinewave, huh? Neatness counts. They've gotta end with .5 bias and half the amplitude, or they'll click.
"Jonathan Hall" sinewave@silentflame.com wrote in message news:5f9b6e200907220700u2b94b5b3o35d7d5246ea24882@mail.gmail.com...
OK - so I think a fair summary of this proposal (correct me if I'm wrong) is: We should create a group of experienced BLP editors (or similar) to edit a BLP that has been the subject of an edit war. The page would be protected from editing by other (non-sysop) users. This would form an alternative to or replacement for page protection, and would hopefully lead to more editing than page protection. We should also allow users to create draft articles in their userspace that are (by default) protected from editing by other non-sysops.
I share FT2's concerns about the need to avoid creating a BLP cabal with the first point, and I also have concerns about the second point
- it could lead to POV forks and encourage people to hide an imperfect
article in their userspace rather than it being more visible and publically editable, which will lead to faster improvement. It could also lead to greater feelings of article ownership - if you grew an article to (say) A-class in your userspace before moving it to article space you'll probably have greater feelings of ownership than if it was in publically editablearticlespace from the start.
On Tue, Jul 21, 2009 at 04:05, Jay Litwynbrewhaha@freenet.edmonton.ab.ca wrote:
Subject-Was: Re: A new solution for the BLP dilemma
"Nothing new is under the sun", are among the most humbling of a preacher's words. If you hav ever right-clicked on a file that you uploaded to your website (and you probably hav one that you are not using), then clicked on "properties", you would be greeted with this menu of flags, all within your control: R W P e r e a i r d t m e i t Owner: X X O Group: O O O Everyone: X O O
Those would be appropriate settings for your user page, which is the only one that the system would let you own. Admins would be owners of all pages in main: and user: on wikipedia. That way, if you you refused to comply with one rule or another concerning how user space is used, then an admin would permit everyone to also be able to write to your space, so that a volunteer could show you his ignorance of those rules :-) I can almost see the author of "vandalproof" hanging his head and asking why he did not think of that.
group permission is a special feature of protected file systems. Windows does not hav group permission in XP, TMK, and it does let you protect shared objects from being written to. My web server is NetBSD, so it does hav groups. Users can be added to groups, so that people who hav made applications for being included in a group -- applications to a sysop would let you write files in a particular project, because you were a member of the required group.
In a series of occurances, here is how a biography might become authorized and get a special stamp of approval from the subject of the biography. Someone write's a biography about someone else on their user page. They let it out among their collaborators. Two of those collaborators want to fix it, so the starter permits everyone to write to it. An edit war breaks out, so the sysop (sysops always hav power to permit, as well as power to destroy, which is not displayed) retracts all permission, except permission to a group, then assigns three veterans to that group and solicits their attention to an article in progress. No blocks are issued. No significant flaws are in the wording or the evidence. The page is permitted for reading by all and writing by none. Occasionally, on the talk page, someone raises {{editprotected}}. The questions typically get an answer that could hav been found by reading three months of history. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l