body:
Aphaia wrote:

>Hallo, und thank you for your reply
>On 5/22/05, Timwi <timwi at gmx.net> wrote:
>
>
>>Aphaia wrote:
>>
>>
>>>I would make it sure we can safely ignore those anonymous
>>>submissions' right as "licence holder" [or somehow possible, because
>>>they can't or hardly be contacted, but I am not sure]...
>>>
>>>
>>Just because we can't contact them, doesn't mean they lose their copyright.,
>>
>>
>
>Okay, so they hold their copyright until 50 years will pass from their
>submissions ...
>
70 years in many countries.

Ec


list: wikimedia-l

source: pipermail-mbox

from_name: Ray Saintonge

subject: [Foundation-l] Re: A license for the Ultimate Wiktionary


list: wikien-l

from_name: Geoff Burling

subject: [WikiEN-l] Re: Article size consistency 32k

body:
On Sun, 22 May 2005, Timwi wrote:

> Geoff Burling wrote:
> >
> > And the primary problem I have with accessing information from Wikipedia
> > is not the article length (although a concise well-organized article is
> > always better than a long discursive one, no matter the amount of detail
> > contained), but the size & number of images.
>
> What browser are you using?? Firefox (and IIRC Opera) doesn't wait for
> all the images to load before it displays the text.
>
It's an ancient version of Mozilla that I probably compiled
incorrectly  when I installed in years ago -- but text/image display
was my point. (And note: because I know it is ancient, I haven't
mentioned any of the problems I have using it with Wikipedia, which have
been many; I wouldn't be surprised if I'm the only one experiencing
them.)

Download times are a very off-putting experience whenever one deals with
the Web, & very few web developers bother to optimize for speed -- or
even consider it a problem. Google is an amazing -- & very rare exception.
(I've had this discussion with a web designer friend several times, who
at least understands this issue -- although he's still a bit hobbled
with the "I want them to see the site how I choose, not how they may want
to choose" attitude.)

And turning images off is not the solution. Much of the time, I want to
see some of the images in an article, such as  a map, or specific
photographs of a person or a place; I'm not interested seeing in every
known image with the proper license that could be related to the
subject.  Which is why I mentioned commons: not only does it support a
competition for the best images in a given category by allowing a
practically unlimited number of images to be uploaded, it does not
require the losers to be deleted because they are unused -- & allows
them to be available to compete in other categories.

Geoff


list: wikipedia-l

subject:
[Wikipedia-l] Article validation: allow IP ratings for the raw
	data phase

body:
Gregory Maxwell wrote:

>On 5/22/05, Magnus Manske <magnus.manske at web.de> wrote:
>
>
>>* Later, we will allow only logged-in users to rate articles, right?
>>Otherwise, we'll lose a great part of the perceived reliability
>>improvement, IMHO. But how can we really set up this system if the data
>>we use as a foundation for the decision is based on anon entries as well?
>>
>>
>We can always collect anon votes but then exclude them from any
>decision making process.
>
In principle I have nothing against anon rating votes.  There could
still be a problem when someone wants to change his vote.  The changes
that are made to an article over time are the most likely reason for
changing a vote.  For a registered user this should be no problem; the
old vote is removed, and the new one added.  In the case of a dynamic IP
the old vote would not automatically be removed.

Ec


list: wikitech-l

from_name: Austin Hair

subject:
[Wikitech-l] Request for selected parts of the user table to be
	included in the dumps.

body:
If it's for purely statistical purposes, what do you need the user_id
and user_name for?

-- Austin


from_name: Alex Regh

subject: [Wikipedia-l] Re: Validation feature update

body:
Hi!

On Sat, 21 May 2005 17:23:02 +0200, Anthere wrote:

>>> Would a page of all ratings from a specific *user* be of general
>>> interest? I think someone suggested it, but...
>
>Why do you think it could be beneficial to store/know this ?

I'd want to see that, because I edit a lot of the sex/gender related articles,
who regularly see "contributions" based on personal POVs, like "homosexuality
is bad/sinfull/unhealthy/unnatural/unbiblical/younameit". Given that such
contributors usually don't like our articles on these subjects very much, the
articles would probably see lots of bad rating based on these POVs. It would
simply be useful to see whether a user who gave for example [[homosexuality]]
a bad rating has also given, for example, [[gay]], [[lesbian]],
[[transgender]], [[Stonewall riots]] and so forth bad ratings or not. The
former might somehow invalidate his vote in the mind of the reader.

Alex
--
If you don't go over the top,
you can't see what's on the other side.
        --- Jim Steinman ---

Alex' Assorted Homepages: www.alexsite.de


list: foundation-l

from_name: Aphaia

subject:
[Foundation-l] STOP Translations needed: Wikimedia Commons
	reaches 100, 000 uploads

body:
Hiya folks

On 5/21/05, Angela <beesley at gmail.com> wrote:
> On 5/21/05, Angela <beesley at gmail.com> wrote:
> > I've merged Villy's announcement with the press release from the
> > Commons at http://grants.wikimedia.org/wiki/Press_releases/Wikimedia_Commons_May_2005

I think it would be better to put a brief note on the WMF site too
unless the board a/o any thoughtful people object.

Is there anyone who would like to prepare a 100 words summary for
"Latest news" corner, any language will be welcome, but English is
preferable for most of trasnlators.

Baccioni,
--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


from_name: Fred Bauder

body:
This is the typical type of problem you run into with folks using old
equipment and obsolete software. Like, for example, folks in Mexico who use
castoff US equipment. Given our geek editor base, most of whom have
reasonably good equipment, it is hard to put ourselves in the position of
those who are are trying to access the internet under less than optimal
conditions, but is is good if we could to the extent we are able and
accomodate them to the extent we can.

Fred

> From: Geoff Burling <llywrch at agora.rdrop.com>
> Reply-To: Geoff Burling <llywrch at agora.rdrop.com>, English Wikipedia
> <wikien-l at Wikipedia.org>
> Date: Sun, 22 May 2005 11:48:25 -0700 (PDT)
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Subject: Re: [WikiEN-l] Re: Article size consistency 32k
>
> On Sun, 22 May 2005, Timwi wrote:
>
>> Geoff Burling wrote:
>>>
>>> And the primary problem I have with accessing information from Wikipedia
>>> is not the article length (although a concise well-organized article is
>>> always better than a long discursive one, no matter the amount of detail
>>> contained), but the size & number of images.
>>
>> What browser are you using?? Firefox (and IIRC Opera) doesn't wait for
>> all the images to load before it displays the text.
>>
> It's an ancient version of Mozilla that I probably compiled
> incorrectly  when I installed in years ago -- but text/image display
> was my point. (And note: because I know it is ancient, I haven't
> mentioned any of the problems I have using it with Wikipedia, which have
> been many; I wouldn't be surprised if I'm the only one experiencing
> them.)
>
> Download times are a very off-putting experience whenever one deals with
> the Web, & very few web developers bother to optimize for speed -- or
> even consider it a problem. Google is an amazing -- & very rare exception.
> (I've had this discussion with a web designer friend several times, who
> at least understands this issue -- although he's still a bit hobbled
> with the "I want them to see the site how I choose, not how they may want
> to choose" attitude.)
>
> And turning images off is not the solution. Much of the time, I want to
> see some of the images in an article, such as  a map, or specific
> photographs of a person or a place; I'm not interested seeing in every
> known image with the proper license that could be related to the
> subject.  Which is why I mentioned commons: not only does it support a
> competition for the best images in a given category by allowing a
> practically unlimited number of images to be uploaded, it does not
> require the losers to be deleted because they are unused -- & allows
> them to be available to compete in other categories.
>
> Geoff
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Gregory Maxwell

body:
On 5/22/05, Magnus Manske <magnus.manske at web.de> wrote:
> * Later, we will allow only logged-in users to rate articles, right?
> Otherwise, we'll lose a great part of the perceived reliability
> improvement, IMHO. But how can we really set up this system if the data
> we use as a foundation for the decision is based on anon entries as well?

We can always collect anon votes but then exclude them from any
decision making process.


from_name: Timwi

subject: [WikiEN-l] Re: Announcing a policy proposal

body:
Bryan Derksen wrote:
> Richard Rabinowitz wrote:
>
>> Pretty good points, y'know. But single-digit years are pretty weird... :)
>
> The Long Now Foundation <http://www.longnow.org/> makes a policy of
> adding an extra zero to the beginning of years, to remind everyone to
> "think big" where future timescales are concerned. So this year would be
> 02005. How about making it AW 00004? As an added benefit, it'd be easier
> for software to sort. :)

Hm. Unfortunately, alphabetically "before" comes after "after".


subject: [WikiEN-l] Re: Anno Wikipædiæ

body:
Alphax wrote:
>
> I propose that everything be in UNIX time, like 1116743058544.

But that is anti-Windows anti-Microsoft POV!


body:
Gerard Meijssen wrote:
>
> Please read the original post and you will see that noone asked to
> re-license the WIKIPEDIA content.

Maybe *you* didn't, and maybe the original post didn't, but that doesn't
stop us from bringing it up anyway. We all know that the GFDL poses
problems for people wishing to re-use Wikipedia content legally (e.g.
teachers in schools). This is not a Wiktionary-only mailing list.
Licensing issues are on-topic here.


body:
Aphaia wrote:
>
> I would make it sure we can safely ignore those anonymous
> submissions' right as "licence holder" [or somehow possible, because
> they can't or hardly be contacted, but I am not sure]...

Just because we can't contact them, doesn't mean they lose their copyright.


subject: [Foundation-l] Re-licensing Wikipedia

body:
As for re-licensing Wikipedia, personally, if it was up to me, I would
be "bold" and do it the following way. I know that this is legally less
secure than what Mozilla did, but I think that given our situation, it
is reasonable. Someone in this thread mentioned that there is a judge
who gives legal advice to Wikimedia -- maybe if he/she could post to
give their opinion on whether this is legally feasible.

My idea is thus:

* Announce publicly the intended change of license from GFDL to WPL
   (Wikimedia Public License), and invite contributors to complain if
   they are unhappy with their material being re-licensed. Delete and
   re-write the material that is complained about.

* At some point (call it <date>), have all new articles licensed under
   WPL only.

* For one year starting on <date>, display a clear message on every page
   created before <date> stating that "This material is GFDL. We are
   intending to re-license it as WPL on <date+1year>. If you are the
   copyright holder and do not wish for your contributions to be
   re-licensed, please contact us."

* I imagine very few people will contact us, and we can state that
   people's silence is interpreted to mean they're OK with the
   re-licensing.

* Announce all of this extremely loudly in public. Post to all sorts of
   message boards, have news sites report it, etc. We have enough
   publicity to claim that we have contacted all contributors via public
   means. At that point, I believe it is no longer our responsibility if
   someone didn't notice anything for a whole year.

* One year after <date>, switch everything to WPL-only (or whatever you
   like). People may still complain after this, in which case we can
   still remove and re-write their work, but it is not really our
   responsibility that other people may have already re-used the work
   under WPL terms.

Timwi


subject: [Foundation-l] Re-licensing Wikipedia


list: commons-l

subject: [Commons-l] Re: 10,000 public domain paintings uploaded to Commons

body:
Erik Moeller wrote:
> Directmedia put the collection itself under the GFDL

What does this mean, considering each individual image is purportedly
public domain? Is this the "selection is a form of creative expression
too" problem again?


subject:
[Foundation-l] Re: 10,
	000 public domain paintings uploaded to Commons


from_name: Brion Vibber

subject: [Wikipedia-l] Validation feature update

body:
Magnus Manske wrote:
> Brion Vibber schrieb:
>>>Magnus Manske wrote:
>>>
>>>>I have treated the "user anonymity problem" by showing the user IDs
>>>>rather than their names. So, in its current state, it *is* possible to
>>>>find the user who did the rating, but it requires actual work :-)
>>>
>>>I find that very unusual from the perspective of how we do things, a
>>>step backwards from the open model.
>
>
> Maybe I didn't make myself clear (happens:-)
>
> I am "hiding" the user names just as a precaution, in case people don't
> want their ratings to be public.

