from_name: theProject

subject: [Wikipedia-l] Cannot access Thai Wikipedia from Thailand

body:
I did a whois lookup on both of them, and their ISPs are both in Thailand. I
strongly doubt a country-wide block.

theProject

On 8/29/06, Akash Mehta <draicone at gmail.com> wrote:
>
> Hmm... are you sure the proxy servers' IP's identify them as being in
> Thailand? Use your proxies to visit whatismyip.com and traceroute that IP
> using the tools at dnsstuff.com, it might clarify. Otherwise, maybe the
> block has been lifted?
>
> On 8/30/06, theProject <wp.theproject at gmail.com> wrote:
> >
> > Would this effect be replicable by using a proxy server in Thailand? I
> > just
> > tried a couple of proxy servers there and I can use them to load both
> > th-wiki and en-wiki, despite the ridiculous reduction in speed which I
> > think
> > is primarily due to using a proxy server. Mind you, that's just one
> proxy
> > server, and besides, I'm the last guy to ask about anything technical.
> :-)
> >
> > theProject
> >
> > On 8/29/06, Andrew Lih <andrew.lih at gmail.com> wrote:
> > >
> > > Wow, this is pretty serious. Do you think it could be a block? Has
> > > there ever been a block before of anything on the Internet in
> > > Thailand?
> > >
> > > -Andrew
> > >
> > > On 8/29/06, [LiM] Manop <manop at 6tub1.com> wrote:
> > > > Thank you for the reply. It seems that people from Thailand cannot
> > > access
> > > > Wikipedia in other languages as well as Thai Wikipedia; I and my
> > friends
> > > did
> > > > test in English (en), German (de), and Japan (ja). The problem
> occurs
> > in
> > > > other projects as well including Wiktionary, Wikisources.
> > > >
> > > > However I and my friends in Thailand can access to this site
> > > > https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page
> > > >
> > > > Manop
> > > >
> > > > On 8/29/06, Andrew Gray <shimgray at gmail.com> wrote:
> > > > >
> > > > > On 29/08/06, [LiM] Manop <manop at 6tub1.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I'm wondering if anyone have the same problem. Several of my
> > friends
> > > in
> > > > > > Thailand cannot access to Thai Wikipedia (
> http://th.wikipedia.org)
> > > today
> > > > > > since 4-5 hours ago. But I access from the USA, it works fine
> for
> > > me.
> > > > >
> > > > > Is it just th.wikipedia, or other language sites as well?
> > > > >
> > > > > --
> > > > > - Andrew Gray
> > > > >   andrew.gray at dunelm.org.uk
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > (LiM) Manop Kaewmoracharoen
> > > > 427 Town Engineering Bldg.
> > > > Iowa State University
> > > > _______________________________________________
> > > > Wikipedia-l mailing list
> > > > Wikipedia-l at Wikimedia.org
> > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > >
> > > _______________________________________________
> > > Wikipedia-l mailing list
> > > Wikipedia-l at Wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > >
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at Wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> >
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


list: wikitech-l

source: pipermail-mbox

from_name: Lars Aronsson

subject: [Wikitech-l] Template parameter statistics

body:
I don't know when I first heard the plans for wikidata, but one
year ago I proposed a more light-weight alternative approach on
the [[m:talk:Wikidata]] page. Then nothing happened, and today I
implemented it.  It's 98 lines of Perl that processes an XML dump
and extracts template call parameter values.  The source code can
be had from http://meta.wikimedia.org/wiki/User:LA2/Extraktor

The SQL dump of the templatelinks table already tells us which
pages calls which templates.  This script goes beyond that to get
information about each individual call parameter.

The output format is a very simple awk-friendly text file.  For
example, the German Wikipedia page [[de:Anthony Hope]] contains
the two template calls

   {{PND|11901842X}}
   {{Personendaten|
    NAME=Hope, Anthony
   |ALTERNATIVNAMEN=Hawkins, Anthony Hope
   |KURZBESCHREIBUNG=englischer [[Rechtsanwalt]] und [[Autor]]
   |GEBURTSDATUM=[[9. Februar]] [[1863]]
   |GEBURTSORT=[[London]]
   |STERBEDATUM=[[8. Juli]] [[1933]]
   |STERBEORT=
   }}

For this page, the output contains:

   PND|Anthony Hope|1|1|11901842X
   Personendaten|Anthony Hope|2|NAME|Hope, Anthony
   Personendaten|Anthony Hope|2|ALTERNATIVNAMEN|Hawkins, Anthony Hope
   Personendaten|Anthony Hope|2|KURZBESCHREIBUNG|englischer [[Rechtsanwalt]] und [[Autor]]
   Personendaten|Anthony Hope|2|GEBURTSDATUM|[[9. Februar]] [[1863]]
   Personendaten|Anthony Hope|2|GEBURTSORT|[[London]]
   Personendaten|Anthony Hope|2|STERBEDATUM|[[8. Juli]] [[1933]]
   Personendaten|Anthony Hope|2|STERBEORT|

As you can see, the |-separated fields are:

 1. Name of the template called
 2. Name of the page that called the template
 3. Sequence number of this call within the page
 4. Name or position number of the parameter
 5. Value of the parameter

The output for the entire German Wikipedia dump is

  bunzip2 <dewiki-20060803-pages-articles.xml.bz2 |
    perl extraktor.pl >de.params
  du -sm de.params

123 megabytes.  With some simple awk, I get the following
statistics:  There are

  awk '-F|' '{print $2,$3}' de.params | sort -u | wc -l

790,985 template calls using a total of

  wc -l de.params

2,076,178 parameters (on average 2.62 parameters per call) from

  awk '-F|' '{print $2}' de.params | sort -u | wc -l

397,929 different pages to

  awk '-F|' '{print $1}' de.params | sort -u | wc -l

13,295 different templates.  The most commonly supplied parameter
names over all templates are

  awk '-F|' '{print $4}' de.params | sort | uniq -c | sort -nr

NAME (113038 occurances), ALTERNATIVNAMEN (101799),
KURZBESCHREIBUNG (101723), GEBURTSORT (101706), GEBURTSDATUM
(101704), STERBEDATUM (101663), STERBEORT (101649), ID (10061),
ZEIT (6255), VORG?NGER (6210), NACHFOLGER (6210), AMT (6199),
EINWOHNER (5942), FL?CHE (5868), WEBSITE (5680), STAND_EINWOHNER
(5619), Name (5307), PJ (5242), PL (5240), LEN (5224), DS (5219),
OS (5214), OT (5152), MUSIK (5137), DT (5117), TITEL (4750),
INHALT (4739), PRO (4658), REG (4639), DRB (4627), AF (4568),
KAMERA (4557), SCHNITT (4516), Bild (4038), BILD (3562), PLZ
(3344), H?HE (3265), GEMEINDEART (3180), BREITENGRAD (3074),
L?NGENGRAD (3061), KANTON (3013), and NAME_ORT (3005).

Yes, the bad taste of all-caps parameter names is a disease of the
German Wikipedia since the early days of the Personendaten
project.  Personendaten is also the template that is called from
100,000 different pages.  Let's see which templates use the
parameter named GEMEINDEART (kind of municipality):

  awk '-F|' '$4 == "GEMEINDEART" {print $1}' de.templates |
    sort | uniq -c | sort -nr

Ort_Schweiz (2738 calls), Ortschaft_Schweiz (196),
Infobox_Slowakische_Gemeinde-K (121), Infobox_Slowakische_Gemeinde
(111), Ort_Liechtenstein (11), Infobox_Schweizer_Gemeinden (2),
Infobox_Deutsche_St?dte (1).

Let's see which kinds of municipalities there are in Slovakia:

  awk '-F|' '$1 == "Infobox_Slowakische_Gemeinde" &&
             $4 == "GEMEINDEART" {print $5}' de.templates |
    sort | uniq -c | sort -nr

Stadt (74), Stadtteil (21), Gemeinde (16).

And in Switzerland:

  awk '-F|' '$1 == "Ort_Schweiz" &&
             $4 == "GEMEINDEART" {print $5}' de.templates |
    sort | uniq -c | sort -nr

Gemeinde (2591), Stadt (126), Gemeinden (12).

Perhaps "Gemeinden" (a plural) is an error that should be fixed?
Let's see which twelve pages use this value for this parameter to
this template:

  awk '-F|' '$1 == "Ort_Schweiz" &&
             $4 == "GEMEINDEART" &&
             $5 == "Gemeinden" {print $2}' de.templates

Benken ZH, Flaach, Adlikon bei Andelfingen, Andelfingen ZH,
Berg am Irchel, Buch am Irchel, Dachsen, Dorf ZH, Feuerthalen,
Humlikon, Flurlingen, Henggart.

Hmm... It turns out that GEMEINDEART is not used in this infobox
template.  That's odd.  I'll leave it there.

I hope you get the point.  Of course you can use your favorite
SQL database instead of awk.  If you want speed, be sure to create
indexes for every column.

Imagine if there was a templateparameter table supported by
Mediawiki, then we could do this in real time.  I'm wysiwyg
filling out an infobox template here.  Which parameter names
should I supply?  Which values should I typically use?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


list: wikien-l

from_name: cohesion

subject: [WikiEN-l] USGS maps are liberated!

body:
On 8/30/06, Guillaume Paumier <guillom.pom at gmail.com> wrote:
> [ crossposting on wikien-l and commons-l ]
> Is there any project on Commons to upload these maps?
>
> g.

Not that I know of, I don't think they are completely uploaded yet,
but I would be glad to help if one gets started. I emailed the person
that did this and said we might be interested :) Apparently when the
upload is complete his project page will have more details about where
they are. There are a lot, so a commons project might be a good idea
:)


from_name: dmehkeri at swi.com

subject: [WikiEN-l] Policy across different languages

body:
>
> 5. _Wikipedia does not have firm rules_.  Good ol' IAR, here, boys. Much
>     as Certain People may complain about it, it's one of the pillars on
>     which rests our hopes and our success so far.
>
> Now, '4' and '5' can be regarded as peculiar to the English Wikipedia.

French Wikipedia AfD for IAR:
http://fr.wikipedia.org/wiki/Wikip?dia:Pages_?_supprimer/Wikip?dia:Ignorez_les_r?gles

I'm not sure what you would all have made of this if I just left it without
comment.

Instead I will mention that a translation of an old version of the english IAR
was already (and still is) written right into the main rules page.

