No-indexing of project-space pages
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 | Next > |
 |
Re: No-indexing of project-space pages
by Chris Howie
::
Rate this Message:
On Wed, Jul 23, 2008 at 12:48 PM, Gregory Maxwell <gmaxwell@...> wrote:
> An explicit list of exemptions could reasonably grow to very large and > it would need to be scanned for membership every time a page is > parsed. I would be somewhat surprised if there were not >1000 > meta-categories already. Go look at how __NOTOC__ works, that would > be the most logical way of doing this in mediawiki. Thoughts? I'm not pushing a big page over a __NOTOC__ type syntax (yes, I know what it is too). But with a big page we would get protection capabilities, which we would not have with a parser extension. That was the primary argument behind that suggestion. It depends whether we value protection of the noindex system more or maintainability of the list more. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Charlotte Webb
::
Rate this Message:
On 7/23/08, Gregory Maxwell <gmaxwell@...> wrote:
> An explicit list of exemptions could reasonably grow to very large and > it would need to be scanned for membership every time a page is > parsed. I would be somewhat surprised if there were not >1000 > meta-categories already. Go look at how __NOTOC__ works, that would > be the most logical way of doing this in mediawiki. Thoughts? Alright, we could insert something like this into the header templates used for non-content "meta" categories such as the examples I gave above. Tracking down abuses need not be so tedious. If this __NOINDEX__ symbol adds the html which tells Google-bot to move on because there's nothing to see here... it could easily add some sort of visible confirmation (by user preference or javascript gadget or something) showing some kind of on/off-style symbol (NOT FAIR USE, not the stylized [G] favicon mind you...!) to indicate whether or not the page is indexed so you don't have to check the html manually. —C.W. _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Charlotte Webb
::
Rate this Message:
On 7/23/08, Charlotte Webb <charlottethewebb@...> wrote:
> ...so you don't have to check the html manually. But let's not get ahead of ourselves, we need a better internal search engine first. I can see the usefulness of searching across several projects (to look for cross-wiki pattern vandalism to revert or look for other language versions of something you just wrote, etc.) so this is why i suggested putting it on the toolserver. On the other hand a dedicated domain name like "search.wikimedia.org" is equally if not more appealing. —C.W. _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Aryeh Gregor
::
Rate this Message:
On Wed, Jul 23, 2008 at 12:35 PM, Gregory Maxwell <gmaxwell@...> wrote:
> Having to read some enormous page every page-load wouldn't be good. It > would be better to do the right thing on average per-namespace then > use something in the pages to control exceptions. The ability to noindex namespaces is already in MediaWiki and could be turned on at will. See $wgNamespaceRobotPolicies. $wgArticleRobotPolicies is also relevant, although not really useful unless we have a very short fixed list of exceptions that can be maintained by sysadmins (which we don't). It wouldn't be too hard to fix bug 8068 and add a __NOINDEX__ keyword, though. We would of course want an __INDEX__ keyword as well. (Probably we can leave out __FOLLOW__ and __NOFOLLOW__ as options. Using the namespace default for all pages should be fine there.) Maybe I'll make that my project for today. _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
|
|
|
Re: No-indexing of project-space pages
by Chris Howie
::
Rate this Message:
On Wed, Jul 23, 2008 at 3:06 PM, <WJhonson@...> wrote:
> Transparency. There is no benefit and a great drawback to not indexing. > Not indexing makes it appear we are hiding something. That belief is already > very prevalent among our critics, we don't want to feed them a ton of raw > steak. It's hard to hide things when our own search engine can find them too. And even if our own search was restricted to not search though some things, AfD for example (though not doing so would probably make a lot of people mad, and rightfully so), then someone interested enough could write a spider that ignores robot tags and fetches everything, then grep it. Or hell, just download a database dump. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Gregory Maxwell
::
Rate this Message:
On Wed, Jul 23, 2008 at 3:06 PM, <WJhonson@...> wrote:
> Transparency. There is no benefit and a great drawback to not indexing. > Not indexing makes it appear we are hiding something. That belief is already > very prevalent among our critics, we don't want to feed them a ton of raw > steak. You are welcome to weigh the benefit as insufficient, when you say "no benefit" you're insulting several experienced and trusted users here who see substantial benefit. I've yet to see anyone accuse us of hiding things on the basis of the many things we already no-index. Can you provide a pointer? On the flipside I can point to several examples of WP critics complaining that our sausage-making is showing up at the top of Google, above more useful links, just on the basis of our domain's high position. If your concern is transparency and avoiding criticism for hiding things there are several gigantic elephants in the room that are not yet addressed which make no-indexing seem utterly insignificant by comparison. For example, consider the fact that deletion and oversight cause mis-attribution of edits, and that we frequently use deletion to hide widely linked to bad edits ... really to avoid people being mislead by the links, but someone could argue that we're hiding our errors). _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
|
|
|
Re: No-indexing of project-space pages
by Angela Anuszewski
::
Rate this Message:
>
> 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?) -- Wikipedia:[[User:Psu256]] _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Aryeh Gregor
::
Rate this Message:
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. _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Risker
::
Rate this Message:
2008/7/23 <WJhonson@...>:
> 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 > 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 _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
|
|
|
|
|
|
Re: No-indexing of project-space pages
by Nathan Awrich
::
Rate this Message:
Even if its true that you *need* Google for this purpose, its nowhere near
important enough a function to effectively argue against turning on noindex for non-article/portal pages. Of the number of people using searches on Google that might turn up a DRV, AfD, user page, etc. with damaging information - few of them are going to be Wikipedians searching for dirt or dish on other Wikipedians. The purpose of Wikipedia isn't to be available to historians researching its creation, or to various editors looking for meta-details - its to be an encyclopedia, for the public, with useful information. Having damaging information available on real people thats relevant only inside Wikipedia doesn't serve that purpose, so making it unsearchable outside Wikipedia is completely sensible. Nathan On Wed, Jul 23, 2008 at 4:21 PM, <WJhonson@...> wrote: > > > > > --------------- > You know perfectly well (I think) that that is not to what I refer. > I'm not looking for the user's page, but rather the user, wherever they > appear. > > If there is an allusion to so-and-so getting into a nasty fight with > such-and-such, I need to look for the two of them together to see what it's > about. > It's not perfectly likely that that fight appeared on either user or user > talk pages of *them* but it may appear on the talk page of somebody else. > > Historians need to preserve the ability to biograph the historians > themselves. That is part of the history of Wikipedia. We are not just a > series of > articles, but rather individuals and some of those individuals create > intriguing historians of their own. Noindexing user talk pages > effectively wipes the > ability to learn whatever-can-be-known about the people who create > Wikipedia. > > Will Johnson > > > WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Chris Howie
::
Rate this Message:
On Wed, Jul 23, 2008 at 4:23 PM, <WJhonson@...> wrote:
> Then address them. Wiping all history is not the way to so do. What exactly about noindexing pages removes their history? -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Joe Szilagyi
::
Rate this Message:
On Wed, Jul 23, 2008 at 1:29 PM, Chris Howie <cdhowie@...> wrote:
> On Wed, Jul 23, 2008 at 4:23 PM, <WJhonson@...> wrote: > > Then address them. Wiping all history is not the way to so do. > > What exactly about noindexing pages removes their history? > Nothing. The principal benefit that I can see about blocking Search engines to anything but Article, Image, and Portal space is that our readers see and find the real content, that we're producing. With real life names, defamation, libel, BLP vios, and lord knows what else buried in archives of DRV, AFD, user talk, project space... how does it benefit us to let all that hang out? So the occassional user can "search about" another user? Does not compute. - Joe _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
|
|
|
Re: No-indexing of project-space pages
by Newyorkbrad (Wikipedia)
::
Rate this Message:
On 7/23/08, WJhonson@... <WJhonson@...> 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@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Newyorkbrad (Wikipedia)
::
Rate this Message:
On 7/23/08, WJhonson@... <WJhonson@...> wrote:
> > > In a message dated 7/23/2008 8:16:12 A.M. Pacific Daylight Time, > szilagyi@... writes: > > What is the benefit to allowing Google to index DRV, talk pages, and > user/user talk pages?>> > > ---------------------------------------- > Transparency. There is no benefit and a great drawback to not indexing. > Not indexing makes it appear we are hiding something. That belief is > already > very prevalent among our critics, we don't want to feed them a ton of raw > steak. > > Will Johnson As was previously noted, pages such as AfD, RfA, and RfAr were apparently excluded from being indexed some time ago. (I apologize again for having missed this in my initial post, and am curious when it was done.) I have never heard of a single complaint regarding this change in procedure. Wikipedia's critics have a broad range of views, and no one can anticipate every criticism that could (rightly or wrongly) be made. However, as noted, there have been relatively few objections raised to no-indexing most of the types of pages at issue other than purely logistical ones. By contrast, several of Wikipedia's best-known critics have repeatedly and vociferously objected to the fact that negative comments about both contributors or article subjects -- including types of comments that would not be allowed in the encyclopedia itself -- are preserved forever on Wikipedia pages, and thus inevitably become high-ranking and permanent search engine results for these individuals. They are right to object, and Wikipedia should continue to address this well-known, longstanding, and readily fixable problem. My concern with this issue is not an idiosyncratic one. I have seen others raise concerns surrounding this issue on-wiki, on this mailing list, on Bugzilla, had them expressed to me by a personal acquaintance who has encountered this issue, and also seen frequent references to the problem on a site in which many of "our critics," as well as many Wikipedians (who may of course also be critics), participate. Sometimes we may think that criticism of Wikipedia is misguided, but other times it has merit, and when it has merit we should act on it. In any event, the possibility that our critics would be affronted by our no-indexing these pages is purely speculative, while the fact that our critics (and many others) have raised entirely justified objections to our current practice is very real. Newyorkbrad _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
|
|
Re: No-indexing of project-space pages
by Newyorkbrad (Wikipedia)
::
Rate this Message:
On 7/23/08, Charlotte Webb <charlottethewebb@...> wrote:
> > On 7/23/08, Charlotte Webb <charlottethewebb@...> wrote: > > ...so you don't have to check the html manually. > > But let's not get ahead of ourselves, we need a better internal search > engine first. I can see the usefulness of searching across several > projects (to look for cross-wiki pattern vandalism to revert or look > for other language versions of something you just wrote, etc.) so this > is why i suggested putting it on the toolserver. > > On the other hand a dedicated domain name like "search.wikimedia.org" > is equally if not more appealing. > > —C.W. Any thoughts following up on the status of our ability to create improved internal searching as discussed here? Implementation of the no-index proposal should not await (and I gather is not awaiting) improvements in this feature, but a commitment to proceed with such improvements would eliminate virtually the only serious objection that has been raised to it. Newyorkbrad _______________________________________________ WikiEN-l mailing list WikiEN-l@... To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l |
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