But their ratings are *supposed* to be public. That's the whole point of
the exercise!

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20050522/96f7a561/attachment.pgp


subject: [Foundation-l] sco/fiu-vro in danger

body:
Thank you for your mails, Ryo and Sulev

On 5/20/05, Nicolas Weeger <nicolas.weeger at laposte.net> wrote:

> I can't find any hint of fiu-sco in the deletion log, can't see anything about it.

Surely because none of  those files were deleted. In my opinion it
sounds too strong to call a lising for RfD as "destroying".

I made a research if there is a possibility those files are already
legitimate parts of existing Wikipedia (meta policy allow us to speedy
it, like already transwikied media, copied article from some
mysterious reasons), but I didn't find any evidence to think so and
meta namespace is apparently not dedicated for normal encyclopedia
articles, therefore I thought those pages were appropriate to list on
the RfD.

Because of lisiting, he or she could get a chance to advocation, so I
think it was a fair decision for both parties. And I think it was a
rude action to put such pages withouth remark like "this is a test
page" specially on main namespace.

> > Now user of Wikimedia Aphaia threats to erase our work
> > and has already destroyed Scots test page!!

You misunderstood the situation unless you make a lie. Oscar lilsted
[[Scotland]] and I put a {{rfd}} tag. It is a part of our routine of
request for deletion and every editor has a right to do according our
policy. And both test main page and article haven't been deleted by
anyone, you have no right or reason to say the above. I request hereby
for apology on this bad and wrong labelling.

> Did you tell Aphaia about the purpose of the pages? [ok, read the revelant pages, she understood the purpose].

I know it after I listed those pages on RfD. And I would like to point
out those are actually substubs on main namespace without any links so
I wondered first if I could speedy them as test.It is very regret to
see my torelence is rewarded wiith such bad wording.

>Maybe she didn't read wikimedia-l and doesn't know what has been
decided. Remember: assume good faith first (no, i am not accusing
*you* of lying, merely pointing out that it's almost certainly a
misunderstanding between you two).

Thank you Ryo, no, I don't subscribe wikipedia-l. I am a Wikiquoter
rather than a Wikipedian. And I think it is too rude and unwise
Wikipedia-l introduces a new policy not to Wikipedia but to Meta which
has its own community independent from any particular project without
announcement or discussion. I pointed out there was no message on
meta, even on [[Meta:Babel]].

