I have just completed and written up a little research project of mine:
1. Talk pages are where references/links/citations go to die; less
than 10% ever make it back
2. In just the sampled edits, millions of page-views are affected
3. Conclusion: putting references/links/citations in an Article's Talk
page is a bad idea (compared to External Links)
Numbers, source code, and lists of edits are provided in the link.
On 22 December 2011 18:10, Ken Arromdee <arromdee(a)rahul.net> wrote:
> And for the general problem is something I've often noted: Wikipedia is set
> up to force people to follow the rules.
Interesting debating point, but I think the comment is ahistorical. It is
more accurate, IMO, to note that "slavish" rule-following on enWP is a
characteristic of non-"old school" editors. It may well be that the
community as a whole has shifted its centre of gravity on this issue. (The
point covers both the curatorial and disciplinary functions on the site, so
I'd make the case for parsing it further.)
> And the more you use "it's in the
> rules" as a club to hit bad users with, the more others can use it as a
> to force bad ideas through; there's just no defense to "what I want
> follows the
> rules". You see this all the time for BLPs: "Don't you have any empathy?
> We're hurting a real person." "You're just trying to distract us from this
> rule. Your own personal feelings aren't an excuse to ignore our
We have IAR, and "slavishness" might be called IIAR, so it should be
ignored as a guideline (IIIAR should trump IIAR). This could all get silly
but according to some logical stuff, that has been known since about 1920,
I^4AR is probably no different from I^2AR.
In other words, if the writ of "ignore all rules" no longer runs because
the community thinks of it as too retro, there can still be some
meta-principle about not following the wrong path just because rules
indicate it. "Rule-bound" is like "muscle-bound", a pejorative, and rightly
BLPs are of course an obvious place where it may be hardest to argue that
rules should be ignored.
I wanted to let everyone know that we recently began testing some new
versions of the Article Feedback tool. As you may remember, the first
version of the tool (launched earlier this year), focused on having readers
provide feedback on the quality of articles . The new versions try a
different approach, based in part on feedback from the community. Rather
than ask readers for feedback on quality, the new feedback forms prompt the
user to help improve the encyclopedia. For example, one version we're
testing asks the reader "Did you find what you're looking for?". If the
reader answers "No", the tool prompts them to explain what is missing. The
intent is to provide editors with some idea of feedback on what readers are
actually hoping to see when they read a Wikipedia article, so that the
editing community may incorporate that feedback when developing the
article. Hopefully, some of these readers will also become editors.
Here is the blog post with more details:
Right now, there are three test versions running on approximately 10,000
randomly selected rticles.
Is this type of feedback actually going to be helpful? We don't know. So
the next step is to evaluate the comment streams coming in from each test
version to see which one offers the most number of constructive comments
accompanied by the least amount of noise . We'll be doing this with
community members, so if you'd like to be involved, please drop either me
or Oliver Keyes (okeyes at wikimedia dot org) a line. We're also tracking
progress on the project page .
 The comment streams aren't going to be viewable by the public yet. One
of the next phases of the project is to design a "Feedback Page" which
displays the comment stream on a per article basis. We'll be collaborating
closely with the editing community on the design of this page.
---------- Forwarded message ----------
From: Neil Kandalgaonkar <neilk(a)wikimedia.org>
Date: 13 December 2011 21:27
Subject: [Wikitext-l] Help us test the VisualEditor prototype
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Cc: Wikitext-l <wikitext-l(a)lists.wikimedia.org>
Here's the demo, where you can edit some canned texts (but not actual
Wikipedia articles, yet):
Post bugs here:
And here's the blog post, which puts it more in context.
This new editor was mostly written by Trevor Parscal and Inez
Korczyński, although lots of others have contributed. I've sat a desk
away from them for a few months and I have to say I'm extremely
impressed with what they've put together. If you're expecting Google
Docs, we're not there yet. But the basics are starting to solidify, and
it's getting easier and easier to add cool features.
Hey MediaWiki developers, surely you're not going to let Trevor and Inez
have *all* the fun?
Neil Kandalgaonkar (| <neilk(a)wikimedia.org>
Wikitext-l mailing list
On Sun, 11 Dec 2011 15:01:33 +0000, Charles Matthews wrote:
> That said, I deprecate getting "design" issues mixed up with others. The
> use of emotive terms such as cold and unfriendly implies things about
> intention and fault that aren't exactly helpful. I don't know whether
> arguing that WP is "sui generis" is defensive or not. I can think of
> several issues where it allows a reply like "you'd have more of a case if
> WP were ...", to fill in to taste with "staffed by paid workers"/"for
> profit"/"offering a different service"/"run on a billion dollar
> budget"/"Facebook", etc. These answers seem to me to offer analytical
While the design and user interface of Wikipedia certainly has things
that could stand improvement, I generally like the fact that it's not
run by a "billion dollar budget" commercial outfit brimming with
meddlesome marketing and management types and artsy graphical
designers, aimed at producing a site design that looks cool when
demoed in PowerPoint presentations, shoves lots of annoying,
intrusive ads at the user and is explicitly designed and structured
to maximize this even at the expense of actual content, and works
well (if at all) only in the particular browsers and platforms
targeted by the developer.
Those sites are hard to navigate, hard to read, slow to load, prone
to crashing your browser, go out of their way to interfere with
normal browser operations like caching and back/forward buttons by
having crazy contraptions of scripts to reinvent those wheels in an
inferior way, and are generally a headache to use in comparison with
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/
please try out Sztakipedia toolbar, which might save you some time while
The 90 sec intro video explains everything:
alternatively, please check out the home page of the tool:
http://pedia.sztaki.hu, for installation instructions, etc.
Please give me feedback, good or bad at the talk page of the tool:
For me, your feedback is the most essential thing. As a PhD student my
resarch topic is about how to bring some AI into the editor interfaces
where people create knowledge. My primary target was Wikipedia, even though
I'm an occasional contributor only. Dealing the wiki system is no easy
matter though, so the system I introduce today is not implementing the
whole vision I had when we started the development with some other
students. Not even close. However, the foundation is working on a new
parser and a new rich text editor interface which could open up new options
for the integration of AI. So even if you do not prefer the current form of
Sztakipedia, please share your vision at the talk page or by email about
what kind of help you wish from some kind AI in the editor interface in the
Computer and Automation Research Institute
Hungarian Academy of Sciences
p.s. also please tip me: to what other lists I should send this intro?
Creative Commons is beginning the process of revising their suite of
licenses, with the goal of having a 4.0 version by the end of 2012:
They have a set of goals, including better internationalization,
better interoperability with other licenses, and addressing the needs
of new communities like governments and other public institutions in
addition to the communities already using the licenses.
But this is the requirements gathering period--there is no draft yet.
If you want your input considered, this is the best time to start
thinking about what is and isn't working with the current version of
There is a public wiki explaining more about the goals, timeline,
considerations, and ways to participate:
Wikimedia wants the 4.0 licenses to be better for us and for the
commons than the 3.0 versions, which most Wikimedia projects are
currently using; CC has already reached out to us, wanting to come out
with a version that the Wikimedia community will adopt, and we'll be
trying to make sure everything is coordinated and communicated well
throughout the revision process. But if you are interested, you should
be participating directly. This is doubly true if you are in a
jurisdiction with unusual requirements, or part of a group of users
with particular wants that are not handled well by the current
Please pass this message on to other places where interested people will see it!
Your donations keep Wikipedia free: https://wikimediafoundation.org/wiki/Donate
Web: http://www.mindspillage.org Email: kat(a)wikimedia.org, kat(a)mindspillage.org
(G)AIM, Freenode, gchat, identi.ca, twitter, various social sites: mindspillage
Now whatever the merits of his case, this chap does have a point about
the unfriendliness of the environment. It isn't so much that we've
gone out of our way to be unfriendly, but the tool we use to
interact--the wiki, in other words--isn't really very fit for the
Wikis are _supposed_ to invite contributions, but here we seem to have
built a big maze that only frustrates people who in good faith want to
help us to make it better.
Is there any chance for progress to be made on this? I recently ran
into this problem again at a featured article candidate I was
reviewing. It is has a very worthy 'National Historic Landmarks' set
of templates at the bottom, but unfortunately this leads to massive
template linkage bloat. Of the over 100 articles that link to this
article, I estimate that only three links are from within the text of
other articles - the rest are from the templates.
If I had been able to see at a glance that this article was linked
from two other articles, I would have been able to make a suggestion
to link back to those articles, and maybe link from other articles. As
it was, I was unable to do this and this caused some problems (which
it is best not to go into here).
So is there anyway to encourage or help with whatever needs to be done here?
On Mon, Feb 7, 2011 at 4:10 AM, David Goodman <dggenwp(a)gmail.com> wrote:
> agreed. The footer templates are the biggest source of linkage bloat.
> the templates are useful, and we need some way of keeping track of
> what should be in them when we add or delete articles, but they make
> working with what links here for any practical purpose extremely
> difficult. They'd be much more helpful if they were separated.
> On Sun, Feb 6, 2011 at 9:52 PM, Carcharoth <carcharothwp(a)googlemail.com> wrote:
>> On Mon, Feb 7, 2011 at 1:34 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
>>> On 07/02/11 10:56, Carcharoth wrote:
>>>> On Sun, Feb 6, 2011 at 10:19 PM, Magnus Manske
>>>> <magnusmanske(a)googlemail.com> wrote:
>>>>> Many of these links are due to templates, which I can do little about.
>>>> Can *anyone*, even in principle, do something about that? It really
>>>> bugs me that the "what links here" function doesn't distinguish
>>>> between links arising from templates (often not directly relevant) and
>>>> links directly from the article wiki-text. If the answer is something
>>>> to do with parsers, please do explain!
>>> Yes, it's possible. It was necessary to register links from templates
>>> in the pagelinks table so that when a page is deleted or created, the
>>> HTML caches can be updated so that the link colour will change. With a
>>> schema change and some parser work, it would be possible to flag such
>>> links so that they are optional in "what links here".
>> That would be wonderful. It might even get me to create a bugzilla
>> account to vote for a bug if there is one open on this...(of course,
>> one problem is still that some templates are relevant to article
>> content and some are not - the ones that generate distracting links
>> are the navigational ones that tend to be at the bottom of pages, the
>> footer templates - and I'm not sure if infobox links would count as
>> template links or not - they are generated from parsing of a template
>> parameter, but don't appear in the template itself, unlike the footer
>> [In case anyone is confused, an example is the massive footer
>> templates that can lead to Nobel prize winners decades apart linking
>> to each other, or diverse topics within a broad area linking to each
>> other, though only through templates and not in the text. Oh, and some
>> links appear in both footer templates, infoboxes, and the article
>> 'text'. Not sure how that is handled.]
>> WikiEN-l mailing list
>> To unsubscribe from this mailing list, visit:
> David Goodman
> DGG at the enWP
> WikiEN-l mailing list
> To unsubscribe from this mailing list, visit: