Killing a mosquito with a hammer is not the proper approach however.
Most of, if not all the major issues NYB brought up, were addressed already.
In many cases, when I search for particular things in Google, I *do* in fact want to see the Wikipedia information, that's for what in-fact I'm searching. Our internal search engine does not do the same finesse and bag-of-tricks that Google can do, so it's not really an adequate replacement.
IF the programmers had some way of creating a Google-internal-only search engine, that is, it works exactly like Google and I mean exactly, and yet can only be accessed from inside the Wikipedia frame, that could possibly work.
Often I simply know that there is some issue with a certain user, and I want to know what it IS, since some nellies on here won't just come right out and say it directly (read that tongue-in-cheek). My sole recourse is to Google for the user. Many, but not all, of these hits are to internal Wikipedia pages. How can a historian accurately track the meta-project if we're going to suppress the very pages that are most needed?
The only thing that noindexing User and User Talk pages will do, is give ammunition to those who already loudly trumpet that we hide actions of malevolent editors.. admins.. bureaucrats.. and arbcom members. Because now, we've made it 20 times harder to actually track those actions.
If there are cases, and I do mean relatively few, they can be handled with oversight. If those with Oversight do not WISH those cases to vanish, then we should not be back-dooring that very situation. If we don't have enough oversighters to handle the vast volume (tongue-in-cheek) then we should promote more.
This is not the solution to that problem.
Will Jhonson
**************Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr00050000000020)
IF the programmers had some way of creating a Google-internal-only search engine, that is, it works exactly like Google and I mean exactly, and yet can only be accessed from inside the Wikipedia frame, that could possibly work.
Is there some reason why the Foundation can't/won't buy a Google Search Appliance? (non-free content, etc?)
I've added __INDEX__ and __NOINDEX__ magic words in r37973. A configuration option might be added that would optionally disable them, or I might be reverted for other reasons, but the capability for user-added per-page indexing changes has now been written, in any event.
As I implemented it, any user can add or remove the indexing keywords. This is necessary given that they're implemented as magic words and not a special page or whatever. I did it that way because Brion seemed to favor it in his comments on bugs 8068 and 9415.
This would allow namespaces to be no-indexed by default (with a config change), with __INDEX__ used to re-index individual pages, like policy and essay pages in the Wikipedia namespace but not procedural pages like DRV or RFA.
2008/7/23 WJhonson@aol.com:
Killing a mosquito with a hammer is not the proper approach however.
Most of, if not all the major issues NYB brought up, were addressed already.
User and user talk pages, DRV and others have not been addressed. It is time to close the loop.
<snip> Often I simply know that there is some issue with a certain user, and I want to know what it IS, since some nellies on here won't just come right out and say it directly (read that tongue-in-cheek). My sole recourse is to Google for the user. Many, but not all, of these hits are to internal Wikipedia pages. How can a historian accurately track the meta-project if we're going to suppress the very pages that are most needed?
Google for the user? Really? You can't find talk pages or user contribution histories with out Google?
Meta-project pages are all still there within the mediawiki search function. Unlike some people who seem to need google to find anything for them, I have never once had a problem finding the desired page using the in-house search engine, wonky as it is, and it keeps improving over time.
The only thing that noindexing User and User Talk pages will do, is give ammunition to those who already loudly trumpet that we hide actions of malevolent editors.. admins.. bureaucrats.. and arbcom members. Because now, we've made it 20 times harder to actually track those actions.
You haven't been paying attention. There are all kinds of BLP violations on user and user talk pages, the vast majority of them unrecognised and unaddressed. Those pages often turn up in top 10 google hits, and often perpetuate the BLP problems that may have assiduously been removed from articles and even article talk. Articles need to be indexed. Community gossip does not.
The encyclopedia is about articles. That is what our readership wants to have at their fingertips. I doubt in the extreme that 99.998% of the people who have accessed Wikipedia in the past 24 hours care even so much as one tidbit who our admins are, or what our dispute resolution system is, or whether I exchanged greetings with anyone on my userpage. But I am sure that there are plenty of non-Wikipedians who are flabbergasted to google themselves and find nasty things written about themselves on a wikipedia page that doesn't even look like an article.
This is an encyclopedia, not a gossip rag.
Risker
On 7/23/08, WJhonson@aol.com WJhonson@aol.com wrote:
Killing a mosquito with a hammer is not the proper approach however. Most of, if not all the major issues NYB brought up, were addressed already.
I appreciate from Steve Bain's and other posts that the issue I raised in my first post has been addressed with regard to XfD, RfA, RfAr, RFC, and BLP/N pages (that is, at least the archives of these pages; I think the current pages should be no-indexed as well). However, the same principles that called for no-indexing these pages would also apply to DRV (which is indistinguishable in principle, for these purposes, from XfD; the only reason those pages are still indexed, as I understand it, has to do with page layout issues), as well as SSP, RfCU, the former PAIN and CSN, WQA, AN, AN/I, and AN3.
Pending issues include (1) do we agree to no-indexing all of these; (2) should project space be no-index with an "index this page" opt-in (my preference and how do we set that up); (3) how do we treat userspace (my preference would be a no-index default with users allowed to opt into being indexed if they wish); and (4) other namespaces.
Could someone post a link to any discussion that might be taking place on-wiki or on Bugzilla?
Thanks, Newyorkbrad
Considering as how this issue of noindexing user-space and user-talk by default only seems an issue with a very small handful of editors, I would think the community at-large, who has been having their space indexed for years, would fall on the side of continuing withthe *least* amount of disruption to the status quo.
??? That would be to no-index *on request* user pages and their associated talk pages, project pages and their associated talk pages.? That is, the default would be, as it is today, to index.? But a project or user can opt-in to not index.
?
Will Johnson
-----Original Message-----
From: Newyorkbrad (Wikipedia) <newyorkbrad@gmail.com>
To: English Wikipedia <wikien-l@lists.wikimedia.org>
Sent: Thu, 24 Jul 2008 3:40 pm
Subject: Re: [WikiEN-l] No-indexing of project-space pages
On 7/23/08, WJhonson@aol.com <WJhonson@aol.com> wrote: > > Killing a mosquito with a hammer is not the proper approach however. > Most of, if not all the major issues NYB brought up, were > addressed already. I appreciate from Steve Bain's and other posts that the issue I raised in my first post has been addressed with regard to XfD, RfA, RfAr, RFC, and BLP/N pages (that is, at least the archives of these pages; I think the current pages should be no-indexed as well). However, the same principles that called for no-indexing these pages would also apply to DRV (which is indistinguishable in principle, for these purposes, from XfD; the only reason those pages are still indexed, as I understand it, has to do with page layout issues), as well as SSP, RfCU, the former PAIN and CSN, WQA, AN, AN/I, and AN3. Pending issues include (1) do we agree to no-indexing all of these; (2) should project space be no-index with an "index this page" opt-in (my preference and how do we set that up); (3) how do we treat userspace (my preference would be a no-index default with users allowed to opt into being indexed if they wish); and (4) other namespaces. Could someone post a link to any discussion that might be taking place on-wiki or on Bugzilla? Thanks, Newyorkbrad _______________________________________________ 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 Thu, Jul 24, 2008 at 11:07 PM, wjhonson@aol.com wrote:
Considering as how this issue of noindexing user-space and user-talk by default only seems an issue with a very small handful of editors, I would think the community at-large, who has been having their space indexed for years, would fall on the side of continuing withthe *least* amount of disruption to the status quo.
??? That would be to no-index *on request* user pages and their associated talk pages, project pages and their associated talk pages.? That is, the default would be, as it is today, to index.? But a project or user can opt-in to not index.
I'd say a reasonable middle-ground would be to upgrade the software to support __INDEX__ and __NOINDEX__ then give users a week or two to tag the stuff they want indexed with __INDEX__ before flipping the noindex switch on. This would allow us to keep indexing the useful stuff without having to hunt down every userfied BLP and tag it. Also, new userspace pages would be no-indexed by default, which seems like a good thing to me.
2008/7/25 Chris Howie cdhowie@gmail.com:
On Thu, Jul 24, 2008 at 11:07 PM, wjhonson@aol.com wrote:
Considering as how this issue of noindexing user-space and user-talk by default only seems an issue with a very small handful of editors, I would think the community at-large, who has been having their space indexed for years, would fall on the side of continuing withthe *least* amount of disruption to the status quo.
??? That would be to no-index *on request* user pages and their associated talk pages, project pages and their associated talk pages.? That is, the default would be, as it is today, to index.? But a project or user can opt-in to not index.
I'd say a reasonable middle-ground would be to upgrade the software to support __INDEX__ and __NOINDEX__ then give users a week or two to tag the stuff they want indexed with __INDEX__ before flipping the noindex switch on. This would allow us to keep indexing the useful stuff without having to hunt down every userfied BLP and tag it. Also, new userspace pages would be no-indexed by default, which seems like a good thing to me.
With the amount of stuff that it is useful to index about the only sane response to putting such a procedure in place would be to bot tag everything with __INDEX__ .
On Fri, Jul 25, 2008 at 1:50 PM, geni geniice@gmail.com wrote:
2008/7/25 Chris Howie cdhowie@gmail.com:
On Thu, Jul 24, 2008 at 11:07 PM, wjhonson@aol.com wrote:
Considering as how this issue of noindexing user-space and user-talk by default only seems an issue with a very small handful of editors, I would think the community at-large, who has been having their space indexed for years, would fall on the side of continuing withthe *least* amount of disruption to the status quo.
??? That would be to no-index *on request* user pages and their associated talk pages, project pages and their associated talk pages.? That is, the default would be, as it is today, to index.? But a project or user can opt-in to not index.
I'd say a reasonable middle-ground would be to upgrade the software to support __INDEX__ and __NOINDEX__ then give users a week or two to tag the stuff they want indexed with __INDEX__ before flipping the noindex switch on. This would allow us to keep indexing the useful stuff without having to hunt down every userfied BLP and tag it. Also, new userspace pages would be no-indexed by default, which seems like a good thing to me.
With the amount of stuff that it is useful to index about the only sane response to putting such a procedure in place would be to bot tag everything with __INDEX__ .
We would definitely need bots to tag large slabs of pages that are useful, but I think this is a sensitive enough issue that we should do it right. A project page listing all pages to be categorised created to collate reasonable classes of pages, time allowed for a little discussion, and only then should operators man their bots.
-- John
I do not agree. We have immense amount of crap in our other namespaces that nobody will actively find and tag/untag.
On Fri, Jul 25, 2008 at 3:52 PM, John Vandenberg jayvdb@gmail.com wrote:
On Fri, Jul 25, 2008 at 1:50 PM, geni geniice@gmail.com wrote:
With the amount of stuff that it is useful to index about the only sane response to putting such a procedure in place would be to bot tag everything with __INDEX__ .
We would definitely need bots to tag large slabs of pages that are useful, but I think this is a sensitive enough issue that we should do it right. A project page listing all pages to be categorised created to collate reasonable classes of pages, time allowed for a little discussion, and only then should operators man their bots.
-- John
I do not agree. We have immense amount of crap in our other namespaces that nobody will actively find and tag/untag.
This part tacked on the end is the reason why we should not let bots tag _everything_ as you suggested.
-- John
A reasonable compromise
On Thu, Jul 24, 2008 at 11:23 PM, Chris Howie cdhowie@gmail.com wrote:
On Thu, Jul 24, 2008 at 11:07 PM, wjhonson@aol.com wrote:
Considering as how this issue of noindexing user-space and user-talk by default only seems an issue with a very small handful of editors, I would think the community at-large, who has been having their space indexed for years, would fall on the side of continuing withthe *least* amount of disruption to the status quo.
??? That would be to no-index *on request* user pages and their associated talk pages, project pages and their associated talk pages.? That is, the default would be, as it is today, to index.? But a project or user can opt-in to not index.
I'd say a reasonable middle-ground would be to upgrade the software to support __INDEX__ and __NOINDEX__ then give users a week or two to tag the stuff they want indexed with __INDEX__ before flipping the noindex switch on. This would allow us to keep indexing the useful stuff without having to hunt down every userfied BLP and tag it. Also, new userspace pages would be no-indexed by default, which seems like a good thing to me.
-- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
2008/7/25 Chris Howie cdhowie@gmail.com:
<snip>
I'd say a reasonable middle-ground would be to upgrade the software to support __INDEX__ and __NOINDEX__ then give users a week or two to tag the stuff they want indexed with __INDEX__ before flipping the noindex switch on. This would allow us to keep indexing the useful stuff without having to hunt down every userfied BLP and tag it. Also, new userspace pages would be no-indexed by default, which seems like a good thing to me.
Concur that this sounds entirely reasonable, although it might be worthwhile for some BLP-sensitive folk to trawl through the ones that people tag as __INDEX__ at a future date.
Risker
On Fri, Jul 25, 2008 at 1:28 AM, Risker risker.wp@gmail.com wrote:
Concur that this sounds entirely reasonable, although it might be worthwhile for some BLP-sensitive folk to trawl through the ones that people tag as __INDEX__ at a future date.
If it gets it implemented and lets us change the default... GREAT!
May well be that __INDEX__ becomes Wikipediaspeak for __SPAM__, if so, then so be it... at least it wouldn't be too hard to watch for.