>Also, on VfD, she indicates that it's the *number* of planned
articles that bothers her, not their *existence*.
> (disclaimer: i don't know meta policy)

On IRC conversation yann agreed 100 are too many. If someone really
wants to create "a test wiki with some 100 or 200 articles",  I think
he would be better to create a separate wiki.

And also I oppose to put those test articles without remark on main
namespace. It is very annoying and rude from my view. You could put a
remark at the top, categorize them as "test articles" or put them into
subpages of your test page.

Thank you for considerations,.
--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


subject: [Foundation-l] sco/fiu-vro in danger


subject:
[Foundation-l] Re: STOP Translations needed: Wikimedia Commons
	reaches 100, 000 uploads

body:
'lut toute le monde,

On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:
> It is certainly what was planned. And this is why I suggested to Villy
> he writes the announcement beforehand. I already gave it to Amgine (2 or
> 3 weeks ago), so that wikinews also can prepare it beforehand as well.
> But it should not be on WMF before the official announcement.

D'accord, il y a me^me problem du Yahoo! annoncement peut-e^tre ...
>
> Well, we have a little organisation problem here. And this is the second
> time in this month.

> We have official statements to do... but they can not be public until a
> certain date (essentially because of partners asking that they do not be
> so)... and we hope them to be fully translated in several languages just
> on the date of publishing.

On Yahoo! annoncement it was enough for us to leave each translators
"please give a look to WMF home, and translate it, please" beforehand
or after it was released, and as you know, announcement became
available in over five languages within 20 minutes.

But we were fortunate and helped by many chances. If I was into
wikibreak before reading you message, or some of translators would
have not noticed our messages and so on ...

> Either we give up this idea, or we find a way to set up a "nominative"
> team of trusted translators to take care of it on a private wiki or by mail.

Sounds good. I don't mind if it would be private wiki or mail. Wiki is
better to collaborate but mail communication would be more robust (NO
"sorry- we have a problem ... *g)

--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


subject: [Wikitech-l] Re: date and cache

body:
Anthere wrote:
> http://meta.wikimedia.org/wiki/User_talk%3AAnthere#A_Desperate_Call_for_Help
>
> Some screenshots are displayed here about the bug.
>
> Seems really like cache no ?

Yes, I've got it figured out and I think fixed now.

There was another of those year 2025 entries on es.wikipedia.org. It was
hidden because it was a bot edit, but still screwed up the caching for
Recent Changes.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050522/b085a478/attachment.pgp>


body:
On 5/22/05, Ray Saintonge <saintonge at telus.net> wrote:
> In principle I have nothing against anon rating votes.  There could
> still be a problem when someone wants to change his vote.  The changes
> that are made to an article over time are the most likely reason for
> changing a vote.  For a registered user this should be no problem; the
> old vote is removed, and the new one added.  In the case of a dynamic IP
> the old vote would not automatically be removed.

Ratings are per version not per article, so it's somewhat less likely
that some one will want to change their vote. Usually editors will
just vote again on a newer version.


body:
This has been a problem on Wikinfo. We have set a limit of 200kb for images
(Wikipedia has a 2mb limit). Some images simply can't be used but reducing
the size and generally using thumbs produces difficulties in formatting
which have to be corrected by hand which is quite laborious. A Wikipedia
solution would have to be expressed as policy and have general support among
editors.

Fred

> From: "John R. Owens" <jowens.wiki at ghiapet.homeip.net>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Sun, 22 May 2005 16:11:26 -0500
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Subject: Re: [WikiEN-l] Re: Article size consistency 32k
>
> Geoff Burling wrote:
> <snip>
>> Download times are a very off-putting experience whenever one deals with
>> the Web, & very few web developers bother to optimize for speed -- or
>> even consider it a problem. Google is an amazing -- & very rare exception.
>> (I've had this discussion with a web designer friend several times, who
>> at least understands this issue -- although he's still a bit hobbled
>> with the "I want them to see the site how I choose, not how they may want
>> to choose" attitude.)
>>
>> And turning images off is not the solution. Much of the time, I want to
>> see some of the images in an article, such as  a map, or specific
>> photographs of a person or a place; I'm not interested seeing in every
>> known image with the proper license that could be related to the
>> subject.  Which is why I mentioned commons: not only does it support a
>> competition for the best images in a given category by allowing a
>> practically unlimited number of images to be uploaded, it does not
>> require the losers to be deleted because they are unused -- & allows
>> them to be available to compete in other categories.
>
> I don't know if this might have ever been suggested before already, but
> perhaps a change in software could allow us to set a maximum image size
> in our user preferences? Either in width/height, e.g. "always shrink
> images to less than 200 pixels wide or 150 pixels high, whichever is
> smaller", or in kB, e.g. "always shrink images to less than 10 kB".
> There should probably be a limited number of selections, so that the
> images could be cached the same way they are for regular thumbnailing.
> And of course, you probably wouldn't want the rule applied to Image:
> namespace pages.
> How hard would this be to implement, and would it strain the servers
> much to have to serve up even more different-size versions of the same
> picture?
> It seems to me it could certainly speed up the page loads for those on
> <56kb/s connections. But then again, you might also end up with weird
> formatting, when the author/editor inserting into a page doesn't know
> how large the image ends up being displayed.
>
> --
> John R. Owens
> ProofReading Markup Language : http://prml.sourceforge.net/
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Robin Shannon

subject: [Foundation-l] Re: license evolution

body:
2005/5/22, Ray Saintonge <saintonge at telus.net>:
> I noticed that clause with some  concern quite some time ago, though I
> didn't comment on it.  Article 10 of the licence deals with furute
> revisions, and at first glance appears to deal with the point.
> Nevertheless, even there I am not completely comfortable with it.  The
> article appears to give people a choice about which version whould
> apply.  That's fine when you're dealing with the handful of articles
> that a person might put onto his personal website, but it creates
> potential complications when many users are involved.  A person who
> contributes today may not like a GFDL version that appears five years
> later when he (or his heirs) are no longer reachable.

<snip />

> Ec

But just because it is avaliable under the next version, doesnt mean
it stops being avaliable under the older one. In other words, if i
license something under GFDL 1.0, and then in GFDL 2.0 they say
no-comercial use (which they wont, but that is not the point), it is
still avaliable under 1.0 so that it will forever be able to be used
for commerical purposes. In other words, only changes to make the
information more free would have a real effect.

paz y amor,
-rjs

--
hit me: <robin.shannon.id.au>
jab me: <robin.shannon at jabber.org.au>

This work is released into the public domain.
<http://creativecommons.org/licenses/publicdomain>


subject: [Foundation-l] Re: license evolution


from_name: Alphax

subject: [WikiEN-l] Re: Anno Wikipædiæ

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dpbsmith at verizon.net wrote:
>
>> From: Richard Rabinowitz <rickyrab at eden.rutgers.edu>
>>
>> Pretty good points, y'know. But single-digit years are pretty weird... :)
>
>
> Let's number 'em like checks, or serial numbers... just
> arbitrarily add 1000.
>
>

I propose that everything be in UNIX time, like 1116743058544.

- --
Alphax
OpenPGP key: 0xF874C613 - http://tinyurl.com/8mpg9
http://en.wikipedia.org/wiki/User:Alphax
There are two kinds of people: those who say to God, 'Thy will be done,'
and those to whom God says, 'All right, then, have it your way.' - C. S.
Lewis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkCWm/RxM5Ph0xhMRAvBEAJ9Tv8A4i4qzVsCKgZoHCHaZkRdJ3QCfQWkn
73m6tR5nmCcJiuKdofr+GNY=
=PQOf
-----END PGP SIGNATURE-----


from_name: Lee Daniel Crocker

subject: [Wikitech-l] Re: MediaWiki selected forTrophées du Libre

body:
On Sun, 2005-05-22 at 21:54 +0200, Anthere wrote:
> As we were looking for someone part of mediawiki development team to go
> to the ceremony, I contacted Hashar. He has not been around recently, so
> I am not sure he will answer.

Hey, if they'll spring for the flight...

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


subject: Re: [Wikitech-l] Re: MediaWiki selected for Trophées du Libre

body:
Anthere wrote:
> As we were looking for someone part of mediawiki development team to go
> to the ceremony, I contacted Hashar. He has not been around recently, so
> I am not sure he will answer.

Latest plan is: if we don't hear from Hashar real soon, Notafish and Ryo
will go.

Unfortunately it seems Ryo misjudged the timeframe when signing us up
for this thing so we didn't already have a plan ready. :)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050522/b42e83a2/attachment.pgp>


from_name: John R. Owens

body:
Geoff Burling wrote:
<snip>
> Download times are a very off-putting experience whenever one deals with
> the Web, & very few web developers bother to optimize for speed -- or
> even consider it a problem. Google is an amazing -- & very rare exception.
> (I've had this discussion with a web designer friend several times, who
> at least understands this issue -- although he's still a bit hobbled
> with the "I want them to see the site how I choose, not how they may want
> to choose" attitude.)
>
> And turning images off is not the solution. Much of the time, I want to
> see some of the images in an article, such as  a map, or specific
> photographs of a person or a place; I'm not interested seeing in every
> known image with the proper license that could be related to the
> subject.  Which is why I mentioned commons: not only does it support a
> competition for the best images in a given category by allowing a
> practically unlimited number of images to be uploaded, it does not
> require the losers to be deleted because they are unused -- & allows
> them to be available to compete in other categories.

I don't know if this might have ever been suggested before already, but
perhaps a change in software could allow us to set a maximum image size
in our user preferences? Either in width/height, e.g. "always shrink
images to less than 200 pixels wide or 150 pixels high, whichever is
smaller", or in kB, e.g. "always shrink images to less than 10 kB".
There should probably be a limited number of selections, so that the
images could be cached the same way they are for regular thumbnailing.
And of course, you probably wouldn't want the rule applied to Image:
namespace pages.
How hard would this be to implement, and would it strain the servers
much to have to serve up even more different-size versions of the same
picture?
It seems to me it could certainly speed up the page loads for those on
<56kb/s connections. But then again, you might also end up with weird
formatting, when the author/editor inserting into a page doesn't know
how large the image ends up being displayed.

--
John R. Owens
ProofReading Markup Language : http://prml.sourceforge.net/


body:
2005/5/22, Michael Snow <wikipedia at earthlink.net>:
> Mozilla has been at this since 2001, apparently, and it looks like they
> still have some non-relicensed code. They also inherited the right to
> relicense all Netscape-owned code, which is presumably still a
> considerable portion. The Wikimedia Foundation's ability to relicense
> content previously owned by Bomis would not get us anywhere near that.
> And while I don't know how many people have actually contributed code to
> Mozilla, I would guess that we're on a different level in terms of sheer
> numbers. I have this sneaking suspicion that the relicensing process
> would not scale very well, shall we say.
<snip />
> --Michael Snow

from [[Netscape]]
"The Mozilla engineers decided to scrap the Communicator code and
start over from scratch"

paz y amor,
-rjs

--
hit me: <robin.shannon.id.au>
jab me: <robin.shannon at jabber.org.au>

This work is released into the public domain.
<http://creativecommons.org/licenses/publicdomain>


subject: [WikiEN-l] Re: Anno Wikipædiæ

body:
Alphax wrote:
>
> Timwi wrote:
>
>>But that is anti-Windows anti-Microsoft POV!
>
> You say that like it's a bad thing :(

Well, other people seem to think that an anti-Christian or an
anti-American POV is a bad thing.


from_name: Magnus Manske

subject: [Wikipedia-l] Validation feature update

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brion Vibber schrieb:
> Magnus Manske wrote:
>
>> I have treated the "user anonymity problem" by showing the user IDs
>> rather than their names. So, in its current state, it *is* possible to
>> find the user who did the rating, but it requires actual work :-)
>
>
> I find that very unusual from the perspective of how we do things, a
> step backwards from the open model.

Maybe I didn't make myself clear (happens:-)

I am "hiding" the user names just as a precaution, in case people don't
want their ratings to be public.

Personally, showing the user names is just fine with me. I just wasn't
sure that's true for everyone else, so I took the cautious way.

If there's consensus to show user names, so be it!

Magnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkJ6kCZKBJbEFcz0RAst4AJ4ohEXqVRPVBqRIRU4a9MhEuMlGlwCfXc/4
Ce9H4yaCb8COYBUuEgVASdM=
=d/e8
-----END PGP SIGNATURE-----


subject:
[Wikipedia-l] Article validation: allow IP ratings for the raw
	data	phase

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Gerard schrieb:
> I suggest that we allow ratings by anonymous users (IP numbers), at least
> in 1.5.
>
> Reasons for this:
>
> * we've always worked by leaving things as open as possible and only
>   restricting as needed;
>
> * we're explicitly not using the data for anything important yet, so if ten
>   thousand rating spammers put [[Image:Autofellatio.jpg]] top marks for
>   everything, it won't actually affect anything;
>
> * the raw data will be of great interest to people, and as wide as possible
>   is good. (I can see the academics studying Wikipedia slavering for the
>   ratings data tarball ;-)

Two reasons against this:

* Later, we will allow only logged-in users to rate articles, right?
Otherwise, we'll lose a great part of the perceived reliability
improvement, IMHO. But how can we really set up this system if the data
we use as a foundation for the decision is based on anon entries as well?

* Currently, I store only user IDs with the ratings. Since anons don't
have user IDs, I'd have to change the SQL table for that, in addition to
"just" some code, which means work for me ;-)

Magnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkJ/CCZKBJbEFcz0RAgoxAJ99WS05p/UIa2ZX0mdMdwGT8gb7twCcDvXR
UciL+rrXmlxufNt9wW0PGXc=
=Ab1r
-----END PGP SIGNATURE-----


body:
Hojotoho,

On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:
> > On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:

Mailinglist
> The problem I have with this solution is
>
> * if it is by mailing list, it means yet another mailing list and to be
> fair, the increasing number of mailing list *is* problematic

Hmmm honestly I can't find what is your problem, tre`s che`re.
You can sort your mail in a proper way, and different address is very
sufficient to talk.

And mailinglist is more assured than Cc: list as you described:

> * if it is by regular mail, it is beginning to be a problem as well,
> because we have to remember to which editors to cc for translation, to
> which to cc for mandriva, to which to cc for legal issues, to which to
> cc for mediation issue on a specific wiki... it always end up forgetting
> one person... resulting sometimes in upset. This is getting too complicated.

(murmuring an old spell "read your f*ckin'  RFC822"*...)
* obsolate

You could add anything preferable to you in Subject: ...
Or a neat additional header like "X-WMF-Translation-Requests: "
(but I don't know it is possible on your environment.. perhaps not,
I'm afraid ...
mail environment on freemail accounts is tremendously awkward)

>  We absolutely need to find a way to deal with this, it is increasingly
> inefficient.

Reduce bureaucracy .. so perhaps curerntly the best way is "first
publish in some languages and then call for translators".

--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


from_name: Elisabeth Bauer

body:
Mathias Schindler wrote:
> Anthere wrote:
>
>> Oh, absolutely. Maybe my imagination on what would be exactly
>> displayed is going to far. My validations is very important of course.
>
> My imagination is "display everything". I think that this is not going
> too far.

Seconded. I want to see who rated an article in which way and which
other ratings the user did. Otherwise, the ratings are pretty useless.
Seventy XX voted that the article on the armenian genocide is not NPOV -
  is that a reason to work on the article? Or did they so just because
they are turkish nationalists who don't like the content of the article
and nobody else bothered to rate because all other people saw no
problems with the article?

Wikipedia as an open project needs transparency - no reason to hide data
here.

greetings,
elian


from_name: Delphine Ménard

body:
On 5/22/05, Timwi <timwi at gmx.net> wrote:
> > Directmedia put the collection itself under the GFDL
>
> What does this mean, considering each individual image is purportedly
> public domain? Is this the "selection is a form of creative expression
> too" problem again?

Yep, although I don't see it as a problem.  The database from which
those images AND the info that it gathers are, indeed, as a whole, put
under GFDL. This does not hinder in any way the actual public domain
state of the individual images, which of course can be used as any
Public Domain material.

However, should you wish to have access to the entire database,
(collection of images AND information), to make your own CD/DVD of
those 10000 works of art, THAT is under GFDL,a nd you will have to
comply with the GFDL to release it.

As I understood it, Directmedia has actually acquired the rights to
the database from the Yorck Project in order to release it under GFDL,
which I believe they did not *have* to do and which I find a pretty
good thing.

Cheers,

Delphine
--
~notafish


from_name: Brent 'Dax' Royal-Gordon

subject: [Wikitech-l] Re: privacy problem- GOT THE SOLUTION!!!

body:
Ivan Krstic <krstic at fas.harvard.edu> wrote:
> You can hide the IP completely from visitors,
> and just allow the admins to see it, or you can use an asymmetric cipher
> with a site-wide password. The latter option has the advantage that you
> can salt with another known property of the edit - say, timestamp - to
> get a new per-edit identifier for the same IP each time, avoiding the
> problem with Brent's solution.

I'm not sure you understand the problem we're trying to deal with here.

The idea is to make sure edits by the same person are connected
somehow.  Even as a non-admin, when I revert some vandal's work, I
need to be able to see what else that person has done, so I can figure
out if he's vandalized any other pages.  I need to know that it's one
person who keeps editing the same text into the page, not three.  What
I *don't* need is enough information to hack the person's computer or
figure out if he's a political dissident in my own country.  Hence, I
don't need the IP, but I need *something* that's constant for that
person.

If every edit will get a different "anonymous identity" (so to speak),
we might as well just list "Anonymous" as the editor.

Also, some people have asked why even sysops need access to IP
addresses.  The reason is that they need to be able to block entire
subnets occasionally, and to do that they need to know the IP.

--
Brent 'Dax' Royal-Gordon <brent at brentdax.com>
Perl and Parrot hacker


subject:
[Wikipedia-l] Re: Ratings and decisions (was: Article validation:
	allow IP ratings for the raw data phase)

body:
On 5/22/05, Erik Moeller <erik_moeller at gmx.de> wrote:
> Gregory Maxwell:
> As far as I'm concerned, the ratings should not be tied to *any*
> decision making process, anonymous or not. They are purely data
> collection. Whether a version is stable, whether it is neutral, whether
> it should go into the print edition, and so forth, these decisions
> should be made in consensus if at all possible. (This can be a speedy
> "If there are no objections, this article will be .." type process as
> long as all decisions are reversible.)

eh. They are not useful at all if not ever used as part of a decision
process.  I didn't suggest that we'd ever have policy that is directly
dependant on them.  When I decide I'm going to burn a CD of wikipedia,
I'll take the data and massage it before using it to decide what I put
on my CD.  If you don't like my decisions, feel free to not download
the ISOs I make :).

> A peer review process, in my opinion, must be tied to *discussion* first
> of all, and not to voting.

Right, well we have that today. A tally can be one way of formalizing
the results of a discussion.  I am a card carrying member of the
'voting is not the answer' crowd.

> Voting is a valid last resort, but not a
> generally good way to review an encyclopedia. It would be very bitter if
> a simple software feature could be used to overthrow years of
> consensus-building culture on Wikipedia.

You're jumping to a conclusion no one has suggested, relax. I agree.

> I am somewhat concerned that the fact that these ratings will be public
> will be used to influence discussion. I hope when this feature goes into
> beta, we will have a clear and public policy that these ratings have no
> relevance whatsoever to ongoing discussions and decision making
> processes. Otherwise I strongly oppose this feature being taken live in
> the first place. I have no objection to people using the ratings to
> build a list of pages to work on, as long as the question whether the
> pages do, in fact, need work remains a community decision.

People execute polls on wikipedia (at least the english one that I
read) all the time. It  hasn't killed us yet. :)


from_name: Ævar Arnfjörð Bjarmason

body:
I'd like to request that selected parts of the user table be included
in the dumps for statisticical purposes, namely the user_id, user_name
and user_options fields. It would be useful to have this data to
collect statistics on what parts of the preferences are actually being
used, and being able to compare this with the user_id (and user_name)
field would enable checking for what settings regular editors have and
how many change their default settings and so on.

And before people get all up in arms about this then no, this does not
include your email or the hash of your password (those are in
user_email and user_password respectively).


body:
On 5/22/05, Brion Vibber <brion at pobox.com> wrote:
> 2) We accept contributions with very little information on how to
> contact the author. We only rarely have e-mail addresses, and often all
> we have is a pseudonym or the network address and time at which the edit
>   was submitted. This makes it very hard for us to track down prior
> contributors to ask permission.