I can easily see us getting entirely the wrong impression from the Russian
Verifiability thing.

Dan


list: commons-l

subject: [Commons-l] Fwd: [WikiEN-l] USGS maps are liberated!


list: wikipedia-l

from_name: Ray Saintonge

subject: [Wikipedia-l] "Drive-by tagging" advice needed

body:
Maury Markowitz wrote:

>I recently got into a minor squable that started with another example of
>what I refer to as "drive-by tagging". Basically someone comes by an article
>and inserts a whole bunch of tags without any comment. Some of these may be
>valid, others less so, but very often its impossible to know one way or the
>other without the original "tagger" pointing out the problems.
>
>For instance, consider this example I came across recently: Mirror Fusion
>Test Facility. The "tagger" inserted a needs cats and needs wikification.
>The cats one was entirely valid and I added one, but I can't for the life of
>me even imagine what needs additional wikification. It seems to follow the
>style guide perfectly. I wrote to the tagger, but he responded saying "by
>following the link within the tag for all you need to know about wikifying
>an article", which is a non-answer.
>
>I would like to hear any comments you all may have on this topic. Is it OK
>to simply remove vague tags if the article in question does not appear to
>have a problem related to the tag and there is no comment? I ask because, as
>I noted, the last time I removed tags the tagger then stamped the article
>with a PROD, their argument being that removing tags is PRODable.
>
The response to that may simply be "So fix it!"  The article says what
it says with or without categories or Wikification.  Neither are
essential.  Since the items that need additional Wikification are the
ones that he doesn't understand he is in the best position to do it. ...
but then it might not be practical to Wikify EVERY word. :-)

Ec


from_name: Brion Vibber

subject: [Wikitech-l] (no subject)

body:
hunterda at adelphia.net wrote:
> Can you please take my son off this mailing list. For some reason he is
> receiving numerous e-mails, probably due to his signing up mistakenly. So
> sorry for the trouble. Thank you.         Jill Aldridge

I've unsubscribed this address.

-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060830/d6d925bc/attachment.pgp>


subject: [Commons-l] Response from the USGS image purchaser

body:
>---------- Forwarded message ----------
>Hey Judson,
>
>Having them hosted on the commons had occurred to me as well.  They
>are raw tiff's, still with the map border, etc.  So it might be
>advantageous to make them easier to handle by a average wikipedia
>viewers.
>
>They are also about 300 GB in total.  So if you think it makes sense
>for the commons to host them, I can arrange to mail a hard drive with
>the data.
>
>Thanks,
>-jared

I emailed Jared (the person that bought the maps) just to say that
there was interest in uploading them to commons, and he offered to
mail a hard drive with all the images! I was thinking we would
probably just grab them from the Archive, but I thought I would let
everyone know of this offer in case anyone wanted to do it that way.

It is a lot of data, and in tiff format.


from_name: Simetrical

subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> But what if we logged a one-way hash of the IP address, that
> couldn't be correlated with anything else?

There are only about four billion possible IP addresses.  Anyone could
just do a brute-force execution of whatever hashing algorithm we use
on every IP address.  Really, though, there's no harm in storing IP
address-pageview links for a short period of time, like a day.

However, this wouldn't require that, and indeed, a server-side
solution would be impossible: 99.9% of page hits won't go to the
server to start with.  Since JavaScript is being used anyway, you can
just have the script only run the first time you visit a given page
per session.


from_name: Jay R. Ashworth

subject: [Wikitech-l] Disabling users

body:
On Wed, Aug 30, 2006 at 06:27:32PM +1000, Nick Jenkins wrote:
> The more interesting question is: If people can find a way of adding
> this type of functionality to the default install (but disabling it by
> default) so that it doesn't impact you, should it be added?

Why not?

Worst case: if you want to add something that the development team
feels is so fundamentally incompatible with their ethos (or, more
likely, so complicated and prone to increase suppot load :-) that they
Just Won't Put It In, either fork, or, more likely, just maintain it as
a patch/dropin, and track the releases.  It's *still* easier than
writing all of MediaWiki yourself.

> On the plus side, it'd most likely lead to more deployments of the
> software, and hence more people familiar with the syntax, and more
> people familiar with wikis in general, and what people get used to at
> work they tend to use at home too (with potential positive impact).
> On the negative side, maybe it's seen as complicating the software,
> and endorsing a feature that's opposed to the fundamental aim of open
> knowledge.

Well, at the risk of pissing people off, I'm gonna come down on the
"who gives a shit" side of that.

Someone has to be more Catholic than the pope, for progress to happen
-- but that's rms' job.

IMHO.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Mark Clements

subject: [Wikitech-l] Disabling users

body:
"Nick Jenkins" <nickpj at gmail.com> wrote in
message news:NABBJGECPILFNLFEAPIKOEINIMAA.nickpj at gmail.com...
> >
> > If MediaWiki doesn't fill your needs, and you can't patch it to do so,
> > you're welcome to use something else; Tim and brion won't be offended.
>
> [SNIP]
>
> Basically there's a tension between the real-world ways in which people
want to use MediaWiki the software "product", and the
> primary raison d'etre of MediaWiki as an open-to-everyone collaborative
platform.
>
> The more interesting question is: If people can find a way of adding this
type of functionality to the default install (but
> disabling it by default) so that it doesn't impact you, should it be
added?
>
> On the plus side, it'd most likely lead to more deployments of the
software, and hence more people familiar with the syntax, and
> more people familiar with wikis in general, and what people get used to at
work they tend to use at home too (with potential
> positive impact). On the negative side, maybe it's seen as complicating
the software, and endorsing a feature that's opposed to the
> fundamental aim of open knowledge.
>

Another thing to bear in mind is that if there are enough features wanted by
'business' or 'the real world' or whatever you want to call it, which the
developers deliberately avoid implementing then the project may end up
forking.

Whether this is a Good Thing or not, I guess depends on your persepective.

- Mark Clements (HappyDog)


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] WP:LIVING and "sensitivity" again

body:
geni wrote:
> On 8/29/06, David Gerard <dgerard at gmail.com> wrote:
>> Yes. Bluntly, most of our articles about pop cultural figures need an enema.
>
> Evedences?
>

People keep adding badly-spelt one-liners to them.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060830/886324e5/attachment.pgp


from_name: Andrew Gray

body:
On 30/08/06, David Gerard <dgerard at gmail.com> wrote:
> On 30/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> > On 8/29/06, Sam Korn <smoddy at gmail.com> wrote:
>
> > > I don't think anyone is contesting these issues.  The only issue under
> > > contention is whether this should be stated explicitly for fear of
> > > causing even more hagiography.
>
> > I think it already *is* stated. On the other hand, I wouldn't mind the
> > bit about not including birthdate information for fear of "identity
> > theft" being removed - sheer paranoia.
>
> The *what*? That's bloody stupid.

It may or may not surprise you to know that that is a surprisingly
common reason for asking "please do not list my birthdate"...

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


subject: [Wikitech-l] Disabling users

body:
On Wed, Aug 30, 2006 at 12:01:20PM +0100, Rob Church wrote:
> On 30/08/06, Michael Bimmler <mbimmler at gmail.com> wrote:
> > Okay. Seems I misread which bug/feature you were talking about.
>
> I have stated, and continue to maintain, that to implement strong,
> per-page access controls, to the level that some organisations
> require, within MediaWiki would require a considerable rewrite and a
> rethink of a lot of aspects of the software, and that such a change
> would *not* be consistent with the purpose and intended use case for
> MediaWiki.

"... for it's primary development customer, the Wikimedia Foundation,
who are paying the bills."  But I undersatdn your point, entirely, Rob;
don't take that as a challenge.

> Organisations which "cannot implement MediaWiki" because of this
> should seek an appropriate document management solution for their
> needs, that is, obtain (purchase, if needs be - it would be worth it)
> software that was *written for their intended use*. MediaWiki as a
> project isn't seeking to become the world's #1 commercially-used wiki
> package.

Quite so.

I'm very fond of WebGUI, which has one of the two major wikiattributes,
easy page creation and version tracking/revert, now.  Adding the other
one.

The other attribute -- easier text markup through wikitext -- it does
not have, but it wouldn't be that hard to add.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Timwi

subject: [WikiEN-l] [[Template:FA/BeenOnMainPage]]

body:
Hi,

please take a look at this:

http://en.wikipedia.org/w/index.php?title=Template:FA/BeenOnMainPage&action=history

The template causes pages to become invalid XHTML. (Not in a majorly
serious way, but still.) I fixed that. Unfortunately, it breaks the CSS
rules people have put into their user CSS to style it. Thus I was reverted.

What is the proper avenue for this kind of situation? The "normal user"
will, of course, just think I broke it and revert it, without caring
about XHTML conformance. The correct way however required for those
users to fix their CSS. What do I do?

Timwi


from_name: Aerik Sylvan

subject: [Wikitech-l] hitcount stats

body:
Whoa!  I missed the announcement of implementing the marvelous new
hitcounter.  What happened to concerns about spoofing hits by way of
bypassing the sampling - is it a non-javascript thingy that is therefore
impervious to spoofing?  I'd love to see the logic/code.

Just to add to the "logging hashed versions of ip addresses" fray:  we could
recreate and overwrite the supersecret key daily (or even hourly).  It then
occurs to me that you could theoretically use this, along with the stats of
consistently popular pages, to try to decrypt the hash, but that's gotta be
a fantastically difficult.  You could further mix it up by changing the hash
every day (is that stupid?  sounds like a good idea).  Then, you could see
multiple views of a really popular page by the same guy (he'd have to have a
*lot* of views, to be picked up through the sampling rate).  Any holes in
this logic?  Fun to think about.

Regards,
Aerik


subject: [Wikitech-l] hitcount stats

body:
On Wed, Aug 30, 2006 at 05:24:51PM +0200, Steve Bennett wrote:
> On 8/30/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> > However, this wouldn't require that, and indeed, a server-side
> > solution would be impossible: 99.9% of page hits won't go to the
> > server to start with.  Since JavaScript is being used anyway, you can
> > just have the script only run the first time you visit a given page
> > per session.
>
>
> Actually now that I think about this, does this actually sufficiently model
> the data we want to collect? Are we interested only in "how many people
> visit a certain page" and not also in "how many times a certain page is
> viewed"? If 5 users spend a whole day arguing back on forth on Wikipedia
> talk:Pok?mon, is 5 or 200 a more interesting/useful/relevant metric for that
> page?

Yes.

> We should probably start thinking about exactly why we want this data, and
> what we should do with the results of it.

Indeed; they're two separate, and both useful, measurements needed by
different audiences.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Andrew Lih

subject: [WikiEN-l] [Wikipedia-l] "Approved" versions on Wikipedia FAQ

body:
Does this make the 5 minute cut? :)

I think the premise of the FAQ is off in its current form. I am
worried by the "we" part, meaning the mythical monolithic Wikipedia
community. (ie. Why not make this an opportunity to show that
Wikipedias have their distinct culture and are at different stages of
development?)

I think the announcement should make clear:
- There has always been a desire for a better reader experience
- The larger Wikipedia communities have turned their attention from
growth to quality
- The German Wikipedia has initiated an experiment with a
"nonvandalized" and "checked" versions (nb: terminology may need to be
tweaked)
- This "potentially" may allow for a mechanism other than blunt
protection for preventing vandalism
- The greater Wikipedia community hopes to learn from this pilot project
- The English and other Wikipedias, with their own norms and cultures,
may or may not adopt the German initiatives

PS: Would be nice to have a pointer to a meta page (if it exists)
describing the German initiative. If I had not attended the Wikimania
2006 summit on the top floor of Pound Hall with Danny, Kurt, G.
Maxwell, Jimmy, Raul654, Kelly Martin, et al, I would not have known
these things. And I'm a bit concerned we're neglecting to use the wiki
to share this knowledge.

-Andrew (User:Fuzheado)

On 8/30/06, David Gerard <dgerard at gmail.com> wrote:
> This is in response to the somewhat silly English-language press we've
> had lately. I'll be sending copies of this out to the sources of
> recent articles on the subject that got it precisely backwards.
>
> The following is, I understand, technically accurate, based on text
> from Amgine, Phillipp Birkin (de:wp), Jimbo and Mathias Schindler (I
> think), and comcom discussions (press relations being part of that
> job). Corrections welcomed - you have about five minutes.
>
> (and geni, I expect you to ask how this makes the new patrollers' jobs
> easier - by having what's effectively a feed of new-editor and
> anonymous edits, is what I was thinking of.)
>
>
> - d.
>
>
> "Approved" versions on Wikipedia FAQ
>
>
> * What is changing?
>
> We want to open up editing without damaging the reader's experience.
>
> We want to be more wiki and let editors edit freely, which is where
> all the good things come from. At present a small percentage of
> articles (a few hundred out of 1.5 million on the English language
> Wikipedia, http://en.wikipedia.org/) are locked or partially locked
> from editing. We want to open these up. But Wikipedia is a top 20
> website (Alexa ratings, no. 17 on 3 month average; no. 15 on 30 August
> 2006 - http://www.alexa.com/), so we must keep it good for the
> readers.
>
> The new feature will mean that edits from new or anonymous editors
> will be delayed before being shown to readers - they will see a
> 'flagged OK' version by default, with a link to the live version. The
> idea is to enhance the *reading* experience, and free us to enhance
> the *editing* experience. If vandalism can't be seen by the general
> public, there will be less motivation to vandalise.
>
> Anonymous or new-editor edits will need to be approved by a logged-in
> editor. Of the thousands of editors on the large Wikipedias, many
> concentrate on checking revisions and dealing with odd changes and
> vandalism - this will assist their work and we do not expect new
> delays.
>
> We are also considering a related feature to flag particular versions
> of articles as being of high quality. This is to a different end: a
> high-quality finished product. This will likely be tested first on the
> German language Wikipedia (http://de.wikipedia.org/), which has
> already had three stable editions released on CD and DVD, which have
> sold quite well. If the feature works there, it may be used on other
> language Wikipedias.
>
> These features are not finished, so we don't have a lot of fine detail
> as to how it will all work as yet. But we hope this change will allow
> us to do things such as open up the George W. Bush article or even the
> front page itself to full unrestricted editing.
>
>
> * When was this proposed?
>
> Jimmy Wales asked for a time-delay feature for casual readers in late
> 2004; after very fast editing on the Indian Ocean tsunami produced a
> very high-quality article
> (http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake) very
> quickly, but with some highly visible vandalism; we've hotly discussed
> how to achieve stable high-quality editions of Wikipedia since almost
> the start of the project, in 2001.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] "Approved" versions on Wikipedia FAQ


from_name: Steve Summit

subject: [Wikitech-l] hitcount stats

body:
Simetrical wrote:
> On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
>> But what if we logged a one-way hash of the IP address, that
>> couldn't be correlated with anything else?
>
> There are only about four billion possible IP addresses.  Anyone could
> just do a brute-force execution of whatever hashing algorithm we use
> on every IP address.

Well, no, not just "anyone". :-)

> Really, though, there's no harm in storing IP
> address-pageview links for a short period of time, like a day.

I would tend to agree.  But three people at AOL lost their jobs
because of something they honestly thought there was "no harm" in
doing.  And it's very difficult (if not impossible) to guarantee
that something gets kept for only a day.

> However, this wouldn't require that, and indeed, a server-side
> solution would be impossible: 99.9% of page hits won't go to the
> server to start with.

Not sure what you mean here.

> Since JavaScript is being used anyway, you can just have the script
> only run the first time you visit a given page per session.

But that would be considerably more work to implement, and would
require arbitrary amounts of state kept in the browser, and would
break down if the browser were restarted (or perhaps just if the
tab or window were closed).


from_name: Rob Church

subject: [Wikitech-l] Disabling users

body:
On 30/08/06, Michael Bimmler <mbimmler at gmail.com> wrote:
> Hm. Example from Wikimedia environment:
> There are more and more private wikis which are only for members of
> boards (wmf/chapters) or committees or internal.wikimedia etc. I think
> it would be definitely nice to have an option to disable a user's
> account (as in he can't see any pages anymore and is treated as if he
> had none account at this private wiki) e.g. if he retires from this
> board/committee/whatever.

I'm not disputing the account locking feature.

Rob Church


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> Well, no, not just "anyone". :-)

Anyone *could*.  Most people just wouldn't know *how*.

> I would tend to agree.  But three people at AOL lost their jobs
> because of something they honestly thought there was "no harm" in
> doing.  And it's very difficult (if not impossible) to guarantee
> that something gets kept for only a day.

If it's possible to guarantee it gets kept, it's possible to guarantee
it only gets kept for a day.

> > However, this wouldn't require that, and indeed, a server-side
> > solution would be impossible: 99.9% of page hits won't go to the
> > server to start with.
>
> Not sure what you mean here.

What effect would it have if I reloaded the page fifty times?  I
wouldn't send fifty messages to the view-logging server instead of
one; I would have a 4.88% chance of sending *one* message, rather than
a 0.1% chance.  The server doesn't know that I reloaded the page fifty
times: it just knows that it was told I visited it an *average* of
1000 times (averaging it with non-hits).  It can't, therefore, discard
the extra 49 page loads; it never received them.  The client has to
discard them if anyone's going to.

> But that would be considerably more work to implement, and would
> require arbitrary amounts of state kept in the browser, and would
> break down if the browser were restarted (or perhaps just if the
> tab or window were closed).

That's not a bug, it's a feature: it shouldn't be the same page hit if
I leave and then return.  And more work than "impossible" is rather
difficult.


subject: [Wikitech-l] hitcount stats

body:
Steve Bennett wrote:
> Actually now that I think about this, does this actually sufficiently model
> the data we want to collect? Are we interested only in "how many people
> visit a certain page" and not also in "how many times a certain page is
> viewed"? If 5 users spend a whole day arguing back on forth on Wikipedia
> talk:Pok?mon, is 5 or 200 a more interesting/useful/relevant metric
> for that page?

Me, I think I'm much more interested in the former.  Among other
things, it's an objective measure of something at least vaguely
akin to the elusive concept of "notability", and one big reason
for filtering out multiple hits from the same browser is therefore
to make it harder for people to deliberately skew the statistic.

The latter statistic -- assuming the argument takes the form of
actual edits -- is already derivable directly from the page
history, isn't it?


from_name: Gregory Maxwell

subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> One significant potential source of error in Leon's (marvelous!)
> new hitcount stats is the possibility that one reader is for
> whatever reason fetching the same page multiple times (perhaps
> due to nothing more than a prolonged edit).
[snip]

No.

The tool measures estimated views rather than unique impressions, thus
this is not an error. Someone sitting around hitting reload over and
over again is additional views, thus such actions should be sampled
just as often as any other view.

The major source of error in this is that we are sampling at far too
low a rate.  We believe that page view distribution for wikipedia is
power law. As such, course sampling will only be able to tell us
useful data about the relative ranking of the most popular items, so
it's good that the web interface only displays the top 1000 at most...
However, with only 34,000 samples collected of enwiki viewing over
four days much of the samples are scattered randomly around pages deep
into the tail which we can't not speak about accurately.

Changes will be made so that we can substantially increase the sampling rate.

I pity the journalist who sees our data and runs an absolutely idiotic
story based on it.


subject: [Wikitech-l] Disabling users

body:
On 30/08/06, Michael Bimmler <mbimmler at gmail.com> wrote:
> Okay. Seems I misread which bug/feature you were talking about.

I have stated, and continue to maintain, that to implement strong,
per-page access controls, to the level that some organisations
require, within MediaWiki would require a considerable rewrite and a
rethink of a lot of aspects of the software, and that such a change
would *not* be consistent with the purpose and intended use case for
MediaWiki.

Organisations which "cannot implement MediaWiki" because of this
should seek an appropriate document management solution for their
needs, that is, obtain (purchase, if needs be - it would be worth it)
software that was *written for their intended use*. MediaWiki as a
project isn't seeking to become the world's #1 commercially-used wiki
package.

I do not, however, dispute the other bug report; that which calls for
locking and hiding of certain accounts, since I accept it would be
useful to the main audience at which MediaWiki is targetted; the
Wikimedia projects.

Rob Church


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Rob Church <robchur at gmail.com> wrote:
> I plead ignorance, sir. Do provide a URL?

I believe you introduced me to www.justfuckinggoogleit.com, Rob.  ;)

http://news.google.com/news?q=AOL+logs


subject: [Wikitech-l] [MediaWiki-CVS] SVN: [16282] trunk/phase3

