> From: Ray Saintonge <saintonge(a)telus.net>
> Subject: Re: [WikiEN-l] Proposals for new policy/guidelines
> To: English Wikipedia <wikien-l(a)lists.wikimedia.org>
>
> Jonas Rand wrote:
>> I believe that many of Wikipedia's current policies are flawed, and
>> should
>> be replaced by new ones, and/or new policies should be created. The
>> neutral
>> point of view policy is especially flawed in that there is no such thing
>> as
>> completely unbiased. Everyone has a bias, and it complicates things when
>> people hide biases and pretend not to have them. Wikipedia should be an
>> open, collaborative site where everyone can voice their opinions on a
>> subject. This would be under a horizontal rule below the article.
>>
> You clearly don't understand NPOV. Its presence is an acknowledgement
> that everyone has a bias; it's not a denial. Indeed if everyone were
> capable of unbiased writing it would no longer be needed. The neutral
> point of view is not accomplished by one person; rather it is a
> synthesis of multiple views drawing in different directions until a
> balance is reached. We have far fewer problems with people hiding their
> biases than with people insisting on them.
I have heard this, and I think this interpretation of NPOV is good for a
fundamental principle. However, the interpretation that it is trying to be
without any point of view, which I have also heard, is a bad idea.
>
> There is a lot of room for expressing opinions on the talk pages where
> an opinion is recognized as such. For the most part, however, we are
> not in a position to pass judgement on the validity of an opinion.
The talk page is for opinions regarding the _article_, not the subject of
the article.
>> Claims in an article should mostly be supported by sources, if they are
>> scientific claims. It should also be a place where people experienced
>> about
>> a subject are respected and trusted if their claims are supported by
>> other
>> scientific publications. Original research, however, should also be
>> allowed,
>> if the research is extensive and sophisticated.
>>
> Whether a claim is "scientific" is a subjective judgement. Whether a
> person is sufficiently "experienced" is a subjective judgement. So too
> are several of the qualifiers in your statement. Your premises only
> lead to circular arguments and fallacious reasoning. Who decides
> whether original research is extensive and sophisticated? If it is
> truly original we necessarily only have the word of the researcher.
> Allowing them would leave us with a lot of strange theories without the
> capacity to perform adequate peer review ourselves.
>
> All this is still consistent with my view that the demand for sources,
> and accusations of original research are frequently taken to excess, but
> that's another story. The fundamental requirements in these areas
> remain sound.
Thank you for bringing attention to this, I'm sorry. I meant research
supported by pubications by scientists who are somewhat knowledgeable about
the subject (i.e. other pubications in that field) should at least be
considered and not outlawed.
>> All opinions should be allowed.
> They are ... on the talk page.
Only opinions regarding the article, improvements we should make to it, et
cetera. I am not saying we should replace the talk page with a discussion
page for the subject, as the talk page does serve a useful purpose. We
should keep the talk page, and use the subject discussion page alongside it.
Jonas
>----- Original Message ----
>From: Jonas Rand <joeyyuan(a)cox.net>
>To: wikien-l(a)lists.wikimedia.org
>Sent: Wednesday, June 4, 2008 5:29:30 PM
>Subject: [WikiEN-l] Proposals for new policy/guidelines
>All opinions should be allowed.
>Thoughts?
>Jonas
I think you want the blogosphere more than E2.
B
I believe that many of Wikipedia's current policies are flawed, and should
be replaced by new ones, and/or new policies should be created. The neutral
point of view policy is especially flawed in that there is no such thing as
completely unbiased. Everyone has a bias, and it complicates things when
people hide biases and pretend not to have them. Wikipedia should be an
open, collaborative site where everyone can voice their opinions on a
subject. This would be under a horizontal rule below the article.
Claims in an article should mostly be supported by sources, if they are
scientific claims. It should also be a place where people experienced about
a subject are respected and trusted if their claims are supported by other
scientific publications. Original research, however, should also be allowed,
if the research is extensive and sophisticated.
All opinions should be allowed.
Thoughts?
Jonas
> Date: Wed, 4 Jun 2008 12:12:19 -0400
> From: "Casey Brown" <cbrown1023.ml(a)gmail.com>
> Subject: Re: [WikiEN-l] Fwd: [Wikitech-l] TorBlock extension enabled
> To: "English Wikipedia" <wikien-l(a)lists.wikimedia.org>
> On Wed, Jun 4, 2008 at 9:59 AM, Jonas Rand <joeyyuan(a)cox.net> wrote:
>> I think this is a good idea, as far as soft-blocking or. However, the
>> "autoconfirmed, 100 edits, 90 days" is not, because the users with Tor
>> should be allowed to use it, if it protects them from privacy. It should
>> not
>> be softblocked until an editor is an "experienced editor", because it is
>> an
>> assumption of bad faith for Wikipedia to assume that an editor does not
>> have
>> good intentions because they aren't "prolific".
>>
>> I can understand if this is a cautionary measure, however just because an
>> editor hasn't made 100 edits and stayed there for 90 days, does not mean
>> they are vandals or sleeper accounts. This is a flaw in the proposal, and
>> should be fixed.
>>
>
> Of course, but this does not stop them from editing -- only from
> editing semi-protected pages or other things that require an
> autoconfirmed account[1]. Tor is too often abused (globally, on all
> Wikimedia sites), so I assume the longer autoconfirmed information is
> the price of having that level of privacy.
>
Well, I thought that softblocking was enabled for all registered accounts
(not just autoconfirmed ones). Therefore, it shouldn't be the Tor rule that
should change, but the softblocking rule altogether, so that all registered
accounts are softblocked.
> Just a note, this isn't a proposal. It is a notification or
> "heads-up" about an already installed[2], global (all of Wikimedia)
> extension.[3]
>
> [1]http://en.wikipedia.org/wiki/Special:ListGroupRights
> [2]http://en.wikipedia.org/wiki/Special:Version
> [3]http://www.mediawiki.org/wiki/Extension:TorBlock
Thank you.
Jonas
As of today, the "FlaggedRevs" extension is available to any wiki
community that wishes to use it. FlaggedRevs is a tool for patrolling
changes, identifying high quality article versions, and changing the
default version shown to unregistered users. It's highly configurable.
As such, we're making it available in two configurations:
1) A minimally intrusive "patrolling" configuration;
2) Custom configurations per your request.
== Who needs this feature and where can I see it? ==
Larger wiki communities will probably benefit more from the use of
this feature than smaller ones. If you have problems keeping vandalism
in check, and/or want to experiment with new ways to identify high
quality content, you should look into this functionality.
You can see an English language demo installation of the feature at:
http://en.labs.wikimedia.org/
The feature is in production use on the German Wikipedia:
http://de.wikipedia.org/
The German Wikipedia uses a custom configuration where the most recent
vandalism-patrolled version, if any, is shown to unregistered users.
You can track the progress of their use of the patrolling feature
here:
http://tools.wikimedia.de/~aka/cgi-bin/reviewcnt.cgi?lang=english
== Patrolling Configuration ==
In the Patrolling Configuration, any user who has been registered for
more than 21 days and has made at least 150 edits will be
automatically given the permission to patrol changes for vandalism.
Only changes made by users who are not permitted to patrol changes
need to be patrolled.
In addition, sysops will be given the permission to flag versions of
"featured articles" in accordance with existing nomination processes.
(In other words, this gives you the ability to identify specific
_versions_ of an article as "featured", rather than the article as a
whole.) Finally, sysops will be permitted to define on a per-page
basis that changes need to be patrolled before being visible to
unregistered readers. This is an alternative to semi-protection; it
doesn't make sense to use both on a given page.
The use of these features is subject to policies that your wiki
community will need to develop. They should be used carefully until
such a policy is in place.
To activate the patrolling configuration,
1) File a request on http://bugzilla.wikimedia.org/ of type
"enhancement", component "site request". You may need to create a
BugZilla account to do this.
2) Title your request "Enable FlaggedRevs Patrolling Configuration on
(my project name)".
3) Post a link to your BugZilla request to your project's "Village
pump" and mailing list, if available.
If there are no objections on the BugZilla page, the request will be
considered valid after 7 days. (It may still take a while longer to
process it.)
== Custom Configurations ==
The FlaggedRevs extension is highly flexible in its configuration. We
are willing to accommodate custom requests. Since some configurations
of FlaggedRevs could be considered highly disruptive, the requirements
are somewhat higher.
1) Read about the configuration options at:
http://www.mediawiki.org/wiki/Extension:FlaggedRevs
and experiment with the live demo at:
http://en.labs.wikimedia.org/
2) Create a page in the "Project:" namespace (e.g. "Wikipedia:",
"Wikibooks:") of your wiki community describing the configuration you
want to use.
3) Create a BugZilla request as above, titled "Enable FlaggedRevs
custom configuration on (my project name)" pointing to the proposal
page you have created. Provide an English translation of all relevant
information if possible - or we may not be able to help you.
4) Post a link to your proposal and to the BugZilla request to the
various relevant channels of your wiki community, e.g. "village pump",
mailing list.
If there are no objections within 14 days, your request will be
considered valid. If there are objections, please try building
consensus. If necessary, you can also resort to a poll (a very large
majority, at least two thirds, is generally necessary).
Note that custom configurations will take longer to process, and might
sit in the technical support queue for several weeks.
Our developers will _only_ look at the information attached to the
BugZilla request, so please make sure that everything relevant is at
least linked from there.
== Translators needed ==
The user interface of the FlaggedRevs extension needs to be translated
into as many languages as possible. The extension can be localized
using http://translatewiki.net/ - please follow the instructions there
to become a translator.
== User interface developers needed ==
If you are a PHP developer with JavaScript/CSS experience, your help
in improving the user interface experience (by improving the CSS or
adding AJAX features) would be appreciated. Just check out a fresh
copy of the MediaWiki code and the FlaggedRevs code and get started:
http://www.mediawiki.org/wiki/Subversionhttp://mediawiki.org/wiki/Extension:FlaggedRevs
If you need committer access to our version control system, please
e-mail <commitaccess at wikimedia dot org>, attaching your SSH key and
desired username as per the above link.
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
> Date: Wed, 4 Jun 2008 10:45:12 +0100
> From: "David Gerard" <dgerard(a)gmail.com>
> Subject: [WikiEN-l] Fwd: [Wikitech-l] TorBlock extension enabled
> To: "English Wikipedia" <wikien-l(a)lists.wikimedia.org>
>
> ---------- Forwarded message ----------
> From: Andrew Garrett <andrew(a)epstone.net>
> Date: 2008/6/4
> Subject: [Wikitech-l] TorBlock extension enabled
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> Hi all,
>
> After working through the code with Tim for a few hours this
> afternoon, the TorBlock extension has been enabled on Wikimedia.
>
> The TorBlock extension will override local IP blocks to provide a
> consistent treatment of tor. Currently, this involves allowing only
> logged-in users to edit, and requiring tor users to have 100 edits,
> and a 90-day-old account, prior to being autoconfirmed.
>
> Hopefully, this will provide a balance between allowing users to edit
> through tor without the difficult process of granting per-wiki IP
> block exemptions, and preventing pagemove vandals (such as the user
> known as 'Grawp' on English) from using Tor for vandalism and so on.
>
> I haven't yet implemented this, but I am interested in the prospect of
> marking Tor users as such on either CheckUser, or (privacy policy
> depending) on Recent Changes.
>
> --
> Andrew Garrett
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think this is a good idea, as far as soft-blocking or. However, the
"autoconfirmed, 100 edits, 90 days" is not, because the users with Tor
should be allowed to use it, if it protects them from privacy. It should not
be softblocked until an editor is an "experienced editor", because it is an
assumption of bad faith for Wikipedia to assume that an editor does not have
good intentions because they aren't "prolific".
I can understand if this is a cautionary measure, however just because an
editor hasn't made 100 edits and stayed there for 90 days, does not mean
they are vandals or sleeper accounts. This is a flaw in the proposal, and
should be fixed.
Jonas
A dump is indeed your best bet, especially if you intend to spider all of
2,400,000 articles.
In response to whether anything similar has been done before, you might
want to have a look at the six-degrees project
(http://toolserver.org/~river/pages/projects/six-degrees) which was a
replication-based implementation of something similar to what you're
suggesting. It's since been taken down, but there's a similar tool at
http://www.netsoc.tcd.ie/~mu/wiki/ ("find shortest paths") which queries
the last database dump for the closest path between two articles.
- H
Andrew Gray wrote (Wed 04/06/2008 11:00):
> 2008/6/4 Sylvan Arevalo <khakiducks(a)gmail.com>:
> > Oh and if anyone has suggestions on the best way to make the database
> > of hyperlinks that reference each other (spidering all of wikipedia,
> > or is there a better way to do it?)
>
> Spidering is bad!
>
> (It's both time-consuming for you and very annoying for us)
>
> You can get the dataset you're looking for via dumps.wikimedia.org - you
want the enwiki pagelinks.sql.gz file, I believe. Not entirely sure what
you'd do with it after that, but it ought to have the data you're looking
for in a suitably stripped-down form.
Going through AfD today, I was struck by frequent accusations of
'advertising' being thrown at articles about companies and commercial
products, and contributors to those articles. (The case I especially
noticed was [[Wikipedia:Articles for deletion/Roland System-100]], but
that's only one specific example; it's an endemic problem). I think
this is a problem, an assumption of bad faith, and an unnecessary
biting of newbies.
I think that Wikipedia being constantly bombarded by genuine spam has
put us in an overly defensive mindset, which is also fed by the
free-software anti-commercial attitude of some contributors. Spam is
when an article is created to garner publicity or hits. It's not
documenting anything anyone cares about, it's instead trying to give
false respectability to something our readers don't want to see.
We delete huge amounts of things as 'Spam' and 'Blatant advertising'
that are not. They are well-meaning attempts by someone who is
interested in something to document it in Wikipedia. By calling their
attempts to help by such names, we are burning people. We're taking
someone who might become a useful contributor and slapping them
because they had the temerity not to know the rules, including the
unwritten ones.
Some of these articles shouldn't be created at all, because no
reliable sources exist for them. If that's the case, that's what we
should tell the contributor. In other cases sources exist but the
creator didn't cite them; this is a cleanup issue. In yet other
cases, the information belongs in Wikipedia, but not where the
contributor placed it; an education issue. And yes, I realize that
workload means that new page patrollers etc. may have to work in a
hurry - templated messages that don't assume bad faith can be made,
and even deletions can be done without insulting.
In many cases what's deemed 'advertising' isn't advertising at all, as
in the above example; that Roland synth hasn't been sold in almost 30
years, and nobody's trying to make money by writing a Wikipedia
article about it. What's actually the case is that the article has
been written by someone who doesn't know our house style. It reads
like an article on a vintage-synths website, written by an enthusiast.
The difference between enthusiast-site writing and encyclopedia
writing has to be learned.
Can we start to not assume that peoples' motives are bad unless they
show that they are?
-Matt
In a message dated 6/2/2008 4:07:14 P.M. Pacific Daylight Time,
dgerard(a)gmail.com writes:
2008/6/3 David Goodman <dgoodmanny(a)gmail.com>:
> We update the database at the rate of about 30-35 percent per year. A
> third of the database is completely revised on a yearly basis thanks
> to the input of our contributors. That's something that is probably
> much more speedy than Wikipedia. Obviously Wikipedia cannot do that
> because they are several times as large as we are
And if they were half as big again, they could update twice as fast!>>
------------
Really Tiny Brittanica! For people who just can't be bothered with a lot of
things like concepts and thoughts and stuff!
I.NO.oO.U.R. !
Will
**************Get trade secrets for amazing burgers. Watch "Cooking with
Tyler Florence" on AOL Food.
(http://food.aol.com/tyler-florence?video=4&?NCID=aolfod00030000000002)