Agreed. And here a derivative problem would rise: how we treat
submissions from anonyomous (or unregistered users precisely).
Curently more than half JA WP & EN WQ contributors are anons. On other
projects, about 16-20%. I would make it sure we can safely ignore
those anonymous submissions' right as "licence holder" [or somehow
possible, because they can't or hardly be contacted, but I am not
sure]...

--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


body:
On 5/22/05, David Gerard <fun at thingy.apana.org.au> wrote:
> Mmmm. Possibly the results should not even be viewable for 1.5.

So are we to create yet another class of privileged user now? Those
with access to the verification system output?

What a horrible idea.  Our community is founded on openness and
cooperation and we can't achieve that if only a priesthood has access
to some information.  We should only form special classes of users
when there is a compelling need in terms of keeping the site
operational (thus only allowing some users to delete or block, and not
including cleartext passwords in our DB dump output).

> Yes. However, articles with low ratings will be an obvious place to go for
> people to fix things up.
>
> I think it'd be horrible if "low ratings" suddenly became a VFD reason.

Eh, 'low raitings' would never be a direct reason to VFD. It would be
a reason to rewrite the article, almost any reason suggests we rewrite
the article is a reason suggesting we keep the article.

However, the rating system could be (ab)used to help automate the
voting collection process for places where we already vote (FAC, VFD)
by providing a uniform way to collect votes and perform tallies.


subject: [Wikipedia-l] Re: Ratings and decisions

body:
David Gerard wrote:
> Gregory Maxwell (gmaxwell at gmail.com) [050523 08:15]:
>>On 5/22/05, David Gerard <fun at thingy.apana.org.au> wrote:
>
>>>Mmmm. Possibly the results should not even be viewable for 1.5.
>
>>So are we to create yet another class of privileged user now? Those
>>with access to the verification system output?
>>What a horrible idea.  Our community is founded on openness and
>
> No, no, only for 1.5 - so that the data gathering can proceed without any
> visible output as a running score.

Eeeeeeh? This doesn't make any sense, and sounds like a terrible,
terrible thing. I would rather remove the survey feature ("validation")
from 1.5 entirely than have some weird hidden secret survey thing.

(In any case, as always I strongly recommend removing it from the core
distribution and making it an extension. It's not a core function and
shouldn't be touching core code much if at all. Changing the
"validation" name would probably also be wise, as it doesn't seem to be
involved with validating anything.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20050522/f2c29833/attachment.pgp


from_name: Anthere

subject:
[Foundation-l] Re: STOP Translations needed: Wikimedia Commons -
	25th of may

body:
I noted that Erik set up the release date on the 23rd again rather than
on the 25th.

The official release is NOT ON THE 23rd, it is on the 25th. Please do
not make the official release 2 days before the official announcement.

ant


body:
This discussion is about how to improve the usability of the website.
Looking forward to a print edition the 2mb limit makes sense, but these very
large images ought not to make it difficult for the less advantaged to use
the website.

Some way needs to be found to not impose them on users whose equipment is
unable to handle them.

Fred

> From: Angela <beesley at gmail.com>
> Reply-To: Angela <beesley at gmail.com>, English Wikipedia
> <wikien-l at Wikipedia.org>
> Date: Mon, 23 May 2005 00:57:23 +0200
> To: English Wikipedia <wikien-l at wikipedia.org>
> Subject: Re: [WikiEN-l] Re: Article size consistency 32k
>
> On 5/22/05, Fred Bauder <fredbaud at ctelco.net> wrote:
>> This has been a problem on Wikinfo. We have set a limit of 200kb for images
>> (Wikipedia has a 2mb limit). Some images simply can't be used but reducing
>> the size and generally using thumbs produces difficulties in formatting
>> which have to be corrected by hand which is quite laborious. A Wikipedia
>> solution would have to be expressed as policy and have general support among
>> editors.
>
> A 200kb image isn't likely to be of a suitable quality for print, so I
> would recommend not imposing such limits on Wikipedia, where many
> people do have the goal of producing print versions. If anything, we
> ought to be encouraging higher resolution images with this aim in
> mind.
>
> Angela.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Jean-Baptiste Soufron

body:
> Thank you, that was quite interesting to read through - if there
> are other similar cases, I'd love to hear about them.

There are some but Mozilla is one of the biggest one. Actually, I
just studied FLOSS licenses evolution and I really think it is a
feasible thing.

> One significant obstacle, of course, is that we have a lot of
> anonymous editors where it's effectively impossible to trace the
> person who holds the copyright (as opposed to the computer from
> which they made the contribution). I'm guessing that Mozilla didn't
> have this problem. We probably also have a much larger volume of
> people who are not contactable via email, since we don't require an
> email address in order to sign up for an account.

The good solution is a well done tagging job... And time.

>
> And while I don't know how many people have actually contributed
> code to Mozilla, I would guess that we're on a different level in
> terms of sheer numbers. I have this sneaking suspicion that the
> relicensing process would not scale very well, shall we say.

I think it would, but is it a priority today ?

>
> The possibility of rewriting content we're unable to relicense is
> interesting to consider. It strikes me that one potential use for
> Magnus Manske's article validation tool would be to flag revisions
> when an article has been rewritten so as to remove the content that
> we can't secure permission to relicense. But anyway, if people are
> serious about actually relicensing, the longer they wait, the
> harder it will be.

Then we should prepare something around it.


body:
On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:
> I noted that Erik set up the release date on the 23rd again rather than
> on the 25th.
>
> The official release is NOT ON THE 23rd, it is on the 25th. Please do
> not make the official release 2 days before the official announcement.
>
> ant

Agreed. We can't be announcing something that is not ours before the
people who do it, that would not be fair, and actually particularly
distasteful.

If we cannot wait to announce the 100,000th file on commons, let us do
it on the 23rd. And have the other stuff on the 25th. The second will
boost the first anyway.

I would, however, find it equally smart to wait till both annoucements
can be made in the same press release.

best,

Delphine
--
~notafish


body:
And it appears that a mistake went along the way... either change of
date, or mistransmission of the information... but it is the 23rd....
Sigh. I revert myself then... and go make myself an herbal tea...

Ant

Anthere a ?crit:
> I noted that Erik set up the release date on the 23rd again rather than
> on the 25th.
>
> The official release is NOT ON THE 23rd, it is on the 25th. Please do
> not make the official release 2 days before the official announcement.
>
> ant


subject:
license roadmap ? (was: Re: [Foundation-l] Re: A license for the
	Ultimate Wiktionary)

body:
On another hand, we are all talking like if re-licensing should be
done right now in the blink of an eye... when we have time and we can
do it slowly.

If we need something like a roadmap :

1. A good first step could be to enable dual-licensing as the default
policy for new additions,

2. then to begin to authors of old-gfdl content to re-license their
stuff,

3. and finally to replace gfdl-only content if necessary.

That would allow a slow but smooth process for relicensing. With
adapted tagging, it could be a very good solution.

Jean-Baptiste Soufron

Le 22 mai 05 ? 09:01, Brion Vibber a ?crit :

> Robin Shannon wrote:
>
>> 2005/5/22, Michael Snow <wikipedia at earthlink.net>:
>>
>>> Mozilla has been at this since 2001, apparently, and it looks
>>> like they
>>> still have some non-relicensed code. They also inherited the
>>> right to
>>> relicense all Netscape-owned code, which is presumably still a
>>> considerable portion. The Wikimedia Foundation's ability to
>>> relicense
>>> content previously owned by Bomis would not get us anywhere near
>>> that.
>>> And while I don't know how many people have actually contributed
>>> code to
>>> Mozilla, I would guess that we're on a different level in terms
>>> of sheer
>>> numbers. I have this sneaking suspicion that the relicensing process
>>> would not scale very well, shall we say.
>>>
>>
>> from [[Netscape]]
>> "The Mozilla engineers decided to scrap the Communicator code and
>> start over from scratch"
>>
>
> To clear up any misunderstandings here: until very recently the
> majority
> of work on Mozilla was done by programmers employed by Netscape/AOL to
> work on it, and that code was thus owned by Netscape/AOL whether or
> not
> it dated back to the old Navigator or Communicator products.
>
> From the beginning, any contributions from third parties had to
> grant a
> special license (Netscape Public Licence / Mozilla Public Licene)
> which
> gave Netscape the right to include it in their proprietary
> Netscape-branded browser product as well as the open-source Mozilla
> releases.
>
> When the Mozilla project (then still headquartered at Netscape/AOL) a
> couple years later decided to add a GPL dual-license, Netscape/AOL was
> able to unilaterally change the license on code it outright owned. It
> was not able to do so on third-party submitted code for which only an
> NPL/MPL license was granted to them. For those third-party
> contributions, it was necessary to track down the authors and ask
> permission to change the license grant.
>
>
> We're similar to the Mozilla case in that we do not require third-
> party
> contributors to assign copyright to us, so a licence change not
> specified for in the licenses already granted to us would require
> seeking permission from the contributor.
>
> We're *different* from the Mozilla case in two important ways:
> 1) There is very little material that is owned outright by the
> Wikimedia
> Foundation, so virtually everything would require seeking permission.
>
> 2) We accept contributions with very little information on how to
> contact the author. We only rarely have e-mail addresses, and often
> all
> we have is a pseudonym or the network address and time at which the
> edit
>  was submitted. This makes it very hard for us to track down prior
> contributors to ask permission.
>
> </IANAL>
>
> -- brion vibber (brion @ pobox.com)
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