body:
On 30/08/06, brion at svn.leuksman.com <brion at svn.leuksman.com> wrote:
> Revision: 16282
> Author:   brion
> Date:     2006-08-30 03:56:17 -0700 (Wed, 30 Aug 2006)
>
> Log Message:
> -----------
> * Fix bug in wfRunHooks which caused corruption of objects in the hook list
> References EVIL! Not needed anymore in PHP 5 anyway.

Oh, thank fuck. I thought for a moment that a recent commit of mine to
Parser.php had screwed up the software, but couldn't find the
problematic change - all I could determine was that, for me, it seemed
to trigger when Cite was active.

It's wonderful what PHP will chuck out as HTML output when it
encounters "interesting" bugs like this. :)

Rob Church


list: foundation-l

from_name: Jeff V. Merkey

subject:
[Foundation-l] Fwd: NYTimes.com: African Languages Grow as a
 Wikipedia Pr...

body:
Jimmy Wales wrote:

>Delirium wrote:
>
>
>>A non-paternalistic attitude would be to treat African languages like we
>>treat all other languages.  Even though quite a few Westerners are
>>interested in the subject of spreading information in China, for
>>example, the Chinese-language projects have been run by Chinese speakers.
>>
>>
>
>Ok.  But that's because there *is* a Chinese community, quite healthy
>and active.
>
>It is a bit harder when, 5 years on, we seen little signs of life, and
>some good ideas about why we don't see signs of life.  In such cases, I
>think it is not paternalistic to think about how we can proactively help
>to create a community there.  A community, I hasten to add, of native
>speakers.
>
>

Yep.

>--Jimbo
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>


list: wikimedia-l


subject: [Wikitech-l] hitcount stats

body:
Simetrical wrote:
> On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
>> Well, no, not just "anyone". :-)
>
> Anyone *could*.  Most people just wouldn't know *how*.

Ah.  So you can high jump 8 feet, can you?

>> And it's very difficult (if not impossible) to guarantee
>> that something gets kept for only a day.
>
> If it's possible to guarantee it gets kept, it's possible to guarantee
> it only gets kept for a day.

False (unless you're splitting hairs).

>>> However, this wouldn't require that, and indeed, a server-side
>>> solution would be impossible: 99.9% of page hits won't go to the
>>> server to start with.
>>
>> Not sure what you mean here.
>
> What effect would it have if I reloaded the page fifty times?
> I wouldn't send fifty messages to the view-logging server instead
> of one; I would have a 4.88% chance of sending *one* message,
> rather than a 0.1% chance.

Okay, but that's true only as long as (a) the stats factor is in
the thousands, which it doesn't have to be (and isn't for some
wikimedia projects, and (2) nobody's trying to deliberately skew
the results.  But also, it only *matters* if you're trying to
keep (not discard) the extra hits, i.e. if you do want to say
something like "M people viewed it N times" as opposed to
"M people viewed it at least once".  If you're interested in
discarding redundant hits, it obviously doesn't matter whether
the browser or the server does it.


from_name: Anthony

subject: [WikiEN-l] "Approved" versions on Wikipedia FAQ

body:
On 8/30/06, David Gerard <dgerard at gmail.com> wrote:
> We want to be more wiki and let editors edit freely, which is where
> all the good things come from.
>
That's no less of a insincere statment than it was the first time
Jimbo decided to restrict editing and call it becoming more open.

> Anonymous or new-editor edits will need to be approved by a logged-in
> editor.

Non-logged in editors are not anonymous.  In fact, the only way to
effectively be anonymous is to create an account for every edit and
log in.

Anthony


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> There are only about four billion possible IP addresses.  Anyone could
> just do a brute-force execution of whatever hashing algorithm we use
> on every IP address.  Really, though, there's no harm in storing IP
> address-pageview links for a short period of time, like a day.
[snip]

H(secret + ip)  can only be inverted by exhaustive search of both the
secret and the IP (or the secret if you happen to have some known H(),
IP pairs)... and the secret can be much longer than 32 bits.

However the fuss about the AOL logs showed that, at least for search
strings, mere correlation of requests was enough to leak too much
data.   I do not believe that the same is true for page hits, but
thats the consideration.

To me it seems a bit foolish of an argument though... any one of our
admins could add such a bug... any upstream ISP could sniff the
traffic.... and we all know that the US Government is already doing
so. ;)  but it is what it is..... and for some reason people don't
like the prospects of the world figuring out that they have a venereal
disease. Silly people.


body:
On 8/30/06, cohesion <cohesion at sleepyhead.org> wrote:
> I emailed Jared (the person that bought the maps) just to say that
> there was interest in uploading them to commons, and he offered to
> mail a hard drive with all the images! I was thinking we would
> probably just grab them from the Archive, but I thought I would let
> everyone know of this offer in case anyone wanted to do it that way.
>
> It is a lot of data, and in tiff format.

Anyone know the status of Djvu support in mediawiki?  I know brion was
working on it for Wikisource.

Djvu would be the most correct format for the distribution of this data.


from_name: Maury Markowitz

body:
I recently got into a minor squable that started with another example of
what I refer to as "drive-by tagging". Basically someone comes by an article
and inserts a whole bunch of tags without any comment. Some of these may be
valid, others less so, but very often its impossible to know one way or the
other without the original "tagger" pointing out the problems.

For instance, consider this example I came across recently: Mirror Fusion
Test Facility. The "tagger" inserted a needs cats and needs wikification.
The cats one was entirely valid and I added one, but I can't for the life of
me even imagine what needs additional wikification. It seems to follow the
style guide perfectly. I wrote to the tagger, but he responded saying "by
following the link within the tag for all you need to know about wikifying
an article", which is a non-answer.

I would like to hear any comments you all may have on this topic. Is it OK
to simply remove vague tags if the article in question does not appear to
have a problem related to the tag and there is no comment? I ask because, as
I noted, the last time I removed tags the tagger then stamped the article
with a PROD, their argument being that removing tags is PRODable.

Maury


body:
On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> That's no less of a insincere statment than it was the first time
> Jimbo decided to restrict editing and call it becoming more open.

Jimbo did? Really.  Jimbo really gets around.

> Non-logged in editors are not anonymous.  In fact, the only way to
> effectively be anonymous is to create an account for every edit and
> log in.

Technically, the word anonymous means without a name.


from_name: Matt Brown

body:
On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> Of course the fact that it's not useful information combined with the
> fact that it's almost never an easily verified fact is an equally good
> reason.

Agreed.  However, if the birthdate is already public information, I
see no point in censoring Wikipedia about it.  Verifiability works
quite well in this regard; if it's already in reliable source
material, then the cat is out of the bag and deleting it from
Wikipedia serves no practical good.

-Matt


body:
On 30/08/06, Steve Bennett <stevage at gmail.com> wrote:
> On 8/30/06, Rob Church <robchur at gmail.com> wrote:
> >
> > Oh, thank fuck. I thought for a moment that a recent commit of mine to
> > Parser.php had screwed up the software, but couldn't find the
> > problematic change - all I could determine was that, for me, it seemed
> > to trigger when Cite was active.
> >
>
> This fixes the recent problems with duplicate refs?

According to the bug report, although the fuck-up I was observing on
the local test wiki was a little more...erm, well, it was a little bit
more severe.

Rob Church


body:
On 8/30/06, Timwi <timwi at gmx.net> wrote:
> The template causes pages to become invalid XHTML. (Not in a majorly
> serious way, but still.) I fixed that. Unfortunately, it breaks the CSS
> rules people have put into their user CSS to style it. Thus I was reverted.

Surely "class" instead of "id" should be used; that's exactly what the
XHTML specs call for, I believe - 'class' is designed for when this is
one of possibly many elements that should be treated as a group.

-Matt


subject: [Wikitech-l] hitcount stats

body:
Simetrical wrote:
>On 8/30/06, Rob Church <robchur at gmail.com> wrote:
>>On 30/08/06, Steve Summit <scs at eskimo.com> wrote:
>>> I would tend to agree.  But three people at AOL lost their jobs
>>> because of something they honestly thought there was "no harm" in
>>> doing.  And it's very difficult (if not impossible) to guarantee
>>> that something gets kept for only a day.
>>
>> I plead ignorance, sir. Do provide a URL?

To the personnel implications of the AOL debacle:

	http://www.theregister.co.uk/2006/08/30/online_anonymity/
	http://www.ovum.com/news/euronews.asp?id=4770

To my claim about data retention:

	http://catless.ncl.ac.uk/Risks/23.76.html#subj1

> I believe you introduced me to www.justfuckinggoogleit.com, Rob.  ;)

Heh.  Hadn't come across that one before.  Thanks.