body:
On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:
> And it appears that a mistake went along the way... either change of
> date, or mistransmission of the information... but it is the 23rd....
> Sigh. I revert myself then... and go make myself an herbal tea...
>

May I have a cup?

No sugar, thanx.

Delphine

--
~notafish


body:
> If it's for purely statistical purposes, what do you need the user_id
> and user_name for?

Because being able to compare preferences with editing habits is
useful for just that.


from_name: Kate Turner

subject:
[Wikitech-l] Re: Request for selected parts of the user table to be
	included in the dumps.

body:
?var Arnfj?r? Bjarmason wrote in
gmane.science.linguistics.wikipedia.technical:

> I'd like to request that selected parts of the user table be included
> in the dumps for statisticical purposes, namely the user_id, user_name
> and user_options fields.

does mysqldump have support for dumping only certain columns?

> And before people get all up in arms about this then no, this does not
> include your email or the hash of your password (those are in
> user_email and user_password respectively).

i have no particular opinion, but i suspect some people would object to
preferences being included in dumps.

kate.


from_name: Eric

body:
Ivan Krstic <krstic <at> fas.harvard.edu> writes:
>
> Eric wrote:
> > Jumble up again
> > add something again
> > ---
> > And now you have a nonsense IP that's almost impossible to crack.
>
> No. You have a nonsense IP that anyone with the slightest determination
> can reverse-engineer. As I previously mentioned, you have two ways of
> ensuring strong anonymity. You can hide the IP completely from visitors,
> and just allow the admins to see it, or you can use an asymmetric cipher
> with a site-wide password. The latter option has the advantage that you
> can salt with another known property of the edit - say, timestamp - to
> get a new per-edit identifier for the same IP each time, avoiding the
> problem with Brent's solution.
>
> While it may well be enough for the level of anonymity you're striving
> for, claiming that your makeshift cryptographic hand-waving is "almost
> impossible to crack" is, at the very least, ignorant.
>
> -IK
>

You're probably right about the possibility of cracking the makeshift jumbling i
suggested earlier, and the fixed salt MD5 seems a better option of assigning a
unique number to each IP.

Your two ideas are good for anonymity, however, easily dealing with Vandalism is
 an equally important aim I cant afford to compromise with. If the IP's are
hidden, people would not be able to click on that unique number and see all the
edits by that certain number/IP. If the IP's are encrypted uniquely with
different salt each time, that too will disable people from checking the
vandalist acts made by the same IP. So one thing is clear: We need a unique
number for each IP. The chance of someone having the same IP as another person
is very small so that doesnt matter. The asymetric cypher you and others
suggested seems the best choice. Interestingly the anonymous edit tracking works
if the output 'code' (IP) starts with a number. If it starts with a letter (like
f7564ghfdd), it doesnt work. That problem is solved by adding a constant number
to each anonymous code (like 5f7564...).
Anonymity means that ideally, not even Admins should see the real IP so the real
IP should not be stored in the database even if MyPhPadmin is the only way to
access it.

Dealing with vandalism is the remaining issue:
The site will be controversial so there will be lots of vandals. Removing
anoynous editing is an option but I want to see how it goes before I'm forced to
remove anoymous editing.
I dont believe Wiki is equipped to deal with vandals easily. Looking at the case
of a vandal who does 50 edits in a single day and how WIKI itself advises to
deal with it:
- Click on all the rollback links
So we'd have to click 50 times on all the rollback links. Think about dealing
with this daily.

Since same IP's can be used by others, WIKI should add a certain unique random
number that makes that IP and that machine unique. Something that could come
from creating a cookie in that machine. So you'd have 111.111.111.111.PC_ABR34
PC_ABR34 identifies that certain PC so if another person is using another PC
with the same IP, they'll get a different number. The aim is to differentiate 2
people using the same IP and thus differentiate the vandal from the good guy.
With that in place, there should be a way to reject all the changes of a single
IP/PC with a few sysop clicks.

Also, there should be protection from bots which copy paste the same text in the
mass vandalism they do. Detection should be there to catch the same text being
posted in different pages from the same IP and block or atleast postpone
suspicious edits until someone approves it. Flood limits should be set between
edits so we can reduce the number of spam vandal edits. Automatic Alert pages
should be present for anonymous edits, particularly high volume edits from the
same IP.

So I think that WIKI is not well equipped to deal with anonymous vandalism. It
works for most of the information WIKI has which is nuetral, but this is a big
problem for controversial topics where vandals are bound to be more. Removing
anonymous editing has the disadvantage you know of already.
There definitely has to be a way of dealing with anonymous vandalism more
efficiently and quickly.

I'm glad the uniquq salt/code works, so I do have a way to ban a single IP but
dealing the vandalism is the next big problem.

Eric


body:
On 5/22/05, David Gerard <fun at thingy.apana.org.au> wrote:
> No, no, only for 1.5 - so that the data gathering can proceed without any
> visible output as a running score.
> I anticipate the results of the data-gathering test to be available in a
> downloadable form for people to pick over in close detail.

Eh, it sets a bad precedent. Users will claim we stole their anonymity
when we turn off the feature. Besides what will it hurt? sure it might
get used in fodder for silly arguments but so does everything else.

To make the test the most valid we should try to make it approximate
the real usage as close as possible. For example, it's likely that
people will vote more often when they disagree with the existing
votes. But that wont happen if the existing votes are private.

> > > I think it'd be horrible if "low ratings" suddenly became a VFD reason.
> > Eh, 'low raitings' would never be a direct reason to VFD.
> I'm sure someone said that about "notability", which isn't in the deletion
> policy either.

I'd encourage you to cite that one. :)

> You watch. I bet someone will try just that and someone else will think
> it's a dandy idea for culling Wikipedia.

Sure, but people will also argue that when we give a solog authored
article bad votes we are also making a POV statement driven by our
bias against him. :-)

People will claim many things. We are going into 1.5 with an explicit
statement that it's a test and shouldn't be used for anything.

> > However, the rating system could be (ab)used to help automate the
> > voting collection process for places where we already vote (FAC, VFD)
> > by providing a uniform way to collect votes and perform tallies.
>
> It provides some framework for article metadata, yes. Or at least for ideas
> on metadata.

Well version metadata. We already have article metadata of a sort,
think catagory tags and the like. :)


body:
Delphine M?nard a ?crit:
> On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:
>
>>And it appears that a mistake went along the way... either change of
>>date, or mistransmission of the information... but it is the 23rd....
>>Sigh. I revert myself then... and go make myself an herbal tea...
>>
>
>
> May I have a cup?
>
> No sugar, thanx.
>
>
> Delphine

I drank a full teapot of very hot green tea with mint. It is best very
very sugary. I'll make you one when you come in Clermont... my own
garden mint... no pesticides :-)

ant


subject:
[Wikipedia-l] Re: Article validation: allow IP ratings for the raw
	data phase

body:
David Gerard a ?crit:
> Magnus Manske (magnus.manske at web.de) [050523 01:05]:
>
>
>>* Later, we will allow only logged-in users to rate articles, right?
>>Otherwise, we'll lose a great part of the perceived reliability
>>improvement, IMHO. But how can we really set up this system if the data
>>we use as a foundation for the decision is based on anon entries as well?
>
>  Presumably the ratings data will be released for people to analyse any way
> they like.
>
>
>
>>* Currently, I store only user IDs with the ratings. Since anons don't
>>have user IDs, I'd have to change the SQL table for that, in addition to
>>"just" some code, which means work for me ;-)
>
>
>
> There is that minor point ;-) It just occurred to me that leaving it
> completely open would produce interesting data we wouldn't get otherwise.
>
>
> - d.

Allowing ip rating is mandatory. We should not limit ourselves to self
rating, but make it possible that those reading wikipedia (usually
without any account) could rate the articles as well.

So, my feeling is that we should keep ip rating open in the future as well.

Ant


from_name: David Gerard

subject: [Wikipedia-l] Article validation possible problems page

body:
Walter van Kalken (walter at vankalken.net) [050522 11:39]:
> David Gerard wrote:

> >http://meta.wikimedia.org/wiki/Article_validation_possible_problems
> >Lots of people hear about the feature and immediately ask, "what if someone
> >does xxx bad thing?" 1.5 is just to gather data, so we probably want as
> >wide an input range as possible, without trying to second-guess problems we
> >can't measure. But this list will help tell us what to look out for later.

> Although I agree partially I would at least want the agreement that as
> soon as we are using it for something serious we "reset" it within the
> parameters we by than have learned are needed.

Yep. We'll need to throw away the test-phase data before doing anything
real with it.

- d.


body:
On 5/22/05, Anthere <anthere9 at yahoo.com> wrote:

> I drank a full teapot of very hot green tea with mint. It is best very
> very sugary. I'll make you one when you come in Clermont... my own
> garden mint... no pesticides :-)

Can't wait, it's the only tea I like with sugar :)

Delphine
--
~notafish


body:
Delphine M?nard a ?crit:
 > On 5/22/05, Anthere
<anthere9 at yahoo.com> wrote:
 >
 >
 >>I drank a full teapot of very hot green tea with mint. It is best very
 >>very sugary. I'll make you one when you come in Clermont... my own
 >>garden mint... no pesticides :-)
 >
 >
 >
 > Can't wait, it's the only tea I like with sugar :)
 >
 > Delphine

Gneugneugneu...

I thought it real weird... Went through my mails ... tough on yahoo mail
box... found the most official one... it was written the official date
for release was 23rd... My memory is playing with me :-((
I hope you will accept my apologies...

/me put alcohol in the herbal tea and goes make an act of contrition.


subject: [Wikitech-l] Re: date and cache

body:
http://meta.wikimedia.org/wiki/User_talk%3AAnthere#A_Desperate_Call_for_Help

Some screenshots are displayed here about the bug.

Seems really like cache no ?

Anthere

Anthere a ?crit:
> Okay, I left them a message on the pump and a link to your message.
>
> Ant
>
>
> Brion Vibber a ?crit:
>
>> Anthere wrote:
>>
>>> Three times now in about a week or so, some spanish editors reported
>>> me a weird bug, that makes them see the wrong date on some pages or
>>> on recent changes. See the last comment
>>> http://meta.wikimedia.org/w/index.php?title=User_talk:Anthere&curid=521&diff=0&oldid=132341
>>
>>
>>
>> We could really use more details here, such as *what sort* of wrong
>> dates are seen. Specifically what they are, and specifically where they
>> are seen. Comparitive times (eg 'I saw "May 99, 2199" at the date for
>> three changes on Recent Changes at about 12:40 UTC on May 16') and
>> confirming screen shots may help.
>>
>> If it's an old cached page, vs it's the specific year 2025 thing, vs
>> it's a year 2003 thing, etc might have to be treated differently.
>>
>>
>>> ... I also noticed in the past few days a huge issue with cache.
>>> Three times yesterday, when I edited meta, for a new page, after I
>>> saved the page, there was nothing on it, and I had to reload to see
>>> the new page.
>>
>>
>>
>> This sort of thing is generally due to lagging in the database
>> replication, and is more prone when load is heavy (and especially when
>> painful page rename operations and such are going on).
>>
>>> Weirder is what is currently happening on the village pump on the
>>> french wikipedia (though part of it might be due to Paris servers).
>>>
>>> I connected anonymously yesterday, and I got the 14th of may page. I
>>> reload several times, forced reload... and still got the 14th of may.
>>
>>
>>
>> Cache updates might not be going through properly.
>>
>> -- brion vibber (brion @ pobox.com)
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikitech-
>
> l


body:
As we were looking for someone part of mediawiki development team to go
to the ceremony, I contacted Hashar. He has not been around recently, so
I am not sure he will answer.

Ant

Brion Vibber a ?crit:
> Nicolas Weeger wrote:
>
>>> The awards ceremony will be held in Soissons, France on May 26. Can
>>> someone attend representing the project?
>>
>>
>> Delphine (notafish) volunteered, but of course others can go!
>> She's not a developer or anything, but member of Wikim?dia France, so
>> that should do it if no one else can go.
>
>
> Cool! Well, notafish or <insert as yet nonexistent developer volunteer>
> should contact me to put them in touch with the TdL people soon so they
> know we have an official project representative coming and can arrange
> whatever they need to arrange. :)
>
> -- brion vibber (brion @ pobox.com)
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Stirling Newberry

subject: [Wikipedia-l] Jimbo interview on NPR Friday?

body:
The program in question is Christopher Lydon's new show "Open Source".
Mr. Lydon is one of the most ardent advocates of the change that is
taking place in our society, of which wikipedia is a part.

On May 22, 2005, at 8:24 PM, David Gerard wrote:

> David Gerard (fun at thingy.apana.org.au) [050521 23:57]:
>
>> There was a Jimbo interview about Wikipedia on Friday around 12 noon
>> Boston
>> time. I was in it as well by phone, so I'm interested in hearing it
>> :-) Did
>> anyone get a recording and/or transcription?
>
>
> Found it!
>
>     http://www.radioopensource.org/2005/05/16/pilot-3-the-wikipedia/
>
> 49MB MP3. iTunes gave a Spinning Beachball Of Death before we got to my
> bit, I'll try again tomorrow ;-)
>
> Where do these get indexed?
>
>
> - d.
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>


from_name: Erik Moeller

subject:
[Wikipedia-l] Re: Ratings and decisions (was: Article validation:
 allow IP ratings for the raw data phase)

body:
Gregory Maxwell:

> We can always collect anon votes but then exclude them from any
> decision making process.

As far as I'm concerned, the ratings should not be tied to *any*
decision making process, anonymous or not. They are purely data
collection. Whether a version is stable, whether it is neutral, whether
it should go into the print edition, and so forth, these decisions
should be made in consensus if at all possible. (This can be a speedy
"If there are no objections, this article will be .." type process as
long as all decisions are reversible.)

A peer review process, in my opinion, must be tied to *discussion* first
of all, and not to voting. Voting is a valid last resort, but not a
generally good way to review an encyclopedia. It would be very bitter if
a simple software feature could be used to overthrow years of
consensus-building culture on Wikipedia.

I am somewhat concerned that the fact that these ratings will be public
will be used to influence discussion. I hope when this feature goes into
beta, we will have a clear and public policy that these ratings have no
relevance whatsoever to ongoing discussions and decision making
processes. Otherwise I strongly oppose this feature being taken live in
the first place. I have no objection to people using the ratings to
build a list of pages to work on, as long as the question whether the
pages do, in fact, need work remains a community decision.

Erik


from_name: Aphaia

subject: [Foundation-l] Re: A license for the Ultimate Wiktionary

body:
Hallo, und thank you for your reply
On 5/22/05, Timwi <timwi at gmx.net> wrote:
> Aphaia wrote:
> >
> > I would make it sure we can safely ignore those anonymous
> > submissions' right as "licence holder" [or somehow possible, because
> > they can't or hardly be contacted, but I am not sure]...
>
> Just because we can't contact them, doesn't mean they lose their copyright.,

Okay, so they hold their copyright until 50 years will pass from their
submissions ...
So rigidly it is impossible for us to switch licence -- or we should
cast once all of anonymous submissions (because there is no
established contact between them and us, and we are not sure talk page
is enough for this purpose ...)
--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


subject: [WikiEN-l] Re: Anno Wikipædiæ

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Timwi wrote:
> Alphax wrote:
>
>>
>> I propose that everything be in UNIX time, like 1116743058544.
>
>
> But that is anti-Windows anti-Microsoft POV!
>

You say that like it's a bad thing :(

- --
Alphax
OpenPGP key: 0xF874C613 - http://tinyurl.com/8mpg9
http://en.wikipedia.org/wiki/User:Alphax
There are two kinds of people: those who say to God, 'Thy will be done,'
and those to whom God says, 'All right, then, have it your way.' - C. S.
Lewis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkI+v/RxM5Ph0xhMRAvHFAJ9F1Da9u25GncRx21+GieLShKAZogCfeiB3
ipoKMnf2AmMMBeMywuuIOP8=
=RNwh
-----END PGP SIGNATURE-----


from_name: Geoff Burling

subject: [WikiEN-l] Re: Article size consistency 32k

body:
On Mon, 23 May 2005, Timwi wrote:

> Geoff Burling wrote:
> >
> > It's an ancient version of Mozilla that I probably compiled
> > incorrectly when I installed in years ago
>
> In that case, I'm very afraid you have no grounds to complain.

Did I say that *was* the grounds for my original complaint? You asked, I
answered.
>
> > Download times are a very off-putting experience whenever one deals
> > with the Web, & very few web developers bother to optimize for speed
> > -- or even consider it a problem.
>
[snip]
>   Some of the Wikipedia skins do that
> too and you can happily read away the text as soon as it has been
> transferred. Unfortunately, Monobook isn't one of them, because it uses
> several CSS files which themselves include yet other CSS files...
>
For the record, I don't use the Monobook skin.

> > And turning images off is not the solution.
>
> I never suggested that. That wouldn't make the text appear any sooner
> anyway.

Did I say you had?
>
> > I'm not interested in seeing every known image with the proper
> > license that could be related to the subject.
>
> Then don't look at them.
>
So how I am to selectively view images? Last time this question was
raised (for reasons other than viewing convenience), the conclusion
was that this was an all or nothing situation: either every image linked
in a page gets downloaded -- or none do.

Should I start removing images from pages where I feel there are too
many? Or would this be an example of disrupting Wikipedia to prove a
point?

Timwi, I'm not clear where this exchange between us is going. My
original complaint is with contributors who want to insert more
images than I believe are necessary; at the moment I feel this is
an issue best solved by education, rather than policy or programming.
You seem to hear my generalized complaints about Web design philosophy
as attacks on how Wikipedia is designed; if I had specific complaints
about Wikipedia, I'd be filing detailed bug reports in the proper
manner.

If you think I'm picking a fight with you, I'm not; I'm just trying
to express my belief that the average contributor to Wikipedia sometimes
lacks a clear idea what constraints many end users endure when they
view Wikipedia. And this erroneous impression is related to a number
of other issues I have with Web design -- & with the assumptions
software designers far too often make about their intended audience.

I could expound a little about those, too, but it's probably better to
concede the floor to someone else at this point.

Geoff

Geoff


body:
On Sun, 22 May 2005, Fred Bauder wrote:

> This is the typical type of problem you run into with folks using old
> equipment and obsolete software. Like, for example, folks in Mexico who use
> castoff US equipment. Given our geek editor base, most of whom have
> reasonably good equipment, it is hard to put ourselves in the position of
> those who are are trying to access the internet under less than optimal
> conditions, but is is good if we could to the extent we are able and
> accomodate them to the extent we can.
>
If anyone out there is interested in the issues around this problem, let
me suggest checking the links in the RULE project. These people are
working at the coal face of making ancient hardware work with current
Linux distros, & last time I looked in on the list, they had a fair
number of questions from folks working with old 486s & low-end Pentiums
in third-world villages many miles from where the asphalt ends.

Geoff


from_name: Yann Forget

subject: [Wikipedia-l] Article validation: allow IP ratings for the rawdata	phase

body:
Hi,

Le Sunday 22 May 2005 17:05, Magnus Manske a ?crit :
> David Gerard schrieb:
> > I suggest that we allow ratings by anonymous users (IP numbers), at least
> > in 1.5.
> >
> > Reasons for this:
> >
> > * we've always worked by leaving things as open as possible and only
> >   restricting as needed;
> >
> > * we're explicitly not using the data for anything important yet, so if
> > ten thousand rating spammers put [[Image:Autofellatio.jpg]] top marks for
> > everything, it won't actually affect anything;
> >
> > * the raw data will be of great interest to people, and as wide as
> > possible is good. (I can see the academics studying Wikipedia slavering
> > for the ratings data tarball ;-)
>
> Two reasons against this:
>
> * Later, we will allow only logged-in users to rate articles, right?
> Otherwise, we'll lose a great part of the perceived reliability
> improvement, IMHO. But how can we really set up this system if the data
> we use as a foundation for the decision is based on anon entries as well?

I think it better if only logged in users can validate articles.
But well it depend what we want to do with this feature: selecting articles
for an offline publication or studying psychology and sociology of Wikipedia
readers ?
We have a precedent: only logged in users can upload images.

> * Currently, I store only user IDs with the ratings. Since anons don't
> have user IDs, I'd have to change the SQL table for that, in addition to
> "just" some code, which means work for me ;-)
>
> Magnus

Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