Actually, even though the story was (it seemed) all over the
media last week, it was surprisingly hard to find more than a
couple of hits today.  Besides "AOL" and "CTO" and "resign",
another couple of keywords to use for anyone who wants to read
further would be "Maureen McGovern".


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> > If it's possible to guarantee it gets kept, it's possible to guarantee
> > it only gets kept for a day.
>
> False (unless you're splitting hairs).

// If you remove the line after the next or refactor this code, we will
// flay the living flesh from your bones
$db->write("$IP visited this page, yay")
$db->check_if_stuff_is_over_a_day_old_and_deal_with_it();
// If you remove the above line or refactor this code, we will flay the
// living flesh from your bones

> Okay, but that's true only as long as (a) the stats factor is in
> the thousands,

No, it's true as long as it's above one.  Even if it's just two,
someone making two page views would have a 75% chance of getting one
hit through, instead of a 50% chance: a major difference.

> (2) nobody's trying to deliberately skew
> the results.

If anybody is, we're screwed anyway if we're doing sampling.

> But also, it only *matters* if you're trying to
> keep (not discard) the extra hits, i.e. if you do want to say
> something like "M people viewed it N times" as opposed to
> "M people viewed it at least once".

Um, this entire discussion is about the latter.

> If you're interested in
> discarding redundant hits, it obviously doesn't matter whether
> the browser or the server does it.

Except that the server can't do it.

On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> H(secret + ip)  can only be inverted by exhaustive search of both the
> secret and the IP (or the secret if you happen to have some known H(),
> IP pairs)... and the secret can be much longer than 32 bits.

Except that presumably anyone with access to the actual encoded IPs
will have access to the secret as well, yes?  Or are we talking about
letting *anyone* see the encoded IP-pageview correlations?  In which
case, that is kind of a privacy violation, in the AOL style.

(You could always change the secret, of course . . . first check if
H(secret(1) + ip) exists, and if it does, use H(secret(2) + ip)
instead if that doesn't exist, and so forth . . . but then there's no
point in making it public, and we're back to the "anyone who knows the
encoded IPs knows the secret anyway" thing.)


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > H(secret + ip)  can only be inverted by exhaustive search of both the
> > secret and the IP (or the secret if you happen to have some known H(),
> > IP pairs)... and the secret can be much longer than 32 bits.
>
> Except that presumably anyone with access to the actual encoded IPs
> will have access to the secret as well, yes?  Or are we talking about
> letting *anyone* see the encoded IP-pageview correlations?  In which
> case, that is kind of a privacy violation, in the AOL style.

It can be easily configured so that anyone with access to the secret
has privileged access to the server and, already, anyone with
privileged access to the server could be logging IPs.


from_name: Michael Bimmler

subject: [Wikitech-l] Disabling users

body:
On 8/29/06, Rob Church <robchur at gmail.com> wrote:

> The referenced bug is a long standing feature request that we don't
> have plans to implement, owing to the fact that it contradicts a lot
> of the "ethos" of MediaWiki; its purpose and concept.
>
Hm. Example from Wikimedia environment:
There are more and more private wikis which are only for members of
boards (wmf/chapters) or committees or internal.wikimedia etc. I think
it would be definitely nice to have an option to disable a user's
account (as in he can't see any pages anymore and is treated as if he
had none account at this private wiki) e.g. if he retires from this
board/committee/whatever.
Michael
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> It can be easily configured so that anyone with access to the secret
> has privileged access to the server and, already, anyone with
> privileged access to the server could be logging IPs.

Yes, but again, there's no good reason to allow anyone without
privileged access to the server to see the IPs in the first place,
encoded or not, so why bother encoding them for storage?  *If* you're
going to allow people to view the connections the way AOL did, you may
as well assign arbitrary numbers (say, chronologically) rather than
some encoded form of the IP, since that's easier to implement *and*
more secure, if only marginally.


from_name: Mark Gallagher

body:
G'day David,

> What is the rationale for dumping verifiability, and what cracksmoking
> maniacs thought this was a good idea and why?

I think --- based on one of Kirill (thanks!)'s quotes --- the thing is,
they already *have* "we are an encyclopaedia" and "we don't do original
research" as principles, and they're trying to decide whether or not to
copy a supporting policy for NOR across as well; it's not a case of "why
don't we get rid of this?" but "why do we need this extra thing?".  No?

If that's correct, I can understand why they'd be wary.  There is always
--- rightly so[0] --- resistence even to codifying "editing best
practices" because some fuckwit out there is going to misunderstand what
it means and insist his version be enforced with a sledgehammer[1].

It doesn't mean they're abandoning a core principle, necessarily.  As I
see it, the core principles of English Wikipedia are:

1. _Wikipedia is an encyclopaedia_.  This implies some things, such as
    we're a tertiary source, we don't fill our project with crap.

2. _Wikipedia is neutral_.  That Wikipedia adopts a neutral point of
    view is crucial to the success of an international, stable project.

3. _Wikipedia is free content_.  Everything we do on Wikipedia is
    available under the GFDL or equivalent (I prefer the phrase "less
    silly") licence.  We don't infringe copyrights: creating stuff (text,
    images, sounds) for Wikipedia is called "generating free content";
    taking existing stuff and pretending we have a right to it[2] is
    called "bald-faced theft".

4. _Wikipedia contributors try to avoid being dicks_.  I should hope
    this is self-explanatory, however many policies people cruft --- I
    mean craft --- to help out.

5. _Wikipedia does not have firm rules_.  Good ol' IAR, here, boys. Much
    as Certain People may complain about it, it's one of the pillars on
    which rests our hopes and our success so far.

Now, '4' and '5' can be regarded as peculiar to the English Wikipedia.
I don't know if they are or not (they're so gosh darn sensible I'd
*hope* the other languages use them as well), but if people on, say, the
Polish Wikipedia run around being dicks to each other I'm not going to
lose any sleep.  However, '1', '2', and '3' are *absolutely essential*.
  These three are the raison d'?tre of the international Wikipedia
project, and for them to vanish from any sub-project would be very sad
indeed.

The question is: do Russian Wikipedia plan to abandon the notion of
encyclopaedia as a tertiary source, or are they just saying they don't
want more process?

[0] I may be biased there.

[1] Maybe I'm being overly cynical.  After all, English Wikipedia has
     been groaning with the strain of so many policies for a while now,
     and yet nobody's ever done *this* ... right?

[2] As opposed to *actually* having a right to it under fair use, of
     course!

--
"You can't fight a war on terror if you're ending a sentence with a
preposition."
- John Hodgman on /The Daily Show/


subject: [WikiEN-l] Fighting over (R) and (tm) symbols

body:
On 8/30/06, Daniel R. Tobias <dan at tobias.name> wrote:
> It is my impression (IANAL) that such usages are not necessary, nor
> are they standard in English-language writing style, when the usage
> is of a journalistic or encyclopedic nature rather than as part of
> marketing materials.  After all, Wikipedia has many articles, like
> [[Coca-Cola]], that are named after trademarks, but don't display the
> symbols demanded by the lawyers.

As far as I recall, there is no legal requirement to use either
symbol.  (r) and ? are used by trademark holders to inform you that
they consider the terms trademarks.  It is not commonplace to use
those symbols when you are NOT claiming trademark status on the terms
yourself.

-Matt


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > It can be easily configured so that anyone with access to the secret
> > has privileged access to the server and, already, anyone with
> > privileged access to the server could be logging IPs.
>
> Yes, but again, there's no good reason to allow anyone without
> privileged access to the server to see the IPs in the first place,
> encoded or not, so why bother encoding them for storage?  *If* you're
> going to allow people to view the connections the way AOL did, you may
> as well assign arbitrary numbers (say, chronologically) rather than
> some encoded form of the IP, since that's easier to implement *and*
> more secure, if only marginally.

It's not easier to impliment numbering IPs, actually. Hashing is memoryless.

The reason to use it for storage is the above mentioned paranoia about
being able to make sure things are not retained too long....

It's all a silly and pointless argument in my view, and it's really
off topic for this list.


from_name: Simetrical

subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> It's not easier to impliment numbering IPs, actually.

Autoblock messages use the table row number.  :)


subject: [Wikitech-l] hitcount stats

body:
Simetrical wrote:
> On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
>>>Simetrical wrote:
>>> If it's possible to guarantee it gets kept, it's possible to guarantee
>>> it only gets kept for a day.
>>
>> False (unless you're splitting hairs).
>
> // If you remove the line after the next or refactor this code,
> // we will flay the living flesh from your bones
> $db->write("$IP visited this page, yay")
> $db->check_if_stuff_is_over_a_day_old_and_deal_with_it();

You forgot

	// If you make a copy of $db on your laptop for testing,
	// we will flay the living flesh from your bones

and more importantly

	// We are holding everyone on the planet hostage to ensure
	// that they never make backups of $db, but if something
	// happens to us, you're on the hook for that, too.

>> (2) nobody's trying to deliberately skew
>> the results.
>
> If anybody is, we're screwed anyway if we're doing sampling.

Actually, we were both wrong on that.  It's "If anyone's trying to
deliberately skew the results, we're screwed if we're doing hashing."

>> If you're interested in discarding redundant hits, it obviously
>> doesn't matter whether the browser or the server does it.
>
> Except that the server can't do it.

One of us is being very obtuse here, but I'm not sure which.

If I'm trying to count "approximate number of people who have
viewed the page at least once", without possibly overcounting
people who have viewed the page multiple times, then depending on
the numbers it may be true that the server probably doesn't have
to, but under other circumstances it might very well have to,
and it's certainly strange to say that it "can't".

Saying "the server can't do it" is sort of like saying "Javier
Sotomayor can't high jump seven feet".


body:
On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> > That's no less of a insincere statment than it was the first time
> > Jimbo decided to restrict editing and call it becoming more open.
>
> Jimbo did? Really.  Jimbo really gets around.
>
Did what?  You deny he's restricted editing in the past, or that he
called it becoming more open?

> > Non-logged in editors are not anonymous.  In fact, the only way to
> > effectively be anonymous is to create an account for every edit and
> > log in.
>
> Technically, the word anonymous means without a name.

So a user who logs in as "88 dot 33 dot 23 dot 23" is anonymous?


body:
jayjg wrote:
> It appears that Russian Wikipedia is about to reject Verifiability as a policy:
>

In Soviet Russia, Wikipedia verifies YOU!

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060830/565b1b25/attachment.pgp


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > It's not easier to impliment numbering IPs, actually.
>
> Autoblock messages use the table row number.  :)

Do you have any clue about the details of the counter's internal operations?

Why must you argue with someone who does?

--
Greg
(Who is tired of this idiotic speculation)


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> You forgot
>
>         // If you make a copy of $db on your laptop for testing,
>         // we will flay the living flesh from your bones
>
> and more importantly
>
>         // We are holding everyone on the planet hostage to ensure
>         // that they never make backups of $db, but if something
>         // happens to us, you're on the hook for that, too.

Well, you'd have to give instructions to anyone with shell access,
too, and keep careful track of all . . . okay, but it would be roughly
possible.  We already do it for checkuser IPs.

> One of us is being very obtuse here, but I'm not sure which.

Neither am I . . .

> If I'm trying to count "approximate number of people who have
> viewed the page at least once", without possibly overcounting
> people who have viewed the page multiple times, then depending on
> the numbers it may be true that the server probably doesn't have
> to, but under other circumstances it might very well have to,
> and it's certainly strange to say that it "can't".

If you're only sending one view in every X to the view-counting
server, then it doesn't know how many times you've viewed the page.
It therefore can't exclude multiple consecutive views by the same IP
from its count.  Yes?  No?


subject: [Wikitech-l] Disabling users

body:
On 8/30/06, Rob Church <robchur at gmail.com> wrote:

>
> I'm not disputing the account locking feature.
>
Okay. Seems I misread which bug/feature you were talking about.
Michael
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> Did what?  You deny he's restricted editing in the past, or that he
> called it becoming more open?

Where did Jimbo "decide to restrict editing" and then "called it
becoming more open".

> > Technically, the word anonymous means without a name.
>
> So a user who logs in as "88 dot 33 dot 23 dot 23" is anonymous?

No, they just have a stupid name.

I'm not suggesting that the use of the word anonymous is wise... It's
not, especially when talking to outsiders. I'm just pointing out that
it isn't incorrect, as you stated.


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Do you have any clue about the details of the counter's internal operations?
>
> Why must you argue with someone who does?

1) No.

2) Because I didn't know that you did and was thinking hypothetically,
not concretely.  (But the counter currently doesn't track IPs, does
it?  So why is the current implementation relevant? . . . Well, never
mind, it doesn't matter.  Whatever works, really, I don't much care
what happens behind the curtains unless I have to deal with it, which
I don't.)


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
[snip]
> If you're only sending one view in every X to the view-counting
> server, then it doesn't know how many times you've viewed the page.
> It therefore can't exclude multiple consecutive views by the same IP
> from its count.  Yes?  No?

Correct.

It could exclude duplicate sampled hits, but then it's not clear what
the heck it's measuring.. it's not measuring unique views, it's not
measuring pure views.   It would just be a strange and useless metric.

Which is what I said up the thread.


from_name: Oskar Sigvardsson

body:
On 8/30/06, Timwi <timwi at gmx.net> wrote:
>
> Hi,
>
> please take a look at this:
>
> http://en.wikipedia.org/w/index.php?title=Template:FA/BeenOnMainPage&action=history
>
> The template causes pages to become invalid XHTML. (Not in a majorly
> serious way, but still.) I fixed that. Unfortunately, it breaks the CSS
> rules people have put into their user CSS to style it. Thus I was reverted.
>
> What is the proper avenue for this kind of situation? The "normal user"
> will, of course, just think I broke it and revert it, without caring
> about XHTML conformance. The correct way however required for those
> users to fix their CSS. What do I do?
>
> Timwi

Any idea how many users we are talking about?

I just ran [[Wikipedia:Featured articles]] through validator.w3.org
and got 781 errors (to be fair, they're all the same). That just
doesn't feel right.


from_name: Steve Bennett

subject: [Wikitech-l] Disabling users

body:
On 8/30/06, Rob Church <robchur at gmail.com> wrote:
>
> I have stated, and continue to maintain, that to implement strong,
> per-page access controls, to the level that some organisations
> require, within MediaWiki would require a considerable rewrite and a
> rethink of a lot of aspects of the software, and that such a change
> would *not* be consistent with the purpose and intended use case for
> MediaWiki.

No one seems to have mentioned the obvious, which is that in these cases the
best thing is probably just to lock down the whole webserver with a name and
password. Where I'm working now does that and it works perectly well - we
have about 5 different MediaWiki wikis, and different people have access to
different ones.

Steve


body:
On 8/30/06, Rob Church <robchur at gmail.com> wrote:
>
> Oh, thank fuck. I thought for a moment that a recent commit of mine to
> Parser.php had screwed up the software, but couldn't find the
> problematic change - all I could determine was that, for me, it seemed
> to trigger when Cite was active.
>

This fixes the recent problems with duplicate refs?

Steve


from_name: Jay R. Ashworth

subject: [Wikitech-l] hitcount stats

body:
On Wed, Aug 30, 2006 at 12:24:50PM -0400, Simetrical wrote:
> On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> > > If it's possible to guarantee it gets kept, it's possible to guarantee
> > > it only gets kept for a day.
> >
> > False (unless you're splitting hairs).
>
> // If you remove the line after the next or refactor this code, we will
> // flay the living flesh from your bones
> $db->write("$IP visited this page, yay")
> $db->check_if_stuff_is_over_a_day_old_and_deal_with_it();
> // If you remove the above line or refactor this code, we will flay the
> // living flesh from your bones

Sim, you're discussing what *code* will do.  Steve is discussing what
*people* can do -- see also "capability creep" and "US Government".

> > If you're interested in
> > discarding redundant hits, it obviously doesn't matter whether
> > the browser or the server does it.
>
> Except that the server can't do it.

And to clarify the misundertanding that I believe Steve has on this
point:

<whisper>
Squids
</whisper>

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] hitcount stats

body:
On Wed, Aug 30, 2006 at 12:00:11PM -0400, Gregory Maxwell wrote:
> four days much of the samples are scattered randomly around pages deep
> into the tail which we can't not speak about accurately.

"deep into the tail".

Damn, that's a nice phrase...

Cheers,
-- jr "Lucifer's Hammer?" a
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] hitcount stats

body:
Greg Maxwell wrote:
> It could exclude duplicate sampled hits, but then it's not clear what
> the heck it's measuring.. it's not measuring unique views, it's not
> measuring pure views.

Sampled unique hits.  What's wrong with that?  (No worse than
sampled hits, it seems to me.)

But enough of this, at any rate.


from_name: Frederick "FN" Noronha

subject: [Wikipedia-l] Fwd: [participants] Wikipedia... in Thailand

body:
A friend, contacted vi a the Asia Commons "Participants" lists says
there's no problem at her end. FN

---------- Forwarded message ----------
From: paola.dimaio at gmail.com <paola.dimaio at gmail.com>
Date: 30-Aug-2006 13:05
Subject: Fwd: [participants] Wikipedia... in Thailand
To: WOICT at googlegroups.com, participants at asia-commons.net

Hi Fred
No issues from my end
can access both the english and thai pages of
wikipedia
http://th.wikipedia.org/wiki/%E0%B8%AB%E0%B8%99%E0%B9%89%E0%B8%B2%E0%B8%AB%E0%B8%A5%E0%B8%B1%E0%B8%81

---------- Forwarded message ----------
From: Frederick FN Noronha <fredericknoronha at gmail.com>
Date: Aug 30, 2006 2:07 PM
Subject: [participants] Wikipedia... in Thailand
To: participants at asia-commons.net

Can you'll guys out there in Thailand access the Wikipedia? On the
Wikipedia-L list
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l some were
voicing difficulties in getting across. And, as you know, the Thai
wikipedias is one of the active Asian networks around. FN
--
-------------------------------------------------------------------------------
Frederick Noronha http://fn.goa-india.org   9822122436 +91-832-240-9490
http://fredericknoronha.wordpress.com fredericknoronha at gmail.com


from_name: Travis Derouin

subject: [Wikitech-l] before and after content display hooks

body:
Are there any hooks available planned that are called right before or
after article is displayed in HTML? They'd be useful to have around to
display HTML before or after the contents of an article.

Travis


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Steve Summit <scs at eskimo.com> wrote:
> Greg Maxwell wrote:
> > It could exclude duplicate sampled hits, but then it's not clear what
> > the heck it's measuring.. it's not measuring unique views, it's not
> > measuring pure views.
>
> Sampled unique hits.  What's wrong with that?  (No worse than
> sampled hits, it seems to me.)

You can't sample unique hits, at least not without first capturing all hits.

You could have unique sampled hits, but that doesn't map into any
metric anyone uses... and it will be misunderstood as sampled unique
hits which is another thing entirely.


subject: [Wikitech-l] hitcount stats

body:
On 8/30/06, Tels <nospam-abuse at bloodgate.com> wrote:
> So, if you can't guarantee that the hashes of the IP (including the log)
> don't leak out, how can you guarantee that the secret doesn't leak out?
> Answer: You can't.
>
> The only safe way to not leak these information out is not even to store
> them.

Silly, you store the hashes but not the secret.


from_name: Brion Vibber

body:
Steve Bennett wrote:
> On 8/30/06, Rob Church <robchur at gmail.com> wrote:
>> Oh, thank fuck. I thought for a moment that a recent commit of mine to
>> Parser.php had screwed up the software, but couldn't find the
>> problematic change - all I could determine was that, for me, it seemed
>> to trigger when Cite was active.
>
> This fixes the recent problems with duplicate refs?

It's needed by the fix for that.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060830/e76c19a8/attachment.pgp>


from_name: David Gerard

subject: [WikiEN-l] Asteroids

body:
On 30/08/06, Daniel Mayer <maveric149 at yahoo.com> wrote:

> Not a good idea since that is all we know about most asteroids and those data would be far more
> useful in a big table of asteroids, not on individual pages for each space rock.
> In fact, the basics are already in the List of asteroids tables.
> http://en.wikipedia.org/wiki/List_of_asteroids_%2839001-40000%29
> We can just add to the table.

Excellent! So what we need then is a forest of redirects.

- d.


subject: [WikiEN-l] WTF Have I Missed?

body:
On 8/30/06, Ian Woollard <ian.woollard at gmail.com> wrote:
> It should be possible to build a prototype test-filter webserver.

Nope. It's not.


body:
On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> > Did what?  You deny he's restricted editing in the past, or that he
> > called it becoming more open?
>
> Where did Jimbo "decide to restrict editing" and then "called it
> becoming more open".
>
I have no idea where he did it, but one instance would be when
creation of new articles was restricted.

> > > Technically, the word anonymous means without a name.
> >
> > So a user who logs in as "88 dot 33 dot 23 dot 23" is anonymous?
>
> No, they just have a stupid name.
>
> I'm not suggesting that the use of the word anonymous is wise... It's
> not, especially when talking to outsiders. I'm just pointing out that
> it isn't incorrect, as you stated.

Unwise and confusing, or inaccurate, whatever.  It should be phrased better.


from_name: Neil Harris

subject: [WikiEN-l] Well darn, Pokemon is important after all.

body:
Steve Bennett wrote:
> On 8/29/06, Andrew Gray <shimgray at gmail.com> wrote:
>
>> You can see what I believe is the sampling period by looking at
>> [[MediaWiki:monobook.js]]; it's currently 5000, and hasn't been lower
>> than 3000.
>>
>
> Heh, ok. So if we're seeing figures that end in 333, it presumably
> means the magic factor was like 4333 for a while or something. Yes,
> massive flaw in my logic, thanks for pointing it out ;)
>
>
>
On day 3, they were all multiples of 1000/3

On day 4, they are all multiples of 1000/4...

-- Neil


subject:
[WikiEN-l] You realise this means [[Pokemon]] has to be brought to
	feature quality. (was Well darn, Pokemon is important after all.)

body:
On 30/08/06, Steve Summit <scs at eskimo.com> wrote:

> It really is a case of "be careful what you wish for", isn't it?
> We were quite pleased over at en.wiktionary when Leon turned
> stats on there for us a couple of days previously, but the joy
> is now mixed with rue as we learn that among our most popular
> entries, so far, are consistently MILF, penis, fuck, masturbate,
> and breasts.

What it tells us is that it is absolutely vital that said articles be
of the highest possible quality, and in fact should be brought to
Featured Article status as absolutely soon as possible. (Seriously.)