from_name: Sulev Iva

subject: [Foundation-l] sco/fiu-vro in danger

body:
22.05.2005 9:24:22, Aphaia <aphaia at gmail.com> kirot':

>> > Now user of Wikimedia Aphaia threats to erase our work
>> > and has already destroyed Scots test page!!
>
>You misunderstood the situation unless you make a lie. Oscar lilsted
>[[Scotland]] and I put a {{rfd}} tag. It is a part of our routine of
>request for deletion and every editor has a right to do according our
>policy. And both test main page and article haven't been deleted by
>anyone, you have no right or reason to say the above. I request hereby
>for apology on this bad and wrong labelling.

Hi Aphaia,

I apologize. Yes, I misunderstood the situation. It is my fault because I am still quite unfamiliar in MetaWiki. I had no idea that a
test page may disturb the Meta system. So I was very surprized when I saw my work listed to deletion. Then I saw in the deletion list
that both sco and fiu-vro test pages are really considered as rude and wrong action which should be deleted. Now I understand that it
was just a every-day routine for you to mark pages for deletion. But for me it was really shocking that my work done with heart is
wrong and bad and must be deleted. I did not understand how test pages for small languages' Wikipedias can be so seriously harmful that
they must be marked to deletion. It seemed to me so agressive and dangerous that I was really in panic. Now I understand that you just
followed rules and every-day routine. Thank you for suggestion to write to the beginnig of the test page remark "this is a test page".
I will do it. I am so sorry that I caused misunderstandings.

With best wishes
Sulev Iva
(V?rok)


subject: [Foundation-l] sco/fiu-vro in danger


from_name: Angela

body:
On 5/22/05, Fred Bauder <fredbaud at ctelco.net> wrote:
> This has been a problem on Wikinfo. We have set a limit of 200kb for images
> (Wikipedia has a 2mb limit). Some images simply can't be used but reducing
> the size and generally using thumbs produces difficulties in formatting
> which have to be corrected by hand which is quite laborious. A Wikipedia
> solution would have to be expressed as policy and have general support among
> editors.

A 200kb image isn't likely to be of a suitable quality for print, so I
would recommend not imposing such limits on Wikipedia, where many
people do have the goal of producing print versions. If anything, we
ought to be encouraging higher resolution images with this aim in
mind.

Angela.


body:
To: foundation-l, translators-l

I would like to appreciate current translation for our many
activities; Wikimania, WMF and Board Election. Thank you for your
engagement. And it is obvious we need your help more and more because
of expansion of our activities.

On 5/23/05, Anthere <anthere9 at yahoo.com> wrote:
> And it appears that a mistake went along the way... either change of
> date, or mistransmission of the information... but it is the 23rd....

Hmmm so it will be released on May 23 at last, filles?
Yann, you could put a brief note on the WMF (perhaps both on news-fr &
news-en), after you release it on proper sites, whenver the release
date will be? Erik, or any other commons editor, would you like to
provide us with German translation either directly on the WMF or on
meta?

Other language translators are called for, indeed. TOR, or other
Polish editor, do you have a time to synch WMF home to other language?
There is newly submitted downtime report by Midom and Portuguese
Wikipedia milestone, the 8th Wikipedia with more than 50,000, and only
those news are only available in En, Es and Zh.

And I hope we could release the Board Election announcement on May 24
finally ....

Best,

--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


from_name: Timwi

body:
Geoff Burling wrote:
>
> It's an ancient version of Mozilla that I probably compiled
> incorrectly when I installed in years ago

In that case, I'm very afraid you have no grounds to complain.

> Download times are a very off-putting experience whenever one deals
> with the Web, & very few web developers bother to optimize for speed
> -- or even consider it a problem.

Unfortunately, web surfers often do injustice to web designers who do.
Websites I make may not *finish* loading instantly the way Google does,
because I tend to use more images, but I make it a very important point
that the loading of the images (and CSS and other data) must not impair
the speed of appearance of the text. Some of the Wikipedia skins do that
too and you can happily read away the text as soon as it has been
transferred. Unfortunately, Monobook isn't one of them, because it uses
several CSS files which themselves include yet other CSS files...

> And turning images off is not the solution.

I never suggested that. That wouldn't make the text appear any sooner
anyway.

> I'm not interested in seeing every known image with the proper
> license that could be related to the subject.

Then don't look at them.

Timwi


subject: [Wikitech-l] Error in numRows()

body:
I just tried to create the page [[User:Timwi/test]] to test something,
and I get the following error. I tried several times, and I keep getting
the same thing. Looks like some operation succeeded only partially?...

Error in numRows(): Duplicate entry '2-Timwi/test' for key 2

Backtrace:

     * GlobalFunctions.php line 510 calls wfbacktrace()
     * Database.php line 528 calls wfdebugdiebacktrace()
     * Database.php line 717 calls databasemysql::numrows()
     * MessageCache.php line 307 calls databasemysql::selectrow()
     * MessageCache.php line 249 calls messagecache::getfromcache()
     * GlobalFunctions.php line 432 calls messagecache::get()
     * GlobalFunctions.php line 341 calls wfmsgreal()
     * OutputPage.php line 620 calls wfmsg()
     * Database.php line 386 calls outputpage::databaseerror()
     * Database.php line 333 calls databasemysql::reportqueryerror()
     * Database.php line 911 calls databasemysql::query()
     * Article.php line 873 calls databasemysql::insert()
     * EditPage.php line 239 calls article::insertnewarticle()
     * EditPage.php line 68 calls editpage::editform()
     * EditPage.php line 164 calls editpage::edit()
     * index.php line 176 calls editpage::submit()


body:
John R. Owens wrote:
>
> I don't know if this might have ever been suggested before already,
> but perhaps a change in software could allow us to set a maximum
> image size in our user preferences? Either in width/height, e.g.
> "always shrink images to less than 200 pixels wide or 150 pixels
> high, whichever is smaller", or in kB, e.g. "always shrink images to
> less than 10 kB".

This is absolutely brilliant. I love and support this idea.

Not because I have a slow connection (which I do, but I don't mind), but
rather because I'm getting annoyed when people make images so huge
because they have a 1280x1024 resolution and they think everyone else
must have that too. (I even had one replying back to me saying "Not
everyone has a resolution as low as yours, so please leave the image
this big!")

> And of course, you probably wouldn't want the rule applied to Image:
> namespace pages.

Yes, you do want it applied to Image:-namespace pages. The actual image
above it is not part of the page. :)

> But then again, you might also end up with weird formatting, when the
> author/editor inserting into a page doesn't know how large the image
> ends up being displayed.

People should learn that formatting is more than just looking at what it
looks like on *your* screen. Pages must be formatted in such a way that
they are readable on any resolution (OK, I guess we can assume a minimum
resolution of 800x600, but not more!). Resizing your window is all it
takes to check. Once this is done properly, varying sizes of images
shouldn't have any adverse effect on the formatting.

Of course, if it was entirely up to me, all images and taxo-/infoboxes
would be one big right-floating element and at the top of the article
source text. They would form a neat column on the right, with the text
entirely unaffected. This would solve pretty much all layout issues
instantly, especially the one with the section edit links. There are a
few special cases where this doesn't do, and in some circumstances you
really do want left-floating images, but they can always be handled on a
case-by-case basis.

Timwi


subject: [Wikitech-l] Re: Error in numRows()

body:
Timwi wrote:
>
> I just tried to create the page [[User:Timwi/test]] to test something,
> and I get the following error. I tried several times, and I keep getting
> the same thing. Looks like some operation succeeded only partially?...

Update: The page has appeared by now (and I've deleted it again). I
guess I got the error only after I *re*-submitted the page creation
request because I got the usual "The Wikimedia servers did not return a
response to your request" error message the first time.


body:
Magnus Manske (magnus.manske at web.de) [050523 01:05]:

> * Later, we will allow only logged-in users to rate articles, right?
> Otherwise, we'll lose a great part of the perceived reliability
> improvement, IMHO. But how can we really set up this system if the data
> we use as a foundation for the decision is based on anon entries as well?

Presumably the ratings data will be released for people to analyse any way
they like.

> * Currently, I store only user IDs with the ratings. Since anons don't
> have user IDs, I'd have to change the SQL table for that, in addition to
> "just" some code, which means work for me ;-)

There is that minor point ;-) It just occurred to me that leaving it
completely open would produce interesting data we wouldn't get otherwise.