> (It's true, though; clearly we'll all want to wait weeks or
> months before we can imagine that the stats in general aren't
> swamped by fixations du jour.)

Fixations du jour are fine, at least spread over a month. If that many
people are interested in a given article over a whole month, that's a
significant topic and we have no real excuse for not having it be
featured or near-featured quality. We're no. 17 on Alexa 3-month
average, no. 15 today - that many readers are *significant*.

- d.


body:
This is in response to the somewhat silly English-language press we've
had lately. I'll be sending copies of this out to the sources of
recent articles on the subject that got it precisely backwards.

The following is, I understand, technically accurate, based on text
from Amgine, Phillipp Birkin (de:wp), Jimbo and Mathias Schindler (I
think), and comcom discussions (press relations being part of that
job). Corrections welcomed - you have about five minutes.

(and geni, I expect you to ask how this makes the new patrollers' jobs
easier - by having what's effectively a feed of new-editor and
anonymous edits, is what I was thinking of.)

- d.

"Approved" versions on Wikipedia FAQ

* What is changing?

We want to open up editing without damaging the reader's experience.

We want to be more wiki and let editors edit freely, which is where
all the good things come from. At present a small percentage of
articles (a few hundred out of 1.5 million on the English language
Wikipedia, http://en.wikipedia.org/) are locked or partially locked
from editing. We want to open these up. But Wikipedia is a top 20
website (Alexa ratings, no. 17 on 3 month average; no. 15 on 30 August
2006 - http://www.alexa.com/), so we must keep it good for the
readers.

The new feature will mean that edits from new or anonymous editors
will be delayed before being shown to readers - they will see a
'flagged OK' version by default, with a link to the live version. The
idea is to enhance the *reading* experience, and free us to enhance
the *editing* experience. If vandalism can't be seen by the general
public, there will be less motivation to vandalise.

Anonymous or new-editor edits will need to be approved by a logged-in
editor. Of the thousands of editors on the large Wikipedias, many
concentrate on checking revisions and dealing with odd changes and
vandalism - this will assist their work and we do not expect new
delays.

We are also considering a related feature to flag particular versions
of articles as being of high quality. This is to a different end: a
high-quality finished product. This will likely be tested first on the
German language Wikipedia (http://de.wikipedia.org/), which has
already had three stable editions released on CD and DVD, which have
sold quite well. If the feature works there, it may be used on other
language Wikipedias.

These features are not finished, so we don't have a lot of fine detail
as to how it will all work as yet. But we hope this change will allow
us to do things such as open up the George W. Bush article or even the
front page itself to full unrestricted editing.

* When was this proposed?

Jimmy Wales asked for a time-delay feature for casual readers in late
2004; after very fast editing on the Indian Ocean tsunami produced a
very high-quality article
(http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake) very
quickly, but with some highly visible vandalism; we've hotly discussed
how to achieve stable high-quality editions of Wikipedia since almost
the start of the project, in 2001.


body:
This is in response to the somewhat silly English-language press we've
had lately. I'll be sending copies of this out to the sources of
recent articles on the subject that got it precisely backwards.

The following is, I understand, technically accurate, based on text
from Amgine, Phillipp Birkin (de:wp), Jimbo and Mathias Schindler (I
think), and comcom discussions (press relations being part of that
job). Corrections welcomed - you have about five minutes.

(and geni, I expect you to ask how this makes the new patrollers' jobs
easier - by having what's effectively a feed of new-editor and
anonymous edits, is what I was thinking of.)

- d.

"Approved" versions on Wikipedia FAQ

* What is changing?

We want to open up editing without damaging the reader's experience.

We want to be more wiki and let editors edit freely, which is where
all the good things come from. At present a small percentage of
articles (a few hundred out of 1.5 million on the English language
Wikipedia, http://en.wikipedia.org/) are locked or partially locked
from editing. We want to open these up. But Wikipedia is a top 20
website (Alexa ratings, no. 17 on 3 month average; no. 15 on 30 August
2006 - http://www.alexa.com/), so we must keep it good for the
readers.

The new feature will mean that edits from new or anonymous editors
will be delayed before being shown to readers - they will see a
'flagged OK' version by default, with a link to the live version. The
idea is to enhance the *reading* experience, and free us to enhance
the *editing* experience. If vandalism can't be seen by the general
public, there will be less motivation to vandalise.

Anonymous or new-editor edits will need to be approved by a logged-in
editor. Of the thousands of editors on the large Wikipedias, many
concentrate on checking revisions and dealing with odd changes and
vandalism - this will assist their work and we do not expect new
delays.

We are also considering a related feature to flag particular versions
of articles as being of high quality. This is to a different end: a
high-quality finished product. This will likely be tested first on the
German language Wikipedia (http://de.wikipedia.org/), which has
already had three stable editions released on CD and DVD, which have
sold quite well. If the feature works there, it may be used on other
language Wikipedias.

These features are not finished, so we don't have a lot of fine detail
as to how it will all work as yet. But we hope this change will allow
us to do things such as open up the George W. Bush article or even the
front page itself to full unrestricted editing.

* When was this proposed?

Jimmy Wales asked for a time-delay feature for casual readers in late
2004; after very fast editing on the Indian Ocean tsunami produced a
very high-quality article
(http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake) very
quickly, but with some highly visible vandalism; we've hotly discussed
how to achieve stable high-quality editions of Wikipedia since almost
the start of the project, in 2001.
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


subject: [WikiEN-l] WTF Have I Missed?

body:
On 8/30/06, Ian Woollard <ian.woollard at gmail.com> wrote:
> I mean just a website you go to that has no log-in support that picks
> time-delayed version of articles from the wikipedia for display; so
> you can click and search and stuff.

That would be idiotic. Which is why no one has proposed it.

Think for a moment, a vandal puts up an image of a penis... it says up
for 5 minutes.. then it is removed. Then we sit around, and in 5
minutes a penis is displayed on an article and we are powerless to
stop it.

Gee.. that would help a lot.

[snip]
> It doesn't have to be perfect or fast, it's a *prototype*.

It's generally useful when prototypes model something that someone
would actually want to do.


from_name: Delphine Ménard

subject: [Foundation-l] "wikinomics"

body:
Much clearer with this:

http://www.wikinomics.com/

Delphine

On 8/30/06, Samuel Klein <meta.sj at gmail.com> wrote:
> I'm not sure the authors of this book about "how mass collaboration
> changes everything" have ever heard of Nomic, but they have a cute web
> address, a remarkably familiar cover image and font-choice, and are
> looking for better title suggestions.
>
> Perhaps someone should send them cover-image suggestions as well.  (Or
> perhaps, as they seem to have developed a 3D model of a suitable
> globe, there could be an exchange -- license to use that cover for a
> 3D model of the real WP logo... which would be handy.)
>
> SJ

--
~notafish


subject: [Foundation-l] [Wikipedia-l]  "wikinomics"

body:
Much clearer with this:

http://www.wikinomics.com/

Delphine

On 8/30/06, Samuel Klein <meta.sj at gmail.com> wrote:
> I'm not sure the authors of this book about "how mass collaboration
> changes everything" have ever heard of Nomic, but they have a cute web
> address, a remarkably familiar cover image and font-choice, and are
> looking for better title suggestions.
>
> Perhaps someone should send them cover-image suggestions as well.  (Or
> perhaps, as they seem to have developed a 3D model of a suitable
> globe, there could be an exchange -- license to use that cover for a
> 3D model of the real WP logo... which would be handy.)
>
> SJ

--
~notafish
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


subject: [Foundation-l] "wikinomics"


subject: [Wikipedia-l] [Foundation-l] "wikinomics"


from_name: Daniel R. Tobias

body:
There seems to be ongoing fighting over at the [[Certified Financial
Planner]] page:

http://en.wikipedia.org/wiki/Certified_Financial_Planner

over whether the page should be festooned with (r) and (tm) symbols
everywhere the trademarked title of the article occurs, including as
part of the article's title itself.

It is my impression (IANAL) that such usages are not necessary, nor
are they standard in English-language writing style, when the usage
is of a journalistic or encyclopedic nature rather than as part of
marketing materials.  After all, Wikipedia has many articles, like
[[Coca-Cola]], that are named after trademarks, but don't display the
symbols demanded by the lawyers.

At any rate, if such symbols do remain in the article, they ought to
be done with proper Unicode characters (technically feasible now that
the site is entirely in UTF-8) rather than their ugly ASCII
imitations.

--
Dan
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/


from_name: Andrew Lih

subject:
[WikiEN-l] [Wikipedia-l] [Wmfcc-l] "Approved" versions on
	Wikipedia FAQ

body:
David, thanks for the thoughtful evaluation and creating the meta
page. Glad to see comcom addressing these things with rapid speed in
helping to flesh out the specifics of these initiatives.

-Andrew (User:Fuzheado)

On 8/30/06, David Gerard <dgerard at gmail.com> wrote:
> On 30/08/06, Andrew Lih <andrew.lih at gmail.com> wrote:
>
> > Does this make the 5 minute cut? :)
>
>
> I sent it to a couple of places just now, including Bill Thompson
> (BBC) who sent a very nice reply. So not quite ;-)
>
> I've put it on Meta. Please hack away at will, and move somewhere
> better if sensible:
>
>     http://meta.wikimedia.org/wiki/2006_proposed_approval_for_anonymous_edits
>
> (that's a terrible article name. You can tell I've been writing on the
> work wiki too much. Even if it is MoinMoin.)
>
>
> > I think the premise of the FAQ is off in its current form. I am
> > worried by the "we" part, meaning the mythical monolithic Wikipedia
> > community. (ie. Why not make this an opportunity to show that
> > Wikipedias have their distinct culture and are at different stages of
> > development?)
>
>
> In this case because it was an immediate response to the Bill Thompson
> and Platinax articles. I was trying very hard to keep it *really
> simple* and clear because journalists don't have time to read press
> releases closely - they have to be able to get your message by
> skimming.
>
> There's huge piles of detail I left out ...
>
>
> > I think the announcement should make clear:
> > - There has always been a desire for a better reader experience
> > - The larger Wikipedia communities have turned their attention from
> > growth to quality
>
>
> yep, these are important.
>
>
> > - The German Wikipedia has initiated an experiment with a
> > "nonvandalized" and "checked" versions (nb: terminology may need to be
> > tweaked)
>
>
> Yeah. I didn't give them names, but I hope I got this idea across.
>
>
> > - This "potentially" may allow for a mechanism other than blunt
> > protection for preventing vandalism
>
>
> Jimbo wanted to emphasise "this is to make things wide-open" because
> the press coverage had been "OH NOEZ WIKI IS CLOSED", so this probably
> isn't as neutral as it might ideally be.
>
>
> > - The greater Wikipedia community hopes to learn from this pilot project
>
>
> I think I've got that in. Platinax emailed me to clarify and I said
> that it's quite possible it might go badly and we cancel the idea -
> but we're giving it a go.
>
>
> > - The English and other Wikipedias, with their own norms and cultures,
> > may or may not adopt the German initiatives
>
>
> I left out that bit, but I think I have in that we are trying.
>
>
> > PS: Would be nice to have a pointer to a meta page (if it exists)
> > describing the German initiative. If I had not attended the Wikimania
> > 2006 summit on the top floor of Pound Hall with Danny, Kurt, G.
> > Maxwell, Jimmy, Raul654, Kelly Martin, et al, I would not have known
> > these things. And I'm a bit concerned we're neglecting to use the wiki
> > to share this knowledge.
>
>
> It wasn't a matter of fuss until the press grabbed it and ran with it,
> conclusively describing the Wikipedia elephant to the public as a rope
> holding together walls in a fan shape at the top of several trees with
> a spear and thirty snakes sticking out the side [*]. The feature is
> probably still way too premature to warrant this attention ... but
> it's got it anyway.
>
>
> - d.
>
>
> [*] http://www.wordinfo.info/words/index/info/view_unit/1/?letter=B&spage=3
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] [Wmfcc-l] "Approved" versions on Wikipedia FAQ


from_name: Jeff V. Merkey

subject: [Foundation-l] Quo vadis, WMF?

body:
Jussi-Ville Heiskanen wrote:

>For a long long time it has been the operative assumption that the
>Wikimedia Foundation carries the legal liability, and if things go
>really really badly wrong, the foundation would sacrifice itself, so
>the community, and the content itself could continue elsewhere.
>
>

What?

>Firstly there is the building of increasingly robust defensive
>bulwarks against litigation and other forms that the foundation could
>be seriously harmed.
>

The behavior of the community is the whole reason this risks even exist.
How about the
community take some ownership for its own actions. i.e. "Do folks own
any of this risk
based on their own actions?"

>The other facet of the question is the speed at which the organs of
>the foundation develop into integral parts of how our whole greater
>endeavour operates. Note I am not saying indispensible in the sense
>that those particular organs are locked into place (we are a long way
>from that yet), but integral in the sense that should the highly
>unlikely eventuality of having to start again occur (as the GFDL
>allows), _something_ would have fill their functions in the operation
>of the restarted endeavour.
>
>The problem (or non-problem, as the facts may obtain) here lies on
>what philosophy do we adopt toward this earlier operative assumption
>of sacrificability?
>
>
Man, this is what I meant when I said "gaping disconnects from real
world realities".

>Do we find on reflection, that we have already crossed the Rubicon,
>that although theoretically the work could be restarted elsewhere, the
>disruption would be high enough, that it is wisest to abandon all
>worry about the possibility of sacrificing the Foundation, and
>concentrate on making the Foundation functional without regard to what
>things it might lock us into, and speed up construction of legal and
>other defensive bulwarks into a kind of Fortress Wikimedia Foundation?
>
>Or should we seriously consider examining every new thing the
>Foundation takes onto its plate, making doubly sure that it is
>something that would compromise our ability to just chuck the
>Foundation away like the tail of a lizard, and trust we will have the
>resources to grow a new tail, there being no vital organs in it.
>
>
"Right to leave, Right to fork". Cimon, you are running for the board?
What on earth are you
talking about?

Jeff

>
>
>


subject: [Foundation-l] Quo vadis, WMF?


from_name: Gregory Maxwell

body:
On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> I have no idea where he did it

Then buzz off, troll.


from_name: Andrew Gray

body:
On 30/08/06, David Gerard <dgerard at gmail.com> wrote:

> The new feature will mean that edits from new or anonymous editors
> will be delayed before being shown to readers - they will see a
> 'flagged OK' version by default, with a link to the live version. The
> idea is to enhance the *reading* experience, and free us to enhance
> the *editing* experience. If vandalism can't be seen by the general
> public, there will be less motivation to vandalise.

You might want to clarify what "new and anonymous" means - is this
going to be a time-lapse job like sprotection, or a manually enabled
flag? Because people may well assume the latter, and SFAIK that isn't
being considered...

(in en.wp normal parlance, "new and anonymous" means first-four-days,
so I'm guessing it's intended to be something like that)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: Magnus Manske

subject: [Wikitech-l] Template parameter statistics

body:
Lars Aronsson schrieb:
<snip lots of interesting stuff>
> Imagine if there was a templateparameter table supported by
> Mediawiki, then we could do this in real time.
I remember suggesting that a while ago on this list, so de.wikipedia
could have automatic lists of people sorted by (last) name, though I'm
sure that would only be one application.
>   I'm wysiwyg
> filling out an infobox template here.  Which parameter names
> should I supply?  Which values should I typically use?
>
Actually, we could use a variant of my reference renerator [1] to enter
new templates, with needed and optional parameters and per-parameter
hints, to insert new templates. I for one always feel creeped out by the
species templates on de ;-) and would use such a tool. We'd only have to
glue it to the edit page via JavaScript or something.

Magnus

[1] http://tools.wikimedia.de/~magnus/makeref.php

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060830/d2942fd1/attachment.pgp>


from_name: Akash Mehta

subject: [Wikipedia-l] Cannot access Thai Wikipedia from Thailand

body:
Hmm... are you sure the proxy servers' IP's identify them as being in
Thailand? Use your proxies to visit whatismyip.com and traceroute that IP
using the tools at dnsstuff.com, it might clarify. Otherwise, maybe the
block has been lifted?

On 8/30/06, theProject <wp.theproject at gmail.com> wrote:
>
> Would this effect be replicable by using a proxy server in Thailand? I
> just
> tried a couple of proxy servers there and I can use them to load both
> th-wiki and en-wiki, despite the ridiculous reduction in speed which I
> think
> is primarily due to using a proxy server. Mind you, that's just one proxy
> server, and besides, I'm the last guy to ask about anything technical. :-)
>
> theProject
>
> On 8/29/06, Andrew Lih <andrew.lih at gmail.com> wrote:
> >
> > Wow, this is pretty serious. Do you think it could be a block? Has
> > there ever been a block before of anything on the Internet in
> > Thailand?
> >
> > -Andrew
> >
> > On 8/29/06, [LiM] Manop <manop at 6tub1.com> wrote:
> > > Thank you for the reply. It seems that people from Thailand cannot
> > access
> > > Wikipedia in other languages as well as Thai Wikipedia; I and my
> friends
> > did
> > > test in English (en), German (de), and Japan (ja). The problem occurs
> in
> > > other projects as well including Wiktionary, Wikisources.
> > >
> > > However I and my friends in Thailand can access to this site
> > > https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page
> > >
> > > Manop
> > >
> > > On 8/29/06, Andrew Gray <shimgray at gmail.com> wrote:
> > > >
> > > > On 29/08/06, [LiM] Manop <manop at 6tub1.com> wrote:
> > > > > Hello,
> > > > >
> > > > > I'm wondering if anyone have the same problem. Several of my
> friends
> > in
> > > > > Thailand cannot access to Thai Wikipedia (http://th.wikipedia.org)
> > today
> > > > > since 4-5 hours ago. But I access from the USA, it works fine for
> > me.
> > > >
> > > > Is it just th.wikipedia, or other language sites as well?
> > > >
> > > > --
> > > > - Andrew Gray
> > > >   andrew.gray at dunelm.org.uk
> > > >
> > >
> > >
> > >
> > > --
> > > (LiM) Manop Kaewmoracharoen
> > > 427 Town Engineering Bldg.
> > > Iowa State University
> > > _______________________________________________
> > > Wikipedia-l mailing list
> > > Wikipedia-l at Wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > >
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at Wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> >
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Anthony

body:
On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> > I have no idea where he did it
>
> Then buzz off, troll.

You intentionally misquoted me, but I'm the troll?


subject: [WikiEN-l] WP:LIVING and "sensitivity" again

body:
On 8/30/06, Matt Brown <morven at gmail.com> wrote:
> On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> > Of course the fact that it's not useful information combined with the
> > fact that it's almost never an easily verified fact is an equally good
> > reason.
>
> Agreed.  However, if the birthdate is already public information, I
> see no point in censoring Wikipedia about it.  Verifiability works
> quite well in this regard; if it's already in reliable source
> material, then the cat is out of the bag and deleting it from
> Wikipedia serves no practical good.
>
I think the instances where we have a reliable source for someone's
exact birthdate are very low, however.


body:
On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> On 8/30/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> > > I have no idea where he did it
> >
> > Then buzz off, troll.
>
> You intentionally misquoted me, but I'm the troll?

I didn't misquote you.

"The first time Jimbo decided to restrict editing and call it becoming
more open"

You used the word "and" in your claim. Do trolls come from an
alternate universe where and has been redefined as OR?

Your logic would have me expecting you to agree with this statement:
"Anthony is a homicidal pedophile AND he posts to this list."


body:
On 8/30/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/30/06, Anthony <wikilegal at inbox.org> wrote:
> > Of course the fact that it's not useful information combined with the
> > fact that it's almost never an easily verified fact is an equally good
> > reason.
>
> It's extremely useful information for the purpose of disambiguating.
> How do you know that semi-notable Jim Smith who lives in Sydney, born
> 1957 is or isn't Jim Smith (born Australia 1957, lives in New York)?
> Knowing their birthdates helps a huge amount.
>
The disambiguation page for [[Jim Smith]] seems to handle this fine
without mentioning any birthdates.

> Also, you don't need a birth certificate to source it. Any published
> source is a pretty good start.
>
It's a good start if you don't really care about whether or not it's
correct, which is the case with birthdates.  But if you don't care
about whether or not it's correct, why bother.

Anyway, a published source can be better than a birth certificate.  In
the case of Jimbo, the Wikipedia article has a different birthdate
than his birth certificate, and I'd guess that the article is probably
the correct date.

Of course, it brings up questions about truth vs. "wikitruth" when you
think about how easy it is to get information into Wikipedia - just
tell some news reporter to publish it.

Anthony