- d.


body:
Jean-Baptiste Soufron (jbsoufron at gmail.com) [050523 02:42]:

> >The possibility of rewriting content we're unable to relicense is
> >interesting to consider. It strikes me that one potential use for
> >Magnus Manske's article validation tool would be to flag revisions
> >when an article has been rewritten so as to remove the content that
> >we can't secure permission to relicense. But anyway, if people are
> >serious about actually relicensing, the longer they wait, the
> >harder it will be.

> Then we should prepare something around it.

Easy in 1.5 - see [[m:Article validation feature]] and its associated
[[m:category:Article validation]] for info and discussions. Add a field to
the article ratings in Wiktionary.

- d.


body:
Brent 'Dax' Royal-Gordon <brentdax <at> gmail.com> writes:

>
> Ivan Krstic <krstic <at> fas.harvard.edu> wrote:
> > You can hide the IP completely from visitors,
> > and just allow the admins to see it, or you can use an asymmetric cipher
> > with a site-wide password. The latter option has the advantage that you
> > can salt with another known property of the edit - say, timestamp - to
> > get a new per-edit identifier for the same IP each time, avoiding the
> > problem with Brent's solution.
>
> I'm not sure you understand the problem we're trying to deal with here.
>
> The idea is to make sure edits by the same person are connected
> somehow.  Even as a non-admin, when I revert some vandal's work, I
> need to be able to see what else that person has done, so I can figure
> out if he's vandalized any other pages.  I need to know that it's one
> person who keeps editing the same text into the page, not three.  What
> I *don't* need is enough information to hack the person's computer or
> figure out if he's a political dissident in my own country.  Hence, I
> don't need the IP, but I need *something* that's constant for that
> person.
>
> If every edit will get a different "anonymous identity" (so to speak),
> we might as well just list "Anonymous" as the editor.
>
> Also, some people have asked why even sysops need access to IP
> addresses.  The reason is that they need to be able to block entire
> subnets occasionally, and to do that they need to know the IP.
>

Brent,
Thanks for putting it nicely!
MD5 hash is good for showing a consistent unique number but its now allowing me
to ban. It says "user doesnt exist" when I try to ban that hash.
I would greatly appreciate if you allow me to contact you and seek your help in
this as you are going to do the same thing I need too: Show an anonymous IP,
only admin sees the real IP and ban the blocks if people are being consistent
vandals, etc.
thanks a lot
Eric


from_name: John R. Owens

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Bain wrote:
| John R. Owens wrote:
|
|>I don't know if this might have ever been suggested before already, but
|>perhaps a change in software could allow us to set a maximum image size
|>in our user preferences? Either in width/height, e.g. "always shrink
|>images to less than 200 pixels wide or 150 pixels high, whichever is
|>smaller", or in kB, e.g. "always shrink images to less than 10 kB".
|
| Unfortunately I don't think this would be a workable solution, unless
| a thumbnail duplicate of every image was created at the time of
| uploading. That would be fairly straightforward to do, although it
| would be very resource intensive on the image server(s). (Is there
| more than one yet?) To shrink each image after every request before
| sending to the browser would literally kill the servers.
|
| A better way would be to allow for a user preference to have images
| either on or off by default, but have a link on the page to view a
| version with images. So if a user browsing with images off wanted to
| see an image, they could then re-load the page with images included.
| (If it's good enough for Outlook, then it's good enough for
| Wikipedia.)

That's why I was suggesting it would probably be desirable to have a
limited number of options for maximum width/height/filesize. If that
were the case, then a limited number of different sized copies could be
cached, the same way, if I understand correctly, that the thumbnail
images are cached after the first time they're viewd in the page. So,
for instance, you might have four width/height category choices, e.g.
100x75, 200x150, 400x300, and 600x400, and then you "just" need disk
space for four or less copies of each image (obviously, any images that
are, say, 250x200 would only need two extra copies, and those rather
small ones). I suppose that since this would be applied to pretty much
all images, instead of only those formatted to use thumbnails.
So what you might end up with, for the hypothetical picture and choices
given above (call the picture example.jpg), would be something like
creating files corresponding to the following URLs (I haven't figured
just which name hash directory it should actually belong in, especially
since I notice it does take the "XXXpx-" part into account):
http://upload.wikimedia.org/wikipedia/en/thumb/a/ab/Example.jpg
http://upload.wikimedia.org/wikipedia/en/thumb/c/cd/200px-Example.jpg
http://upload.wikimedia.org/wikipedia/en/thumb/e/ef/100px-Example.jpg
and perhaps something like
http://upload.wikimedia.org/wikipedia/en/thumb/1/12/5kb-Example.jpg
http://upload.wikimedia.org/wikipedia/en/thumb/3/34/10kb-Example.jpg

And then, if you've set your preferences accordingly, you get the 200px
or 100px version, and if not, you get Example.jpg itself in the viewed
page (assuming it hasn't been thumbnailed, either).
If this were to be done, I'd expect there should be a script to create
these thumbnails, run at a low priority, before the option were enabled,
so that the servers wouldn't bog down if many people using the option
started browsing image-laden pages. But I'd definitely want to see what
kind of demands it would make on disk space first.

And mind me, I'm not really pushing for the idea myself, just trying to
present an optimal solution to a problem that was brought up. I'm on
broadband, so it doesn't affect me much personally. I just thought I'd
throw the idea out there.

- --
John R. Owens
ProofReading Markup Language : http://prml.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkaBNEZJRR5c5RmQRAu7tAJoCcuPgYkIR61XdgOC2moJl+1skSACeKvJC
I2Dxy9gho04HAtY6KiT9+6k=
=Zt8Y
-----END PGP SIGNATURE-----


subject: [Wikitech-l] Re: failure notice

body:
I guess that settles it...

Notafish and Ryo are planned for Soissons :-)

Let's hope we get the price :-)

Ant

MAILER-DAEMON at yahoo.com wrote:
Hi. This is the qmail-send program at yahoo.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.

--- Below this line is a copy of the message.

Return-Path:
Received: (qmail 14350 invoked by uid 60001); 22 May 2005 09:29:03 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
b=J0HOvb5SHUNxTWvEYFOpMCmoNlBjh0INiBFNcslp1ZfNmIDLico0Hv24pbu2e/+cOOPVCqM7Y7H2eup8SP6pDx2GJwLPzBXBPivqdDmHgLgh3o0rolMJoBrHd47z4hQ/a7gvT0gsZgA/drS/nFyRWv3FHFT5qgZGZf6aWkXAs9M= ;
Message-ID: <20050522092903.14348.qmail at web32901.mail.mud.yahoo.com>
Received: from [81.251.16.108] by web32901.mail.mud.yahoo.com via HTTP; Sun, 22 May 2005 02:29:03 PDT
Date: Sun, 22 May 2005 02:29:03 -0700 (PDT)
From: Anthere
Subject: prix Special PHP des Troph?es du Libre.
To: hashar at altern.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Bonjour Hashar,

Serais tu disponible pour aller aux Troph?es du Libre
au nom des d?veloppeurs de Wikip?dia ?

Ce serait jeudi ? Soissons.

http://www.tropheesdulibre.org/article.php3?id_article=41

http://mail.wikipedia.org/pipermail/wikitech-l/2005-May/029684.html

Merci de me confirmer ou m'infirmer ta r?ponse.

Anthere

Discover Yahoo!
Stay in touch with email, IM, photo sharing and more. Check it out!
http://discover.yahoo.com/stayintouch.html

---------------------------------
Yahoo! Mail Mobile
 Take Yahoo! Mail with you! Check email on your mobile phone.


body:
On 5/23/05, Anthere <anthere9 at yahoo.com> wrote:
> I thought it real weird... Went through my mails ... tough on yahoo mail
> box... found the most official one... it was written the official date
> for release was 23rd... My memory is playing with me :-((
> I hope you will accept my apologies...
>
> /me put alcohol in the herbal tea and goes make an act of contrition.

Wait a moment, you remind me now on another official topic.
Where is your mail to WQ3, che`ere Florence ;-) ?

--
Aphaea
email: Aphaia @ gmail (dot) com


subject:
[Wikipedia-l] Article validation: allow IP ratings for the raw
	data phase

body:
Gregory Maxwell (gmaxwell at gmail.com) [050523 05:49]:
> On 5/22/05, Ray Saintonge <saintonge at telus.net> wrote:

> > In principle I have nothing against anon rating votes.  There could
> > still be a problem when someone wants to change his vote.  The changes
> > that are made to an article over time are the most likely reason for
> > changing a vote.  For a registered user this should be no problem; the
> > old vote is removed, and the new one added.  In the case of a dynamic IP
> > the old vote would not automatically be removed.

> Ratings are per version not per article, so it's somewhat less likely
> that some one will want to change their vote. Usually editors will
> just vote again on a newer version.

Mmm. Although the feature does offer to wipe your previous ratings.
Possibly it doesn't matter. Let's gather data and see ;-)

- d.


body:
Fred Bauder (fredbaud at ctelco.net) [050523 06:07]:

> This is the typical type of problem you run into with folks using old
> equipment and obsolete software. Like, for example, folks in Mexico who use
> castoff US equipment. Given our geek editor base, most of whom have
> reasonably good equipment, it is hard to put ourselves in the position of
> those who are are trying to access the internet under less than optimal
> conditions, but is is good if we could to the extent we are able and
> accomodate them to the extent we can.

I was recently on dialup (waiting for BT to switch on my new DSL) and using
my lovely but aging Thinkpad 560X - Pentium MMX 233MHz, 96MB RAM. Firefox
is horribly slow with 96MB RAM ;-) I managed to work on Wikipedia and even
do arbitration (a real test of the usability of a tabbed browser) - so
we're doing okay for equipment of that level. It'd be interesting to try it
in Netscape 3 on a 486 with 12MB RAM like I had up to 2001 ;-)

- d.


subject: [Foundation-l] Re: Notes from the last Board meeting

body:
> For official positions, a description of the job, description of what
> is expected from them, a list of tasks, and the limits of the position
> will need to be set in advance of people being appointed to these
> positions. A list of potential positions will be advertised this week,
> and anyone interested in them is invited to contact the board about
> taking these roles

Some proposed positions are now at
http://meta.wikimedia.org/wiki/Official_position#New_positions_proposed

Please comment at
http://meta.wikimedia.org/wiki/Talk:Official_position on any proposed
changes or additions to these new positions.

Angela.