body:
Consider me interested, then. Why did Jeronim quit?

~Mark

On Sat, 24 Jul 2004 21:07:40 +0200, Ronny Raschkowan
<ronny at kopfrechnung.de> wrote:
> Hello.
>
> No, it isn't. The main thing to do is to watch the moderation queue of
> the list, where mails are held because of several things ( posted by a
> non-member, etc). The list administrator would have to check that
> moderation queue, delete the spam and accept non-spam mails. It's easy
> and does not take a lot of time: The l.a. would just have to check the
> mail if he's unsure. Doing that on a daily basis, it would take maximun
> ten minutes. The second thing a list admin would have to do is to change
> a settings of the ML when there's a require for that (set archive to
> private, hide the list in the Mailing List overview, etc), what is done
> on a html interface. The last thing he has to do is regulary the list :).
> If a list admin would be unsure of the options he can do, i'd explain
> him (or her).
>
> Sincerly yours,
> Ronny
>
>
>
>
> Mark Ryan wrote:
> > Is it difficult?
> >
> > On Fri, 23 Jul 2004 18:53:20 +0200, Ronny Raschkowan
> > <ronny at kopfrechnung.de> wrote:
> >
> >>Hello!
> >>
> >>As far as Jeronim is no longer admin of the list, i would like to know
> >>if there is another person who would like to keep up the list and
> >>administrate it.
> >>
> >>I would of course explain the things what a list administrator should do
> >>to the user(s?) interested in it. The main -  activity is spam-deletion
> >>though..
> >>
> >>Volunteers? :)
> >>
> >>Sincerly yours,
> >>Fire
> >>
> >>_______________________________________________
> >>WikiEN-l mailing list
> >>WikiEN-l at Wikipedia.org
> >>http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: wikitech-l

source: pipermail-mbox

subject: [Wikitech-l] Server side compression

body:
As the servers are already strugling, have you wondered what serverside compression will cost in server side CPU consumption?

With the new upload limit of 5Mb this is a more serious issue. What could be a middle ground is to only server 1 Mb max pictures when the thumbs are used and leave the 5Mb pictures to a detail screen. The 1 Mb pictures would be saved. This would cost a lot of harddisk but it is easier to upgrade harddisks than processors.

On that subject, has a SAN ever been contemplated for wikimedia ?

Thanks.
  GerardM


list: wikien-l

from_name: Frank Pinter

subject: [WikiEN-l] Re: WikiEN-l Digest, Vol 12, Issue 47

body:
On Fri, 23 Jul 2004 17:12:07 +0000 (UTC),
wikien-l-request at wikipedia.org <wikien-l-request at wikipedia.org> wrote:
> Message: 6
> Date: Wed, 21 Jul 2004 17:43:49 +0100
> From: sean.clarke at guardian.co.uk
> Subject: [WikiEN-l] a proposal: wikigenealogy
> To: wikien-l at wikipedia.org
> Message-ID: <OF0F941193.3D44E948-ON80256ED8.005B988E at int.gnl>
> Content-Type: text/plain; charset=us-ascii
>
> hello
>
> I've long wished there were a genealogical database of European monarchs
> etc, where for instance Charlemagne exists as an entry with his wives
> listed in one column, his sons in another, his daughters in another, his
> known mistresses in another and his mother and father in two more.
>
> as it grew (wikistyle) you could then see things like: all male descendants
> of Charlemagne (or whoever) or choose to display the information in all
> sorts of ways.
>
> but I don't know a) how to do it or b) if wikipedia is the right place for
> it
>
> any thoughts?
>
> sc

Yes, that is a good idea. However, it should not be on Wikipedia,
according to [[Wikipedia:What_Wikipedia_is_not]]. Maybe if some big
Wikimedia person (like Jimbo, maybe) sees this a consideration for a
project may be started.

-- [[User:Wikiacc]]

============================================
Encoded with Double ROT13 - circumvention will be prosecuted!


subject: [Wikitech-l] Server side compression

body:
In  answer to Brion Vibber,
*I was referring to a post where server side compression was advocated based on the line/screen quality of the client side. This would happen when  the details of the screen are requested. The argument was that a 5 Mb picture is too big over dial up. Consequently the current practice of compress once and save would not apply.

PS Thanks for fixing wiktionary.

Thanks,
  GerardM


from_name: Dori

subject: [Wikitech-l] Article validation

body:
On Sun, 25 Jul 2004 18:16:30 +0200, Magnus Manske <magnus.manske at web.de> wrote:
> On the default skin (no other skins yet, sorry) you'll get a "validate"
> tab on all articles (no other namespaces), for both old and current
> versions. On a sidenote, I discriminate versions by their timestamp, as
> there is currently no other versioning system that works for both cur
> and old tables, AFAIK.

I haven't looked at this feature yet (it's not on test), but wouldn't
it be better to leave the tabs alone and add it to the toolbox
instead? The tab location is getting prettty crowded and it is hard to
see some of them on lower resolutions.

--
[[en:User:Dori]]


from_name: Jens Frank

subject: [Wikitech-l] Re: Image resizing questions...

body:
On Sun, Jul 25, 2004 at 01:28:03AM +0100, Timwi wrote:
> Jens Frank wrote:
>
> >Client-side scaling has the additional downside that the entire high-res
> >image has to be downloaded.
>
> Which is already the case.

Robert's question was:

| 2. How best should the
| Wikipedia deal with convenient viewing of multi-megapixel images

I wouldn't call sending 3MByte images "convenient".

Regards,

JeLuF


list: foundation-l

from_name: Anthere

subject: [Foundation-l] Re: Rewards for developers

body:
Dori wrote:
> On Sun, 25 Jul 2004 02:51:19 +0100, Timwi <timwi at gmx.net> wrote:
>
>>Dori wrote:
>>
>>
>>>It seems too convoluted and prone to conflicts to work effectively
>>>IMO. Donors are unlikely to identify all the features/bugs needing
>>>work.
>>
>>Aw, come on now. That's not really a problem. We can certainly give
>>Jimbo and/or the Board of Trustees the additional power to assign up to
>>25% of unassigned donated money to development task.
>
>
> I don't know that we could. It might piss off some donors if we said
> we'll use this for hardware, and we end up using it for software
> features. Although we do have some money that wasn't donated, and we
> could certainly advertise that doners could donate toward a specific
> feature/bug.

The prize we had in june has no string attached, so might be spent for
rewarding developers.
Also, I think that membership fees and donation should make it possible
that the donor or the member may be able to indicate how if wishes part
of the money to be spent. For now, I suppose we have three "specials"
* I would prefer that this be assigned to hardware
* I would prefer that this be assigned to software development
* I would prefer that this be assigned to wikireaders production
distribution

ant


list: wikimedia-l


body:
Elisabeth Bauer wrote:
> Timwi wrote:
>
>> The point is just anyone who personally thinks a particular feature or
>> bug is really overdue, should be able to directly encourage developers
>> by saying "I offer you $xyz for this". The more important a bug or
>> feature is to the community, the greater the amount of money will be.
>
>
> The point is that we currently have no decision making procedure for
> which features _should_ be implemented.
>
> Encouraging donators to offer money for features they want to be
> realized would make the situation even worse since most people not
> involved in coding don't "wish" things which would be necessary from a
> developer's point of view.
>
> My vision:
> * we should clean up these immense lists of feature wishes
> * we should establish priorities
> * the developers should say what makes sense and what doesn't
> * the developers should give an estimate for the most important features:
> ** how complicated it is to implement
> ** if someone's willing to do it
> ** or if there should be a bounty set out for it (because noone wants to
> do it or noone can do it)
>
> greetings,
> elian

Elian is absolutely correct.

I just had a look at
http://meta.wikimedia.org/wiki/MediaWiki_1.3_comments_and_bug_reports

Ihmo, that is just as a village pump; it might be nice to sweep the
floor sometimes :-)

On top of estimates listed by Elian, I would add estimate of "how long
could it take to be developped".

ant


from_name: Rick

subject: [WikiEN-l] Re: issues

body:
Have you seen [[Talk:Drew Barrymore]]? :^(

RickK

Mark Ryan <ultrablue at gmail.com> wrote:
What troubles me most is that people are fighting over trivial things.
If they are going to edit war, it should at least be a topic worth
arguing over.

~Mark

---------------------------------
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040725/6c2af637/attachment.htm


from_name: Brion Vibber

subject: [Wikitech-l] Re: RSS-Feeds

body:
Henry H. Tan-Tenn wrote:
> Brion Vibber wrote:
>> Feed requests seems to be hardcoded to a limit of
>> 50.
>
> Hmm, weird (and I hope I'm not belaboring this) but the limit can be
> much greater than 50, at least with the installed version.  Such that
> this dumps more than 100 items regardless:

Heh, whoops! Fixed.

-- 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/20040725/e710fbd3/attachment.pgp>


subject: [WikiEN-l] JBOC and his attacks on Roozbeh

body:
JBOC has taken his attacks on Roozbeh outside of Wikipedia.  See http://southwestasia.blogspot.com/2004/07/roozbeh-pournader-anti-iranian.html and http://jboc.blogspot.com/2004/07/roozbeh-pournader-attacks-imam.html.  We may want to keep an eye on any of his readers who might decide to come over to Wikipedia and continue JBOC's campaign of attack and POV.

RickK

---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040725/7a774aba/attachment.htm


from_name: Andy Rabagliati

subject: [WikiEN-l] Russian constitutional crisis of 1993

body:
Jimmy (Jimbo) Wales wrote:

> Today's featured article is a delightful read, but strikes me as
> terribly one-sided.  The adjectives applied to Yeltsin in this
> conflict are consistently negative, and the advjectives applied to his
> opponents are consistently positive.  The reality is much more
> complex.
>
> It is unusual for  a featured article to be so problematic.

As commented elsewhere, much of this article was written by 172, and the
bulk of it quite recent. I also enjoyed the read.

However NPOV a writer might consider themselves, I do not think one can
shoot the messenger.

My guess is the problem is the approval phase of a featured article,
something I know nothing about, but I would suggest that any proposed
featured article be checked to see if there has been cosmopolitan input.

I am aware of 172's writing style, having come across his contributions
to Zimbabwe-related pages.

I personally value his style as keeping pages that are easy candidates
for POV editing clear of mud-slinging, and suitably encyclopedic.

Cheers,     Andy - aka [[User:Wikiwizzy]]


from_name: Peter Danenberg

subject:
[Wikitech-l] Re: [MediaWiki-CVS] phase3/includes Skin.php, 1.234,
	1.235

references:
<E1BoMPp-00077n-ES@sc8-pr-cvs1.sourceforge.net>
	<20040724133954.GA27180@jeluf.mine.nu>
	<20040724143212.GA8820@localhost.localdomain>
	<cdvd4u$e1p$1@sea.gmane.org>

body:
On Sun, Jul 25, 2004 at 02:35:39PM +1000, Tim Starling wrote:
> MediaWiki coding style is described in docs/design.doc

     Exactly,  Tim;  but  I was hoping it was up for discus-
sion.

     Space=2 corresponds to the GNU  C  standard;1  and,  in
addition  to  being  Emacs'  native mode, would format hand-
somely in tab=8 browsers.

     The one-byte overhead may be an insufficient deterrent.

     Best, Peter

-----------
  1 http://www.gnu.org/prep/standards_23.html


from_name: Ashar Voultoiz

body:
Anthere wrote:
> I would like that all developers (others may
> participate as well of course) help setting up a list
> to define how development tasks completed could be
> rewarded.
>
> This will be followed by a public poll to define how
> the rewards would be perceived...
>
> and a private poll for developers to know what their
> opinion on the matter is
>
> Please, contribute to
> http://meta.wikimedia.org/wiki/Bounty
>
> thanks :-)

Hello,

Personally, having users happy when I fix a bug or implement a new
feature is enough for me. Imho a simple thanks through irc is more
rewarding than 10 US$.

--
Ashar Voultoiz


subject: [Wikitech-l] Re: Rewards for developers


from_name: Timwi

subject: [Wikitech-l] Re: Server side compression

body:
Gerard.Meijssen wrote:
> *I was referring to a post where server side compression was advocated
> based on the line/screen quality of the client side. This would happen
> when  the details of the screen are requested. The argument was that a 5
> Mb picture is too big over dial up. Consequently the current practice of
> compress once and save would not apply.

Well, this is the thing -- the server can't know anything about the
client side, including the screen size. Any guess would be no better
than a guess. This is why I suggested to let the server send the entire
big image and let the client do the scaling, but at the same time, I
agree with others that server-side scaling would increase accessibility
for users of slow connections.

Maybe it would make sense to just limit the images on description pages
to a width of 800px and a height of 600px. An image of that size is no
bigger than 200 KB, usually less than 100 KB. However, of course the
problem with this is that users of a screen resolution of 800x600 or
lower would have to scroll around to see it.

Another thing that I don't like about this is that it means you have to
click twice and produce two requests to the server in order to get the
full-size image.

Timwi


body:
Elisabeth Bauer wrote:

> The point is that we currently have no decision making procedure for
> which features _should_ be implemented.

I wouldn't have thought this decision was particularly hard.

> Encouraging donators to offer money for features they want to be
> realized would make the situation even worse since most people not
> involved in coding don't "wish" things which would be necessary from a
> developer's point of view.

Again, as I said, 25% of the money that donors don't explicitly assign
to a bug or feature, should be assignable by someone else. The Board of
Trustees was a suggestion, but if you think the developers should have
some say about this, then certainly we can come up with an
averaging-percentage system for this too (and give the Board of Trustees
permanent voting power). Something like:

At the beginning of Month A,
* I say: Feature X is worth $10, Y is worth $20, Z is worth $25
* You say: Feature X is worth $10, Y is worth $50, Z isn't worth anything
* Jimbo says:  Feature X is worth $22, Y is worth $26, Z is worth $11

Then we get: X = $14, Y = $32, Z = $12

Again, the averaging could optionally be weighted by voting power.

Timwi


body:
Dori wrote:

> On Sun, 25 Jul 2004 02:51:19 +0100, Timwi <timwi at gmx.net> wrote:
>
>>>It seems too convoluted and prone to conflicts to work effectively
>>>IMO. Donors are unlikely to identify all the features/bugs needing
>>>work.
>>
>>Aw, come on now. That's not really a problem. We can certainly give
>>Jimbo and/or the Board of Trustees the additional power to assign up to
>>25% of unassigned donated money to development task.
>
> I don't know that we could. It might piss off some donors if we said
> we'll use this for hardware, and we end up using it for software
> features.

We shouldn't be saying we'll be using the money for anything particular.
That just ties our hands.

> I simply thought that the process had too many rules to be properly
> understood and to work well.

"Too many rules"? Are you saying it's too complicated and you don't
understand how it's supposed to work? It's not complicated at all; as I
said, the LiveJournal Bazaar worked similar to this, and developers
there were perfectly happy with it and understood how it worked.

If you have any specific questions about the system, feel free to ask.
Please don't dismiss it solely on the grounds that you don't understand
it; if you have any specific criticism that you think makes the system
unsuitable, I will happily accept that. Otherwise, I would really like
to give this a try, at least for a few month until we can definitely say
that it doesn't work well. I'll do all the necessary coding for the
voting interface, the averaging, etc.

> Yes, I did misunderstand that. I still don't see it as a fair method
> though. Averages could give some screwey results which might leave
> people who made more work, receive less compensation.

It is perfectly fair. Think about it. Who did "more" or "less" work is
completely subjective. Everyone has their own perception of what
percentage of the work was done by certain people. By averaging out the
percentages, we create some sort of "collective subjective judgment",
and everybody's own judgment will be part of it.

If you're afraid that people might cheat the system by giving ridiculous
percentages, this isn't a problem either. Firstly, only people who have
actually done development in the last month, and the Board of Trustees
perhaps, have voting power. You won't get much voting power if you're
not a responsible individual. Hence, when averaging stuff, the
"irresponsible percentages" will be given much less weight.

Additionally, of course, you shouldn't be able to vote for yourself. :)

>>>It might also lead to races between developers who start
>>>stepping on each other's work in order to get more money.
>>
>>I don't think that will be a problem. Such blatantly un-co-operative
>>people can easily be penalised with very low percentages. People will
>>know they will get more money if they use their common sense to behave
>>within proper forms of etiquette.
>
> It's not necessarily blatant. It could even be inadvertant, or it
> could be as simple as if I am going to do this part I might as well do
> that part or I would prefer that part to work like I plan it. Coding
> is much harder to do collaboratively than editing (unless we're
> talking about unrelated parts).

A bug or feature should be assigned to a particular developer (this is a
core feature of BugZilla, which I'm still hoping we will switch to in
the long run). It will be easy to enforce a policy that only the current
assignee of the bug may work on it. (I admit that the fact that this
worked in LiveJournal is no surprise because nobody has CVS access there
and people only submit patches to BugZilla. But even on Wikipedia, I
suppose CVS access should be given only to responsible developers who
will follow this rule.)

Any more questions? ;-)
Timwi


subject: [Wikitech-l] Re: Rewards for developers

body:
Ashar Voultoiz wrote:

> Personally, having users happy when I fix a bug or implement a new
> feature is enough for me. Imho a simple thanks through irc is more
> rewarding than 10 US$.

Well, this is a noble attitude, and I applaud you for it, but in
practice few people think like that.

Myself included, I won't deny.

Timwi


from_name: Tim Starling

body:
Peter Danenberg wrote:
>      Speaking of which: does wiki policy on indentation pro-
> vide tab=8?
>
>      Best, Peter

MediaWiki coding style is described in docs/design.doc

-- Tim Starling


from_name: S. Vertigo

subject: [WikiEN-l] I blocked User:JBOC

body:
--- David Gerard <fun at thingy.apana.org.au> wrote:
> Of late, admins have been happier to put 24 hour
> blocks (after a warning!) on
> purveyors of egregious personal abuse - particularly
> in edit summaries.
> Second offense, triple the block.
>
> Continued this way, JBOC would, after his seventh
> bout of egregious personal
> attacks, be blocked for *two* years ;-)

So, lets see: thats:

1 = 24,
2 = 72,
3 = 216,
4 = 648,
5 = 1944,
6 = 5832, and...
7 violations = 17,496 hours or 729 days or 1.99593585
years!

Seems about right.
-S

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail


subject:
[WikiEN-l] Somebody with a good reputation will write a critical
	article about Wikipedia and esp. the article [[Prem Rawat]]
	that is locked now

body:
--- Andries Krugers Dagneaux <andrieskd at chello.nl>
wrote:
> I receive an email from somebody who expressed his
> disappointment with
> Wikipedia.

So did I once. So did I.

-S

_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com


subject: [Wikitech-l] Re: Bad HTML:

references:
<20040713230808.0e443242@camber> <40F594F6.1000501@easynet.be>
	<shsmbuqpi8.fsf_-_@tux.gnu.franken.de>
	<sh3c3hwyet.fsf@tux.gnu.franken.de>

body:
On Sat, Jul 24, 2004 at 11:24:26AM +0200, Karl Eichwalder wrote:
> Karl Eichwalder <ke at gnu.franken.de> writes:
>
> > Please stop generating sequences as follows
> > (<URL:http://de.wikipedia.org/wiki/John_Ruskin>):
> >
> >

> >

> >
> > If vertical whitespace is required (why?), use CSS properties.
> > Unfortunately, browsers do not treat those sequences as empty...
>
> FYI: This annoying bug is still visible :-(

This is strange. I use Mozilla for the following.

As an anonymous user, when viewing the entire page source, the
p/br/p sequence appears after the weblinks:

Weblinks

http://www.lancs.ac.uk/users/ruskin/default.htm

Selecting everything from Weblinks until the categories, and clicking
"view selection source", I get this, not including p/br/b:

Weblinks

http://www.lancs.ac.uk/users/ruskin/default.htm

Eingeordnet unter: Brite | Maler | Englischsprachiger Schriftsteller

Using Lynx to get the source (as anonymous user, no cookies set, I get the
later version, without p/br/p sequence.

Regards,

JeLuF


from_name: Roozbeh Pournader

subject: [WikiEN-l] What to do when you are attacked personally

body:
Hi. I've been with the English Wikipedia for quite some time, I'm even
an admin, but I still don't know what to do when I'm personally
attacked (sometimes heavily). I usually go forward and simply
[[Wikipedia:remove personal attacks]], but where should I exactly go
for these, after I am attacked even after mentioning the related
Wikipedia policy? The arbitration committee? Or to another admin for a
block?

For some example, see
<http://en.wikipedia.org/wiki/User_talk:JBOC#External_links>.

roozbeh


from_name: Alfio Puglisi

subject: [Wikitech-l] Re: Bad HTML:

body:
On Sun, 25 Jul 2004, Jens Frank wrote:

>As an anonymous user, when viewing the entire page source, the
>p/br/p sequence appears after the weblinks:
>
>
Weblinks

>

>
"http://www.lancs.ac.uk/users/ruskin/default.htm">http://www.lancs.ac.uk/users/ruskin/default.htm

>

>
>

>

>

Using firefox 0.9 as an anonymous user I don't see any of those

in the page source. Is this some kind of mozilla bug?

Alfio


subject: [Wikitech-l] Article validation

body:
On Sun, 25 Jul 2004 19:40:38 +0200, Magnus Manske <magnus.manske at web.de> wrote:
snip
> >I haven't looked at this feature yet (it's not on test), but wouldn't
> >it be better to leave the tabs alone and add it to the toolbox
> >instead? The tab location is getting prettty crowded and it is hard to
> >see some of them on lower resolutions.
> >
> >
> >
> I thought that "edit, watch, validate" belongs together somehow. These
> are all about the very page you are looking at that moment. The toolbox
> is somthing different, according to my intuition at least :-)

I am not sure where validate would go in a perfect world, I was simply
saying that some people might not even see it due to the layout.

>
> If it proves impractical, it can be easily changed. If moving the link
> will be the worst bug to fix, I'll celebrate!

Well, I haven't seen how this feature works. Any chance it will be put
on test some time soon? Of course I also hope that there are no
problems with it. It's something that could really help us if it works
out well.

--
[[en:User:Dori]]


from_name: Krzysztof Kowalczyk

subject: [Wikitech-l] Rewards for developers

body:
On Sun, 25 Jul 2004 17:58:38 -0400, Bill Clark <wclarkxoom at gmail.com> wrote:
> People tend to be competitive.  Turn it into a game.
>
> Those making requests should be given a certain number of "points" per
> day that they're allowed to assign to their requests (or to already
> existing requests).  When a developer completes a task, they're
> awarded all the points for that task.
>
> Then you need a scoreboard that shows which developers are "winning".

Open-source is 20 years old. There are thousands of open-source
projects. Some are successful, most are not. The development of
open-source projects is on public record. There are mailing list
archives, project web sites, history of CVS commits.

We don't have to guess or invent new ways of making open-source
projects succesful. Much safer strategy is to analyze past, which is
rich with examples, and identify processes that lead to success. Those
who forget the past...

I've followed my share of open-source projects. Big and small,
succesful and failed.

I've never seen "rewarding with points" system applied in practice.
Therefore it's unlikely that it's a good idea and it's certainly very
risky to try things no-one has tried before.

I've seen attempts to apply "bounty" systems to open-source (sorry for
lack of reference, I forgot the names of the projects). They all
failed (as in: didn't produce a lot of new, good code).

I don't know a single succesful open-source project that implements
bounty system. Even less one that can claim that its success is caused
by bounty system.

I've seen projects that flourish despite not having any external
rewards systems in place (mono is a recent example, but there are of
course plenty of them: GNOME and KDE projects, subversion, eclipse,
gcc and I would consider wikimedia to be quite successful so far as it
works well enough to support a massive undertaking as WikiPedia).

It's safe to conclude that you don't need bounty system to have
succesful project.

The real question is: what is?

I think the discussion "is bounty system good or bad" is premature,
stems from a haphzard idea of an individual (as opposed to systematic
exploration of possible options to improve mediawiki project).

It diverts attention from much more important question: "what are the
ways to improve mediawiki".

Krzysztof Kowalczyk | http://blog.kowalczyk.info


from_name: Bill Clark

subject:
[Wikitech-l] Some news of the french servers. Access to the
	developers

body:
On Sat, 24 Jul 2004 18:47:15 +0200, M?d?ric BOQUIEN
<mederic.boquien at laposte.net> wrote:

> For the people with root access, i'll send the password of each server

Not trying to start a flame-war or anything.. but I really suggest
just using RSA/DSA keys for root access as well.

The traditional policy of "log in as a regular user, then su to root"
is actually less secure than just using key access.  People only stick
with it because of inertia.

In ye olden days before strong public key encryption, passwords were
sent in plaintext, so it made sense not to log in directly as root (to
make things slightly more difficult for packet sniffers).

Using su is more secure than direct login with plaintext passwords.
But we don't use plaintext passwords anymore.  We use strong
encryption.  Strong encryption is more secure than su.  Using su is a
security risk nowadays.  Your security is only as strong as the
weakest link, and su is a weak link.

If somebody compromises a user account capable of using su, then it's
trivial to modify that user's PATH and put in a fake su script that
spoofs a failed login, sends the password to Bad Guy, and then removes
all traces of itself.

It also makes it simpler to add or remove root access, if you only
have to worry about changing the authorized_keys file, rather than
changing the password and re-notifying everyone.  Passwords are a
security risk, and should basically never be used (I actually disable
password logins entirely on most of my production machines, and force
everybody to use pub keys for everything).

Just my $0.02 (US).

-Bill Clark


from_name: Robert Graham Merkel

subject: [Wikitech-l] Client-side image shrinking bad...

body:
On Sat, Jul 24, 2004 at 01:40:17PM +0000, wikitech-l-request at wikimedia.org wrote:
>
> > Seeing we want the ability to make printed material out of Wikipedia
> > content, uploading full-resolution images is IMO the way to do it.
> > However, such images currently break the image description page.
>
> Suggestion: Have a magic word, __SCREENSIZE__ or something like that,
> which you can put on an image description page, and it will set
> style="width: 100%" on the image (thus telling the browser to size the
> image in such a way that its width fits the bounding rectangle). Of
> course, __SCREENSIZE__ should be omitted when the image is very small,
> because then "width: 100%" would tell the browser to enlarge it.
>
> Of course, this isn't without problems. If someone's bounding rectangle
> is about 800 pixels wide (it's 826 for me at 1024x768 with Monobook) for
> someone, but 1000 pixels for someone else (possibly using 1280x1024),
> then one of them will want __SCREENSIZE__ to be inserted, while the
> other will complain that it enlarges the image unnecessarily. :/

This approach is fine for broadband users, but it doesn't help for modem
users, who apparently can still be found in massive numbers (modems?
haven't used one of those in years...)  If we're going to shrink the
image, we should shrink it on the server, rather than on the client.

--
---------------------------------------------------------------------------
                                           Robert Merkel
                                     robert.merkel at benambra.org
                                        http://benambra.org

If ignorance ever reaches  a barrel, I want the drilling rights
to his head.
  -- a political opponent on President George W. Bush
--------------------------------------------------------------------------


subject: [Wikitech-l] Rewards for developers

body:
On Sat, 24 Jul 2004 18:09:54 -0700 (PDT), Anthere <anthere9 at yahoo.com> wrote:
> I would like that all developers (others may
> participate as well of course) help setting up a list
> to define how development tasks completed could be
> rewarded.

People tend to be competitive.  Turn it into a game.

Those making requests should be given a certain number of "points" per
day that they're allowed to assign to their requests (or to already
existing requests).  When a developer completes a task, they're
awarded all the points for that task.

Then you need a scoreboard that shows which developers are "winning".

This is basically the same thing Ashar was talking about (making users
happy) except that it's easier to quantify.

-Bill Clark


from_name: Magnus Manske

subject: [Wikitech-l] Article validation

body:
I hereby declare the article validation function to be operational with
basic functions, which means it works but is still full of little icky
bugs :-)

To try, use CVS HEAD and set "$wgUseValidation = true ;" in your
LocalSettings. What to vote for is determined in Language.php by
"$wgValidationTypesEn" (demo is provided in CVS).

On the default skin (no other skins yet, sorry) you'll get a "validate"
tab on all articles (no other namespaces), for both old and current
versions. On a sidenote, I discriminate versions by their timestamp, as
there is currently no other versioning system that works for both cur
and old tables, AFAIK.

 From the validation page, you also get a link to a Special Page (tm)
showing the statistics for the different versions of this article.
Breaking down statistics further was not implemented due to privacy
reasons and my personal lazyness ;-)

There are plans for some kind of "German 1.0" in the near future, not to
mention the English one and the one-volume printed version, so it would
be nice if we could get this running soon.

Magnus


from_name: Jerome Jamnicky

subject: [WikiEN-l] Re: Researching a new Wikien-l mailing list admin.

body:
On Sun, 25 Jul 2004 11:46, Mark Ryan wrote:
> Consider me interested, then. Why did Jeronim quit?
>
> ~Mark

Because I only volunteered because nobody was doing the job, and it turned out
that this was a dumb idea because administering this list was permanently way
down on my todo list.  I've been added to wikitech-l admins, which is a list
I pay more attention to and am directly interested in.


subject: [Wikitech-l] Re: All wiktionaries are not reachable

body:
Gerard.Meijssen wrote:
> When I try to reach en:wiktionary.org or nl:, de:, I get an error message: redirection limit exceeded or cookie problems. So I tried Internet Explorer which does not load the page either, no error message though.
>
> Can someone please find out what the problem is ??
>
> Thanks,
>   GerardM

Fixed

-- Tim Starling


subject: [Wikitech-l] Article validation

body:
Dori wrote:

>On Sun, 25 Jul 2004 18:16:30 +0200, Magnus Manske <magnus.manske at web.de> wrote:
>
>
>>On the default skin (no other skins yet, sorry) you'll get a "validate"
>>tab on all articles (no other namespaces), for both old and current
>>versions. On a sidenote, I discriminate versions by their timestamp, as
>>there is currently no other versioning system that works for both cur
>>and old tables, AFAIK.
>>
>>
>
>I haven't looked at this feature yet (it's not on test), but wouldn't
>it be better to leave the tabs alone and add it to the toolbox
>instead? The tab location is getting prettty crowded and it is hard to
>see some of them on lower resolutions.
>
>
>
I thought that "edit, watch, validate" belongs together somehow. These
are all about the very page you are looking at that moment. The toolbox
is somthing different, according to my intuition at least :-)

If it proves impractical, it can be easily changed. If moving the link
will be the worst bug to fix, I'll celebrate!

Magnus


from_name: David Gerard

subject:
[WikiEN-l] Re: [Wikipedia-l] Paper Wikipedia 1.0: a modest rant^W
	proposal

body:
On 07/23/04 16:41, David Gerard wrote:
> I've been thinking about it and reading and researching about it and
> talking incessantly on IRC about it and writing on the lists about it.
>     http://en.wikipedia.org/wiki/User:David_Gerard/1.0
> This sets out a concise action plan for a paper Wikipedia 1.0, letting
> the wiki do the work. It sets out milestones and what is needed for
> them.

Mark Ryan said on IRC, 'huh, I didn't see the page. I thought the email
was a bit short for an action plan ...' So I'm sending it to the list too!

- d.

User:David Gerard/1.0
 From Wikipedia, the free encyclopedia.

We've wibbled on the mailing lists and various wiki pages about Wikipedia 1.0
for over a year now. We now have an actual publisher asking us for a paper
version. We need an action plan.

The key to success will be to harness dilettantism and let the wiki do the
work. That's what got us this far.

The plan below includes milestone versions 0.7, 0.8, 0.9 and 1.0. Please think
of earlier milestones. To get milestone 0.7, we need a distributed rating system.

"We learned from Nupedia that excessive a priori formalization is a killer.
Better to start from a very open point of view, and then upon review, if our
end product is starting to be bad in some way, make adjustments based on what
we've learned." [1]
(http://mail.wikipedia.org/pipermail/wikien-l/2003-August/005986.html)

Note that this plan is concerned with the single-volume paper Wikipedia 1.0,
not the possible CD-ROM plan. (The main difference is we don't need to cut
subject areas for the CD-ROM ? we have a lot more space.)

(Feel free to edit this. Discussion to the talk page.)

Table of contents
1 Action plan outline
2 Paper Wikipedia will not be a fork
3 Rating systems
4 Selection is the hard part
4.1 Letting the wiki give us milestone 0.7
5 Stand-alone lead sections
6 Non-free images
7 Publisher
8 A paper Wikipedia in every classroom in Africa
9 Links
9.1 1.0-specific (Jimbo)
9.2 Selection process
9.3 Rating mechanisms
9.4 Bringing areas up to scratch

1. Action plan outline

     * Jimbo has stated that he doesn't want a fork from the current content,
except at the last moment before preparing for print.
     * We have various plans for rating articles or versions of articles,
which we can use to see what's up to scratch.
     * We have various lists of what should be in a single-volume
encyclopedia. Completing these lists would be a fine program for volunteer
recruitment, by the way.
     * In a lot of cases, the [[Wikipedia:lead section]] is going to become
the print article. We need stand-alone leads.
     * We have too many articles with images that are fair-use,
permission-granted, non-profit or of other non-free status.
     * We have an interested publisher, one who actually gets it, waiting in
the wings.
     * We want a paper Wikipedia in every classroom in Africa.

    +------------------------------------------------------------------------+
    |Milestone|           Result           |  Work to get  |  Prerequisites  |
    |         |                            |     there     | before starting |
    |---------+----------------------------+---------------+-----------------|
    |         |                            |Just set a     |                 |
    |         |A book's worth of           |minimum rating |A rating system  |
    |0.7      |sufficiently highly-rated   |and then pull  |running for a    |
    |         |articles.                   |from the       |month or two.    |
    |         |                            |database.      |                 |
    |---------+----------------------------+---------------+-----------------|
    |         |                            |Writing        |                 |
    |         |                            |articles of    |A plan of space  |
    |0.8      |A more balanced selection of|sufficient     |per topic, so we |
    |         |coverage.                   |quality to fill|know where the   |
    |         |                            |gaps - heavy   |gaps are.        |
    |         |                            |lifting.       |                 |
    |---------+----------------------------+---------------+-----------------|
    |         |                            |More heavy     |Enthusiastic     |
    |         |Coverage-complete, with the |lifting. More  |determination.   |
    |0.9      |right selection of          |polishing than |Grim             |
    |         |tolerable-to-good articles. |writing. Fact  |determination.   |
    |         |                            |checking.      |                 |
    |---------+----------------------------+---------------+-----------------|
    |         |                            |Improve        |Good writing.    |
    |1.0      |Polished 0.9.               |tolerable      |Proofreading.    |
    |         |                            |articles to    |Editing. Patching|
    |         |                            |good.          |remaining holes. |
    |---------+----------------------------+---------------+-----------------|
    |Paper    |                            |               |Precise          |
    |Wikipedia|1.0 prepared for print.     |Prepress work. |requirements from|
    |1.0      |                            |               |the publisher.   |
    +------------------------------------------------------------------------+

2. Paper Wikipedia will not be a fork

Jimbo has decreed that we are to fork for print at the last second, rather
than fork now and polish. I suggest we trust his vision.

However, consensus approaches the idea of rating particularly good versions of
specific articles.

3. Rating systems

Various of these are being floated. Current consensus is approaching rating
specific versions on four or five criteria; either yes/no, 0-4 points or 0-10
points.

This is good because it will be easy and people will do it casually.
Harnessing dilettantism, that's the wiki way.

(For edit war hot spots, expect vote spamming.)

4. Selection is the hard part

[[Wikipedia:List of encyclopedia topics]] gives us some idea of what should go
into a single-volume reference. We also need to work out roughly how the
Columbia or Concise Britannica break down into space per topic area. (Do we
have any work in this area already?)

I predict the all-in shitfight will be in turf wars. Selection, as every
partisan editorial group tries to get its articles into the final cut. Not at
the level of editing the articles themselves ? an approval mechanism will
handle that ? I'm talking about telling people that their area won't get all
the articles it might want in. If *any*.

The worst thing is that we'll have to cut back the areas we're actually really
strong in.

4.1. Letting the wiki give us milestone 0.7

The peer-rating system for article versions (as is mooted on the mailing list)
which looks likely to happen anyway, will help 1.0 a lot. Rather than set some
poor bastard to rating thousands of articles, we let the wiki do the work for us.

    1. Wait till a lot of articles (or a fair few) have been rated.
    2. Set a cutoff level that gives you a book's worth of articles.
    3. Examine just how imbalanced we are.

This will give us Wikipedia 0.7, let's say. 0.8 can be better, 0.9 can be
area-selection-complete, 1.0 can be a polished 0.9.

What we need is a way to let the wiki do the work for step 3 above. Is there a
way to harness dilettantism to achieve consensus on what to cut and what to boost?

Bringing areas up to scratch will still be real heavy lifting. How much real
work, we can't know until we get 0.7.

5. Stand-alone lead sections

These are currently optional (according to the MoS), but will become very
important because for long articles, we may just pull the lead section as the
print article. [[News style]] and [[Wikipedia:summary style]] are your friends.

6. Non-free images

These should be cleared and replaced where at all feasible.

Note, by the way, that the publisher would probably have a much easier time
getting copyright clearances for a fixed paper volume than we do for a
changeable open-content encyclopedia (e.g. [[Tube map]], where not having the
map would be ridiculous) ? though I don't expect anyone to agree this is a
good idea.

7. Publisher

We need to know precisely what they require from us, so we know what to aim for.

     * Size in pages, translate to bytes
     * How much space for images
     * Format for publishing

A lot of the prepress gruntwork can likely be done by Wikipedia volunteers for
free. Also, we should be able to test automated systems on 0.7 onwards.

8. A paper Wikipedia in every classroom in Africa

How do we get a list of schools? How many copies is that? How cheaply can we
print a usably good book?

We can almost certainly hitch a ride with other charities for the distribution.

9. Links (external and internal):

9.1. 1.0-specific (Jimbo)

     * [[m:Wikimedia#Wikipedia_1.0]] - Jimbo's dream of a copy in every school
in Africa
     * [[User:Jimbo Wales/Pushing To 1.0]] - Jimbo's official page, lots of
rambling discussion
     * [Wikipedia-l
(http://mail.wikipedia.org/pipermail/wikipedia-l/2003-August/011384.html)
Wikipedia v. Britannica] - ideas about 1.0
     * [WikiEN-l
(http://mail.wikipedia.org/pipermail/wikien-l/2004-February/011045.html) Print
edition] (Jimbo, 26 Feb 2004) - first bite from this publisher

9.2. Selection process

     * [[Wikipedia:List of encyclopedia topics]] ? this list is key to giving
us balance. Need someone to abstract it.
     * [[Wikipedia:Topics where Wikipedia is weak]]
     * [Wikipedia-l
(http://mail.wikipedia.org/pipermail/wikipedia-l/2003-August/011402.html)
Wikipedia v. Britannica] (Tarquin, 18 Aug 2003) - editors as selectors rather
than text editors

9.3. Rating mechanisms

     * [[m:Article validation]] (current discussion)
     * [[Wikipedia:Approval mechanism]] - proposed ideas for a review method
     * [[User:Andrewa/Wikipedia approval mechanism]] - long rambling on
approval mechanisms
     * [[m:Referees]] and [[m:Referees/1]]

9.4. Bringing areas up to scratch

     * [[Wikipedia:WikiProject Aircraft/Strategy]]
     * [[Wikipedia:Math 1.0]]
     * [[Wikipedia:Topics where Wikipedia is weak]]


list: wikipedia-l

subject: [Wikipedia-l] Paper Wikipedia 1.0: a modest rant^W proposal


body:
Solution appears to be simple: Images larger than (say) 640x480 are
displayed in reduced size on the image description page. That image (and
an additional text link maybe) link to the plain full-size image,
without description.

These reduced images should get a special border of some kind to
indicate there's an even larger version.

Magnus

Jens Frank wrote:

>On Sat, Jul 24, 2004 at 01:55:41PM +0100, Timwi wrote:
>
>
>>Robert Graham Merkel wrote:
>>
>>
>>
>>>Seeing we want the ability to make printed material out of Wikipedia
>>>content, uploading full-resolution images is IMO the way to do it.
>>>However, such images currently break the image description page.
>>>
>>>
>>Suggestion: Have a magic word, __SCREENSIZE__ or something like that,
>>which you can put on an image description page, and it will set
>>style="width: 100%" on the image (thus telling the browser to size the
>>image in such a way that its width fits the bounding rectangle). Of
>>course, __SCREENSIZE__ should be omitted when the image is very small,
>>because then "width: 100%" would tell the browser to enlarge it.
>>
>>Of course, this isn't without problems. If someone's bounding rectangle
>>is about 800 pixels wide (it's 826 for me at 1024x768 with Monobook) for
>>someone, but 1000 pixels for someone else (possibly using 1280x1024),
>>then one of them will want __SCREENSIZE__ to be inserted, while the
>>other will complain that it enlarges the image unnecessarily. :/
>>
>>
>
>Client-side scaling has the additional downside that the entire high-res
>image has to be downloaded.
>
>JeLuF
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>


subject: [Wikitech-l] Rewards for developers

body:
On 26 Jul 2004 02:47:00 +0200, Erik Moeller <erik_moeller at gmx.de> wrote:
> Yes, we should just all keep doing whatever we have been doing for 20
> years and be happy, and never try anything new. By the way, this whole
> Wikipedia idea is kind of crazy. People should just use CVS to edit the
> encyclopedia, why come up with something new when there is a perfectly
> good process in place already? Jesus Fucking Christ, what kind of crap
> attitude is this? "We don't have to guess or invent new ways"? No, we
> don't, but guessing and experimenting is the source of all innovation.

As someone who insists on using basing logic in discussion, you set up
a nice strawman yourself.

You're right that the fact, that something hasn't been tried before
doesn't mean that it shouldn't be tried. If that was my only argument,
it would have been bogus.

I believe my arguments are a bit stronger than that. I claim that:
* there are better ways to improve mediawiki project
* we can find those ways by analysing what worked well for other
projects in the past
* bounty systems have been tried and failed, either miserably
(producing nothing) or just plain failed (dind't produce expected or
eve significant improvements, the word "significant" being the key)

> Which you aren't even familiar with to the extent that you could name
> them. I can: CoSource, SourceExchange, the Free Software Bazaar. All these
> models have been examined and have failed for different reasons. CoSource
> failed for lack of VC, but had quite a lot of successful bounties
> completed at the time it closed down (check archive.org). SourceExchange
> was targeted at corporations, not individuals. The Free Software Bazaar
> was a static HTML website maintained by Axel Boldt, who lost interest at
> some point, but it was reasonably active and led to some completed
> projects.

I don't see how showing examples of failed projects that tried to use
bounty system supports your argument that bounty systems are a good
idea.

Whatever your opinion is on why they failed, the only objective
evidence we have is that they failed.

> The open code market idea is certainly not new

I agree. I further claim that it has been tried and failed.

> and it is one which is
> increasingly being explored, refined and adopted, and which will
> eventually inject the one thing into the open source process which is
> currently missing from it: money. I advise you to at least do some basic
> research and read, for example, Jordi Carrasco-Mu?oz' paper "The Open-Code
> Market":
> http://firstmonday.org/issues/issue8_11/munoz/index.html

Thanks for the pointer. I've read the paper. It basically says:
"here's an idea and why I think it should work". Then I went to the
website (http://www.opencodemarket.org/ which really is
http://jordiweb.net). As you can see by reading
http://jordiweb.net/docs/IT/The_Open_Code_Market.html (essentially the
same thing that was submitted to firstmonday) he published his idea on
May 2003. Over a year passed and nothing else has happened.

While I won't claim that his idea is worthless because he failed to
implement it in practice, I certainly don't see how you can present it
as a pro-bounty argument.

> As well as "A history of markets for open source software":
> http://www.ms.lt/en/workingopenly/markets.html

Thanks, this is interesting information.

I knew about CoSource and SourceXchange - and they seem to me just
another failed dotCom business plans, a lot of hype, high-profile
launch and high-profile bust. Hardly an example of success.

Free Software Bazaar: "few dozen projects were completed, mostly for
about $50, one for $1,000". And they're gone. Again, hardly an example
of success.

Open Avenue - as far as I can tell total failure. No sign of even
modest accomplishments (not even completing a few dozen projects) and
the website redirects to an interesting (not work safe) place.

Asynchrony - the only thing that is alive today. But they weren't
really about bounty system, more like matching people with ideas but
unable to program with programmers, and taking a cut if they deliver
anything. Very safe business for Asynchrony but probably much less
successful for those who worked on projects. Regardless, today they
are just a IT service/consulting company. They changed the business
model.

Software Carpentry bounty to develop SC Config/Build/Test/Track. I
wouldn't call that a sucess either. Despite offering $200 k, the
system, to the best of my knowledge, has not been delivered.

They did pay some bounties for completed designs and
http://roundup.sourceforge.net is an implementation of SC Track
(although it's not founded by the bounty - it's an independent, unpaid
effort). So you might call it a partial success but as far as reaching
the initial objectives, it's just a failure. Additionally it (roundup)
shows that more was achieved by unpaid, motivated individual than by
the bounty system.

> > I don't know a single succesful open-source project that implements
> > bounty system.
>
> Your ignorance is unfortunate.

I agree and I thank you for providing links so that I could educate myself.

Now I can say that I'm familiar with several cases where bounty
systems were applied. And they all failed.

I'm still looking for an example of an open-source project that
successfuly implemented bounty scheme. By "success" I mean that a
significant portion of the code/functionality can be directly linked
to bounties offered. In particular, the GNOME and Mozilla bounties you
mentioned are, at best, failed experiments.

> GNOME has a bounty system, and it works:
> http://www.gnome.org/bounties/
> http://www.gnome.org/bounties/Winners.html
>
> Mozilla has recently started bounties as well:
> http://www.markshuttleworth.com/bounty.html

Both those projects failed.

GNOME bounty resulted in fixing 11 bugs
(http://www.gnome.org/bounties/Winners.html). 32 bugs for which a
bounty was offered were *not* fixed
(http://bugzilla.gnome.org/buglist.cgi?product=bounties&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED)
despite the fact that there were 5 months to do the work.

That's for a system that has around 700 new bugs opened weekly and as
much bugs fixed
(http://bugzilla.gnome.org/reports/weekly-bug-summary.html) and is
approaching 150.000 bugs in total. Do you consider that a sucess?
Especially if you factor in all the work that went into nominating
bugs for bounties, creating web pages, evaluating the patches.

It also seems that it has been dropped by GNOME team - it was last
done in november 2003 and there's no activity aftter that. It's just
another failed experiment.

Mark has funded one project  (http://www.schooltool.org/) in
septemeber 2003. Calling it a bounty stretches a definition. If you
read the announcement
(http://www.markshuttleworth.com/schooltoolbounty.txt) he's just
funding (almost) full-time programmers to work for him and develop a
software that is available as GPL.

The "real" bounties that are offered since at least december 2003 (see
e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=181866) for smaller
projects are still unclaimed.

Complete failure.

0 out of 5 Mozilla bounties were claimed. And Mozilla is progressing
just fine. Even if those 5 bounties were completed, the impact on
Mozilla would be insignificant.

> Well, you can set up whatever straw man you want and shoot it down, but
> that has never been the point of the proposal. Read it.

The proposal is about offering bounties (or other rewards) for
completing developement tasks. As far as I know, this has not been
implemented *succesfully* in the past although many tried.

None of the examples you've presented can be called a success for any
reasonable definition of success.

What evidence there is that bounty system work *well* ?

Krzysztof Kowalczyk | http://blog.kowalczyk.info


body:
Karl Eichwalder wrote:

> Exactly.  But there should be more than one link; also offer other
> sizes (resolutions):
>
>     800x600
>    1024x768
> and an entry box where the user can enter the size he is interested
> in.

Heck, no. That's redundant. People can resize images on their own
computer. They shouldn't need to use the Wikimedia servers for that.

Timwi


subject: [WikiEN-l] I blocked User:JBOC

body:
On 07/25/04 15:47, Jimmy (Jimbo) Wales wrote:
> daniwo59 at aol.com wrote:

>>I have blocked User:JBOC for one year. His harrassment of User:Roozbeh is
>>utterly unwarranted, and should be a warning sign for us. I do not want to
>>discuss this on the mailing list any further. If anyone has a problem with it, i
>>invite you to take it up with me in a personal email.

 > I fully support this and if anyone has a problem about Danny
 > doing this, please consider it to be an action fully endorsed by
 > me and coming as it if came from me directly.
 > I'm on vacation more or less right now, so please email Danny for more
 > details if you have a problem with it.  Next week when I get back, we
 > can have a public -- but abstract -- discussion of cases of this type.

Of late, admins have been happier to put 24 hour blocks (after a warning!) on
purveyors of egregious personal abuse - particularly in edit summaries.
Second offense, triple the block.

Continued this way, JBOC would, after his seventh bout of egregious personal
attacks, be blocked for *two* years ;-)

- d.


from_name: Karl Eichwalder

body:
Magnus Manske <magnus.manske at web.de> writes:

> Solution appears to be simple: Images larger than (say) 640x480 are
> displayed in reduced size on the image description page. That image (and
> an additional text link maybe) link to the plain full-size image,
> without description.

Exactly.  But there should be more than one link; also offer other
sizes (resolutions):

    800x600
   1024x768

and an entry box where the user can enter the size he is interested
in.  If possible display the pixel size of the original image.

> These reduced images should get a special border of some kind to
> indicate there's an even larger version.

A special border isn't reqired; just make the original size a hyperlink.

--
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)


in_reply_to:
<ce1114$6lv$1@sea.gmane.org> (timwi@gmx.net's message of "Sun, 25
	Jul 2004 20:17:26 +0100")

body:
Timwi <timwi at gmx.net> writes:

> Heck, no. That's redundant. People can resize images on their own
> computer. They shouldn't need to use the Wikimedia servers for that.

I guess it will not happen that often.  And if it happens often, it is
no problem neither since the images are cached.

Remember the user who read the description page wants to see a
suitable picture, but he does not want to download more than 100KB if
this isn't necessary.

--
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)


subject:
[WikiEN-l] Re: Somebody with a good reputation will write a
 critical article
 about Wikipedia and esp. the article [[Prem Rawat]]   that is locked now

body:
Andries Krugers Dagneaux wrote:

> I receive an email from somebody who expressed his disappointment with
> Wikipedia, especially with regards to the article on the controversial
> inspirational speaker and former guru Prem Rawat
> http://en.wikipedia.org/wiki/Prem_rawat. The person who intends to write
> a critical article about Wikipedia is  an ex-follower and has a good
> reputation. I do not like Wikipedia's reputation to get hurt because of
> his article on his website but I cannot do anything for three reasons.
> First, the article is locked. Secondly, I will be away from the internet
> for some time. Thirdly, the situation is still highly polarized as can
> be read on the talk page.

I don't see the problem. Why doesn't he just write a new article at
[[Prem Rawat/Temp]]? Isn't that the correct way of doing this? Let him
know that he's perfectly entitled to use parts of the existing article
(the source code of which he can easily access), but should be aware
that it's not wise to use the parts that are unter controversy. :)

Timwi


from_name: Mark Ryan

subject: [WikiEN-l] Re: issues

body:
What troubles me most is that people are fighting over trivial things.
If they are going to edit war, it should at least be a topic worth
arguing over.

~Mark

On Wed, 21 Jul 2004 11:09:07 -0700, Jimmy (Jimbo) Wales
<jwales at wikia.com> wrote:
> Michael Snow wrote:
> > What's really appalling is that in many instances, not even the talk
> > page of the disputed article is being used. The only communication going
> > on is through edit summaries, and since those typically consist of "rv",
> > accusations of vandalism, snide remarks, or the pre-filled edit summary
> > from an admin using the rollback button, it's worse than useless.
>
> I fully endorse this paragraph.
>
> I'd rather see people fighting dirty on the talk pages than a revert
> war.  At least in a case like that, there is a glimmer of hope for
> communication.
>
> But of course, I would rather see people not fighting dirty at all,
> but rather seeking to influence others through kindness, reason, and
> patience.
>
> --Jimbo
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Andries Krugers Dagneaux

body:
I receive an email from somebody who expressed his disappointment with
Wikipedia, especially with regards to the article on the controversial
inspirational speaker and former guru Prem Rawat
http://en.wikipedia.org/wiki/Prem_rawat. The person who intends to write
a critical article about Wikipedia is  an ex-follower and has a good
reputation. I do not like Wikipedia's reputation to get hurt because of
his article on his website but I cannot do anything for three reasons.
First, the article is locked. Secondly, I will be away from the internet
for some time. Thirdly, the situation is still highly polarized as can
be read on the talk page.

I have to admit that some ex-followers of Prem Rawat will only be
satisfied if you start the article with something like "Prem Rawat is a
charlatan cult leader who has misled thousands of people with his
propaganda and who claimed to God almighty to save mankind. Due to this
many people wasted many years of their lives." Though I feel strongly
that the ex-followers are partially right due to my own experience with
a charlatan guru aka cult leader, I understand that this can never be
written down following NPOV guidelines.

There is also a recurring, general problem with writing about new
religious movements (NRMs) and that is to what extent criticism of the
critics of NRMs should be allowed in the articles. I am hoping for
general guidelines. Here is what I wrote on the talk page, "I only said
that a person who chooses to pose as a guru and teach meditation
techniques is open and should be open for public scrutiny. The people
who believe and have followed this person and found him wanting and then
openly criticize him are open to scrutiny, in so far, their involvement
with this guru was serious, genuine and sincere. Their criticism of the
guru is, of course, open to scrutiny too. Apart from the authenticity of
their involvement with the guru, one could ask whether some of them have
an ax to grind but this should not be based on mere speculation or
conspiracy theories. There should be some strong documented indication
that they had an ax to grind otherwise no suspicions should be
mentioned. With regards to the same thing with my former guru, this was
a comparison that may give others more insight into my point of view and
into the fact that this unfair, insulting character assassination of
critics is very common by supporters of controversial new religious
movements. The defenders have to resort to ad hominem attacks on the
critics because they ran out of reasonable or logical ways to defend
their guru. Andries 07:44, 24 Jul 2004 (UTC)"

I also wrote a satirical article about Wikipedia being a cult
http://en.wikipedia.org/wiki/User:Andries/Wikipedia%3Acontroversy

See you later. Bye. Andries K.D


from_name: Ray Saintonge

body:
Fennec Foxen wrote:

>On Sun, 25 Jul 2004 11:16:16 -0400, Frank Pinter
><francis.pinter at gmail.com> wrote:
>
>
>>>I've long wished there were a genealogical database of European monarchs
>>>etc,
>>>
>>>
>>Yes, that is a good idea. However, it should not be on Wikipedia,
>>according to [[Wikipedia:What_Wikipedia_is_not]]. Maybe if some big
>>Wikimedia person (like Jimbo, maybe) sees this a consideration for a
>>project may be started.
>>
>>
>
>The problem with this is that, while the monarchy/etc information may
>be available, the project would be prone to insertion of nonfamous,
>nonnotable peoples' geneologies. These are liable to be extremely
>unverifiable. Also, there is a fair population of people who think
>they are royalty but are not:  c.f.
>http://en.wikipedia.org/wiki/User:Vernon_John_De_Duckmanton (and the
>associated talk page).
>
>How would you overcome this sort of problem?
>
Including some genealogical data on royalty pages should be no big
deal.  Extrapolating that to the genealogies of non-famous people
requires a great leap of credibility.  That there would be people who
would mistakenly believe that they were royalty comes as no surprises.
Royal fertilization techniques were bound to grow a few bananas on the
apple tree.

It does appear that John the Duck is straight out of Monty Python; and
with his adversary confessing that his family has taken itself seriously
since the time of King John, the result is bound to be hilarious.

Ec


from_name: Fennec Foxen

subject: [WikiEN-l] Researching a new Wikien-l mailing list admin.

body:
On Fri, 23 Jul 2004 18:53:20 +0200, Ronny Raschkowan
<ronny at kopfrechnung.de> wrote:
> Volunteers? :)
I'll volunteer. I've administered Mailman lists in the past (converted
this site over from Listproc: http://eh.net/mailman/listinfo.cgi).

You want a list administrator, or just a list moderator, btw? (I'll
volunteer for either. :)


subject: [WikiEN-l] Re: WikiEN-l Digest, Vol 12, Issue 47

body:
On Sun, 25 Jul 2004 11:16:16 -0400, Frank Pinter
<francis.pinter at gmail.com> wrote:
> > I've long wished there were a genealogical database of European monarchs
> > etc,
> Yes, that is a good idea. However, it should not be on Wikipedia,
> according to [[Wikipedia:What_Wikipedia_is_not]]. Maybe if some big
> Wikimedia person (like Jimbo, maybe) sees this a consideration for a
> project may be started.

The problem with this is that, while the monarchy/etc information may
be available, the project would be prone to insertion of nonfamous,
nonnotable peoples' geneologies. These are liable to be extremely
unverifiable. Also, there is a fair population of people who think
they are royalty but are not:  c.f.
http://en.wikipedia.org/wiki/User:Vernon John De Duckmanton (and the
associated talk page).

How would you overcome this sort of problem?


from_name: Evan Prodromou

subject: [Wikitech-l] Re: Rewards for developers

body:
> I would like that all developers (others may
> participate as well of course) help setting up a list
> to define how development tasks completed could be
> rewarded.
>
> This will be followed by a public poll to define how
> the rewards would be perceived...
>
> and a private poll for developers to know what their
> opinion on the matter is
>
> Please, contribute to
> http://meta.wikimedia.org/wiki/Bounty
>
> thanks :-)

I don't know about the other MediaWiki developers, but the only reward I'd ask
for for working on MediaWiki is that people work hard to make great articles and
a strong, friendly communities with this software.

If I could ask for anything else, I'd ask that people treat each other with the
gratitude and respect they deserve. Everyone who puts work into these projects
-- editorial, technical, community-building -- deserves our appreciation and kudos.

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


subject: [Wikitech-l] Re: Rewards for developers

body:
Evan Prodromou wrote:

> I don't know about the other MediaWiki developers, but the only reward
> I'd ask for for working on MediaWiki is that people work hard to make
> great articles and a strong, friendly communities with this software.
>
> If I could ask for anything else, I'd ask that people treat each other
> with the gratitude and respect they deserve. Everyone who puts work
> into these projects -- editorial, technical, community-building --
> deserves our appreciation and kudos.

The smell of money always changes the parameters of the game.  When you
hire someone to do a job that was previously shared by members of the
volunteer community: That when perceptions of inequality begin to creep
in.  People start to expect things from the hired hand, and stop doing
it themselves.  Appreciating key volunteers can be tricky.  Sometimes a
more valuable reward is the right way to go; other times a mere "Thank
you" is all that it takes. Token gifts can also work.  These do not have
great monetary value (if any).  Perhaps Jimbo could send them each a
six-place setting of genuine collectors' item Nupedia mugs.  At least it
would help to clear them out of his cellar. :-)

Ec


from_name: Andrew Lih

subject: [Wikipedia-l] Chinese Wikipedia get together in Beijing

body:
On Sat, 24 Jul 2004 06:50:17 +0800, Andrew Lih <andrew.lih at gmail.com> wrote:
> Unlikely. It is an meeting of folks who met on the Internet, so as
> long as it is nothing politically motivated, it's fine. OTOH, if you
> don't hear from me by Wednesday, call my lawyer. :)

Lawyer was not needed.  The first ever China meetup went well - folks
talked about the June Internet block, effects on users/readers and
living with traditional/simplified Chinese. We even had
non-Wikipedians come by who were interested in library science and IT
side of the project.

For a picture of the attendees:
http://zh.wikipedia.org/wiki/Wikipedia:%E8%81%9A%E4%BC%9A#.E7.85.A7.E7.89.87.2C_Photos

Thanks go out to User:Mountain for the location at Peking University,
and the food and drink.

-Andrew (User:Fuzheado)


from_name: Ævar Arnfjörð Bjarmason

subject: [Wikitech-l] Rewards for developers

body: Calm down erik, no need to go all postal over the man;) hehe


from_name: Anthere

subject: [Wikitech-l] Re: Rewards for developers

body:
Bill Clark wrote:
> On Sat, 24 Jul 2004 18:09:54 -0700 (PDT), Anthere <anthere9 at yahoo.com> wrote:
>
>>I would like that all developers (others may
>>participate as well of course) help setting up a list
>>to define how development tasks completed could be
>>rewarded.
>
>
> People tend to be competitive.  Turn it into a game.
>
> Those making requests should be given a certain number of "points" per
> day that they're allowed to assign to their requests (or to already
> existing requests).  When a developer completes a task, they're
> awarded all the points for that task.
>
> Then you need a scoreboard that shows which developers are "winning".
>
> This is basically the same thing Ashar was talking about (making users
> happy) except that it's easier to quantify.
>
> -Bill Clark

Thanks for the feedback Bill

I added your comment here http://meta.wikimedia.org/wiki/Developer_payment

It is much easier for follow up

ant


from_name: Erik Moeller

subject: [Wikitech-l] Rewards for developers

body:
Krzysztof-
> Open-source is 20 years old. There are thousands of open-source
> projects. Some are successful, most are not. The development of
> open-source projects is on public record. There are mailing list
> archives, project web sites, history of CVS commits.

> We don't have to guess or invent new ways of making open-source
> projects succesful.

Yes, we should just all keep doing whatever we have been doing for 20
years and be happy, and never try anything new. By the way, this whole
Wikipedia idea is kind of crazy. People should just use CVS to edit the
encyclopedia, why come up with something new when there is a perfectly
good process in place already? Jesus Fucking Christ, what kind of crap
attitude is this? "We don't have to guess or invent new ways"? No, we
don't, but guessing and experimenting is the source of all innovation.

> Much safer strategy is to analyze past, which is
> rich with examples,

Which you aren't even familiar with to the extent that you could name
them. I can: CoSource, SourceExchange, the Free Software Bazaar. All these
models have been examined and have failed for different reasons. CoSource
failed for lack of VC, but had quite a lot of successful bounties
completed at the time it closed down (check archive.org). SourceExchange
was targeted at corporations, not individuals. The Free Software Bazaar
was a static HTML website maintained by Axel Boldt, who lost interest at
some point, but it was reasonably active and led to some completed
projects.

The open code market idea is certainly not new, and it is one which is
increasingly being explored, refined and adopted, and which will
eventually inject the one thing into the open source process which is
currently missing from it: money. I advise you to at least do some basic
research and read, for example, Jordi Carrasco-Mu?oz' paper "The Open-Code
Market":
http://firstmonday.org/issues/issue8_11/munoz/index.html

As well as "A history of markets for open source software":
http://www.ms.lt/en/workingopenly/markets.html

> I've never seen "rewarding with points" system applied in practice.
> Therefore it's unlikely that it's a good idea

"I've never seen a wiki applied in practice for building an encyclopedia.
Therefore it's unlikely that it's a good idea." Look, please familiarize
yourself with basic logic before you make bullshit arguments like that.

> and it's certainly very
> risky to try things no-one has tried before.

The risk in minimal. If it alienates people, we scrap the system and don't
do it again.

> I don't know a single succesful open-source project that implements
> bounty system.

Your ignorance is unfortunate.

> I've seen projects that flourish despite not having any external
> rewards systems in place (mono is a recent example, but there are of
> course plenty of them: GNOME and KDE projects, subversion, eclipse,
> gcc and I would consider wikimedia to be quite successful so far as it
> works well enough to support a massive undertaking as WikiPedia).

GNOME has a bounty system, and it works:
http://www.gnome.org/bounties/
http://www.gnome.org/bounties/Winners.html

Mozilla has recently started bounties as well:
http://www.markshuttleworth.com/bounty.html

> It's safe to conclude that you don't need bounty system to have
> succesful project.

Well, you can set up whatever straw man you want and shoot it down, but
that has never been the point of the proposal. Read it.

Erik


from_name: Timwi

subject: [Wikitech-l] Re: Rewards for developers

body:
Anthere wrote:

> Thanks for the feedback Bill
> I added your comment here http://meta.wikimedia.org/wiki/Developer_payment
> It is much easier for follow up

Hm, I would be vastly grateful to anyone who could summarise the system
I proposed on the other mailing list (foundation-l) on a meta page where
it will be discussed. :-) (I would do it myself, but I have this project
deadline next week :/)

Timwi


subject: [Wikitech-l] Re: Rewards for developers

body:
Krzysztof Kowalczyk wrote:
>
> It's safe to conclude that you don't need bounty system to have
> succesful project.
>
> The real question is: what is?
>
> I think the discussion "is bounty system good or bad" is premature,
> stems from a haphzard idea of an individual (as opposed to systematic
> exploration of possible options to improve mediawiki project).
>
> It diverts attention from much more important question: "what are the
> ways to improve mediawiki".
>
> Krzysztof Kowalczyk | http://blog.kowalczyk.info

I would like to insist on a couple of things

First, I have no clearly set opinion myself on the topic, which is why I
feel fairly confident to ask you what you think and not to deform it :-)

Second, we can not really say that this discussion on bounty is
premature. No discussion ever is, as long as it is discussion :-) And
since a couple of people are interested, and Erik in particular supports
it very much, then it is best to discuss it openly.

Third, this discussion is in particular triggered by the irc discussion
we had yesterday (see
http://meta.wikimedia.org/wiki/Foundation_website_meeting%2C_July_2004)
during which 2 features development were suggested on that bounty system.

Fourth, as far as I know, though a developer seem to think otherwise,
the money which will be used for bounty system (IF we decide to try that
option) will likely to be WMF one, and in this case, it will be the
board to vote whether to spend or not to spend, and how much to spend.
Now, we are aware it is a controversial matter, so what we will do will
depend essentially of how the developers feel like it, and how all
editors feel like it. Hence, the current discussion.

1) As mentionned by Elian and others, it would be nice that we identify
better which features are currently requested, and which requests are
really supported

2) Then to see which ones are more urgent

3) Then to have this clear to newcomers, so that there is not a barrier
to entry for new developers

4) And suggest ways to reward those taking on tasks.


subject: [Wikitech-l] Special:AskSQL

body:
Even if you dont enable that for en. due to load problems, could you
at least enable it for smaller wikipedias like is. pretty hard to bog
down the DB on a 4MB database, even with the most intensive queries,
would be a great maintenence tool.

On Wed, 21 Jul 2004 21:25:40 +0200, Michael Diederich <dev-null at md-d.org> wrote:
> Hi all,
>
> today i was asking in #wikipedia to reopen the SQL-queries again for admins.
> The new hardware and the low server load of SQL-queries should be a reason
> to reable the most important tool of an admin.
>
> It don't need to be on the main db-server - i could be on a slave or just
> availble on low load times (1-3UTC?)..
>
> In #wikipedia someone suggested, the option should only be granted to some
> users - i also would accept that solution.
>
> I have spoken to some de.wikipedia admins, and all of them support my
> enquery.
>
> Best regards,
>
> da didi
> --
> ===========================================================================
> Gentoo Linux:                   Gentoo Base System version 1.5.1
> kernel-2.6.7                    Pentium III (Coppermine)
> ===========================================================================
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Poor, Edmund W

body:
"Don't bite the hand that feeds you."

It would have been better to reply with mild explanations of how our
Buckminster Fuller article wasn't really a "plug" for Drexler than to
issue a shrill denunciation or (shudder) to loft an f-word at them. If
those were the only two who wrote, than I suggest in the future we get
together and coordinate our strategy for responding.

Anyone care to form or join a Public Relations committee? First order of
business would be to send an apology to The Register and assure them
that the "wankers" who flamed them were not speaking officially for our
project. We might also ask for suggestions on improving our article
about their newspaper...

Ed Poor
Fiddler and Bureaucrat

	-----Original Message-----
	From: Rick [mailto:giantsrick13 at yahoo.com]
	Sent: Friday, July 23, 2004 3:12 PM
	To: Wikipedia English
	Subject: [WikiEN-l] "The Register" is making fun of us

	http://www.theregister.co.uk/2004/07/23/wiki_fiddlers_big_book/

		RickK

  _____

	Do you Yahoo!?
	Vote for the stars of Yahoo!'s next ad campaign!
<http://advision.webevents.yahoo.com/yahoo/votelifeengine/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040726/c172d464/attachment.htm


subject:
[WikiEN-l] Peaceful resolution of religious edit wars (was:
	Somebody will write a critical article about Wikipedia)

body:
Andries wrote passionately and eloquently about the difficulties of
writing a Wikipedia article about a controversial New Religious Movement
(or "NRM", as sociologists like to say).

The chief problem he mentions is "satisfying the ex-followers" who
regard the group founder as a charlatan.

I have also tried several times to intervene or mediate between
pro-Rawat and anti-Rawat contributors, but I guess the article keeps
getting locked due to edit wars.

I can only suggest that we continue to try coaching the contributors in
the skill of "writing for the enemy". That is, ensuring that the article
as a whole, as well as each paragraph and sentence, is organized and
worded so that ANYONE, no matter how sharply polarized their opinion,
will agree that the article is accurate.

I wish the [[Sun Myung Moon]] and [[Unification Church]] articles could
be models for this. I have worked hard over the past 2 or 3 years to
ensure that they always kept a balance between "raving loony support"
and "rabidly adamant denunciation". The mainstay of my strategy has been
to EDIT SLOWLY.

When someone trashes the article (as I conceive it), I avoid wholesale
reversion -- because I am an interested party. Instead, I discuss (most)
changes on the talk page and (usually) make one small change at a time.
I avoid buzz-words in edit summaries like 'NPOVing the text' in favor of
specifics, like "attributing claim of divinity to his right-hand man Bo
Hi Pak" or "attributing claim of corruption to Congressman Donald
Fraser".

Sometimes it can help to mention the controversy in the introduction to
the article. Like:

* Prem Rawat was called "the perfect spiritual master" by his followers
in the 1970s, who gave him the title Guru Maharaj Ji (or Maharaji).
Ex-followers criticize him vehemently as a charlatan who has misled
thousands of people with [[cult]] propaganda and complain bitterly that
many people, deluded by his claims about saving mankind, wasted many
years of their lives."

Please don't give up! I know it's hard and frustrating, but it really is
possible to bring peace to a war-torn article. A prime example is the
[[Chilean coup of 1970]]. No action by the  Arbitration Committee was
needed to settle that, and it's been stable for the last 2 months!

Let's keep at it, buddy!!

Ed Poor


subject: [WikiEN-l] IP blocks

body:
> I have an IP address 203.166.96.239 with an IP address that has been recently and
> consistently used for vandalism and has been banned for successive 24 hours by first
> Dysprosia and then Davidcannon. I am sure that these decisions were fair and
> reasonable: however I would like some information on the track record of the vandalism
> and the addresses so I can take it up with my ISP.
http://en.wikipedia.org/wiki/User_talk:203.166.96.239
http://en.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=203.166.96.239

I also checked http://en.wikipedia.org/wiki/Wikipedia:Vandalism_in_progress
but it appears that there is nothing there.

> Alternatively, would the problem end if I changed my ISP.
Well, the new ISP wouldn't own the same IP address range. :)


subject: [Wikitech-l] Re: Rewards for developers

body:
side note for Erik

------

Erik, I tried the little attribution thingy for when we do not write
from cpov.
Look what happened :-)
http://meta.wikimedia.org/w/wiki.phtml?title=Developer_payment&curid=9457&diff=50349&oldid=50347


subject: [Wikitech-l] Re: Rewards for developers

body:
Timwi wrote:
> Anthere wrote:
>
>> Thanks for the feedback Bill
>> I added your comment here http://meta.wikimedia.org/wiki/Developer_payment
>> It is much easier for follow up
>
>
> Hm, I would be vastly grateful to anyone who could summarise the system
> I proposed on the other mailing list (foundation-l) on a meta page where
> it will be discussed. :-) (I would do it myself, but I have this project
> deadline next week :/)
>
> Timwi

Could you do the summarizing please ?


from_name: Dan Miller

subject: [WikiEN-l] Re: WikiEN-l Digest, Vol 12, Issue 54

body:
I'll join. As WP grows, we need to get on this type of
thing--almost all large organizations do it, and it's
important to manage perceptions. I'll start setting up
a draft page in my userspace, and get up a letter to
the Register as well.

Meelar

> Message: 10
> Date: Mon, 26 Jul 2004 06:28:48 -0700
> From: "Poor, Edmund W" <Edmund.W.Poor at abc.com>
> Subject: RE: [WikiEN-l] "The Register" is making fun
> of us
> To: "English Wikipedia" <wikien-l at Wikipedia.org>
> Message-ID:
>
>
<E506B3FF6BC1254C9AC1B948C380BC2801FBB6E4 at sm-nyny-xm05.nena.wdpr.disney.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> "Don't bite the hand that feeds you."
>
> It would have been better to reply with mild
> explanations of how our
> Buckminster Fuller article wasn't really a "plug"
> for Drexler than to
> issue a shrill denunciation or (shudder) to loft an
> f-word at them. If
> those were the only two who wrote, than I suggest in
> the future we get
> together and coordinate our strategy for responding.
>
> Anyone care to form or join a Public Relations
> committee? First order of
> business would be to send an apology to The Register
> and assure them
> that the "wankers" who flamed them were not speaking
> officially for our
> project. We might also ask for suggestions on
> improving our article
> about their newspaper...
>
> Ed Poor
> Fiddler and Bureaucrat
>\

=====
In one of a series of interviews since teaming up on Tuesday, Kerry and Edwards predicted they would win the political fight over which party best exemplifies the values and ethics of most Americans, but Kerry said they would wage that battle on their terms and not what he called the Republican Party's "little political, hot-button, cultural, wedge-driven, poll-driven values."

--Washington Post, July 11, 2004

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail


subject: [Wikitech-l] Article validation

body:
Dori wrote:

>Well, I haven't seen how this feature works. Any chance it will be put
>on test some time soon? Of course I also hope that there are no
>problems with it. It's something that could really help us if it works
>out well.
>
>
>
It is already on test, but someone needs to run patch-validate.sql or
this query:

CREATE TABLE validate (
  val_user int(11) NOT NULL default '0',
  val_title varchar(255) binary NOT NULL default '',
  val_timestamp varchar(14) binary NOT NULL default '',
  val_type int(10) unsigned NOT NULL default '0',
  val_value int(11) default '0',
  val_comment varchar(255) NOT NULL default '',
  KEY val_user (val_user,val_title,val_timestamp)
) TYPE=MyISAM;

I forgot to include it in the update script. Sorry.

Magnus


subject: [Wikipedia-l] re monobook.css copyright

body:
I was cleaning up various things in Wiktionary when I ran into the link
to http://en.wiktionary.org/style-new/monobook/main.css . Admittedly I
know nothing about css files but the line near the top "Copyright
Gabriel Wicke" grabbed my attention.  There is no mention that it is
being released under any free software licence.  It seems to me that
this is something that should be corrected.

Ec


from_name: Karlheinz Toni

subject: AW: [Wikitech-l] Re: Plain text of page?

body:
Hi there,

> -----Urspr?ngliche Nachricht-----
> Von: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-
> bounces at wikimedia.org] Im Auftrag von Timwi
> Gesendet: Freitag, 23. Juli 2004 15:25
> An: wikitech-l at wikimedia.org
> Betreff: [Wikitech-l] Re: Plain text of page?
>
> Karlheinz Toni wrote:
>
> > what possibilities do I have to get the plain text of a page?
>
> http://en.wikipedia.org/w/wiki.phtml?title=Main_Page&action=raw
> if you want the "correct" but uncommon and usually unsupported
> content-type of text/x-wiki; or
>
> http://en.wikipedia.org/w/wiki.phtml?title=Main_Page&action=raw&ctype=text
> /css
> if you want the "hacky" but more useful text/css which makes it display
> as plain text in browsers.

Thank you for your answer. Is there any possibility of getting the formatted
text of the pages (without navigation,... just the information on the
page)...

Sincerely
Charly


from_name: Pierre Abbat

subject: [Wikipedia-l] template for translating interface?

body:
Some time ago I grabbed LanguagePt.php and translated part of it into Lojban.
This was before templates and categories, so I need to update it. I'd like to
start over with an English template, but LanguageEn.php just has an include
statement, and Language.php says not to use it as a template. What should I
use?

phma
--
li fi'u vu'u fi'u fi'u du li pa


from_name: Yann Forget

body:
Le Sunday 25 July 2004 23:52, Bill Clark a ?crit :
> On Sat, 24 Jul 2004 18:47:15 +0200, M?d?ric BOQUIEN
>
> <mederic.boquien at laposte.net> wrote:
> > For the people with root access, i'll send the password of each server
>
> Not trying to start a flame-war or anything.. but I really suggest
> just using RSA/DSA keys for root access as well.

And just to add my 2 bits, you want to use sudo whenever possible.

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: Frithjof Engel

subject: [Wikitech-l] Rewards for developers

body:
On 25.07.2004 17:58:38 -0400, Bill Clark wrote:
> On Sat, 24 Jul 2004 18:09:54 -0700 (PDT), Anthere <anthere9 at yahoo.com> wrote:
> > I would like that all developers (others may
> > participate as well of course) help setting up a list
> > to define how development tasks completed could be
> > rewarded.
>
> People tend to be competitive.  Turn it into a game.
>
> Those making requests should be given a certain number of "points" per
> day that they're allowed to assign to their requests (or to already
> existing requests).  When a developer completes a task, they're
> awarded all the points for that task.
>
> Then you need a scoreboard that shows which developers are "winning".

I think this will lead to worse software, because it shifts the focus from
"writing good software" to "making money/win the game". There have been
several studies in the past on this topic:

http://www.gnu.org/philosophy/motivation.html

Frithjof


subject: [Wikitech-l] Re: Rewards for developers

body:
Krzysztof Kowalczyk wrote:

> Whatever your opinion is on why they failed, the only objective
> evidence we have is that they failed.

I think it makes a lot of sense to examine why other projects failed.

Take LiveJournal, for example -- the Bazaar system that I based my idea
upon. Under your definition you're going to tell me that it "failed"
simply because the Bazaar is no longer used. However, I was there when
it happened, and I participated in it. I can tell you from first-hand
experience that it was an incredible success. Developer motivation
increased significantly, and the bounties that were paid out were for
much-needed work on the software.

The real reason why it was shut down (heck, it wasn't even explicitly
shut down, it was just neglected) was not that it was unsuccessful, but
just that the alternative they went for in parallel -- namely, hiring
employees for software development -- was just as successful, but much
less of a hassle.

I don't know much about finance, so I can't say how feasible it is for
the Wikimedia Foundation to hire software engineers, but intuitively one
would think that Wikimedia would benefit from such a Bazaar-like system
for as long as there is a significant risk that donations suddenly drop
and would no longer suffice to pay an employee. In my mind, the Bazaar
system has an advantage for both sides: Developers can still be
volunteers (i.e. opt out of any commitment any time they want), and
Wikimedia needn't be afraid of financial problems arising from it (since
never more than a given percentage of a month's donations are spent on
these bounties).

Timwi


subject: [Wikitech-l] Re: Special:AskSQL

body:
?var Arnfj?r? Bjarmason wrote:

> Even if you dont enable that for en. due to load problems, could you
> at least enable it for smaller wikipedias like is. pretty hard to bog
> down the DB on a 4MB database, even with the most intensive queries,
> would be a great maintenence tool.

The argument against this has always been that with Special:AskSQL
enabled on any Wikimedia project, you can access any DB for any other
Wikimedia project. Personally, I don't know how, but maybe the relevant
SQL syntax element could be filtered out to prevent this?

Timwi


subject: [Wikitech-l] Re: Plain text of page?

body:
Karlheinz Toni wrote:

> Thank you for your answer. Is there any possibility of getting the formatted
> text of the pages (without navigation,... just the information on the
> page)...

You mean the HTML?

Well, you could download the page (http://en.wikipedia.org/wiki/Article)
and harvest everything between "<!-- start content -->" and "<!-- end
content -->", but obviously this isn't very professional and works only
because Monobook includes those comments.

Timwi


subject: [Wikitech-l] Re: Rewards for developers

body:
Anthere wrote:

> Erik, I tried the little attribution thingy for when we do not write
> from cpov.
> Look what happened :-)
> http://meta.wikimedia.org/w/wiki.phtml?title=Developer_payment&curid=9457&diff=50349&oldid=50347

Oh, sorry. I wasn't supposed to remove that? :)

I guess I should have checked who it was from. I wouldn't have thought
that *you* wrote it. It looked like an attack on you (personally, I
found the "sigh" to sound like "oh no, not another one of Anthere's
silly ideas").

If you want, put it back in.

Timwi


subject: [Wikitech-l] Re: Rewards for developers

body:
Anthere wrote:

> Timwi wrote:
>
>> Hm, I would be vastly grateful to anyone who could summarise the
>> system I proposed on the other mailing list (foundation-l) on a meta
>> page where it will be discussed. :-) (I would do it myself, but I have
>> this project deadline next week :/)
>
> Could you do the summarizing please ?

Well, I'll do it after the deadline, but if someone wants to beat me to
it ...


from_name: Bill Clark

body:
On Mon, 26 Jul 2004 10:45:02 +0200, Yann Forget <yann at forget-me.net> wrote:

> And just to add my 2 bits, you want to use sudo whenever possible.

Yes, if sudo does the job, that's the best solution of all.

(Of course, we're not talking about "sudo bash" right? That's crazy talk!)

-Bill Clark


from_name: Sj

subject: [WikiEN-l] "The Register" is making fun of us

body:
> Anyone care to form or join a Public Relations committee? First order of business
> would be to send an apology to The Register and assure them that the "wankers"
> who flamed them were not speaking officially for our project. We might also ask
> for suggestions on improving our article about their newspaper...
>
> Ed Poor
> Fiddler and Bureaucrat

Yes, please.  Coordinating responses to press about us is an excellent idea.  I
shuddered a bit myself when I saw those responses, and when I saw someone on
IRC (Raul?) write that they had sent a followup to the second Register
piece.  I'm
not sure we have anything to apologize for -- it isn't anyone's
responsibility to
control what kinds of letters Wikipedians write -- but we should send them a
properly respectful and thankful reply.

After all, by publishing their initial article they fixed a glaring
POV and stylistic flaw
in an article about my favorite 20th century patent artist.

+sj+


subject: [Wikitech-l] New servers for wikipedia

body:
On Mon, 26 Jul 2004 14:08:12 +0200, Camille Constans
<wikipedia at shaihome.net> wrote:

> http://meta.wikimedia.org/wiki/Q3_and_Q4_2004_hardware_order_worksheet#Quick_proposal

Remote serial consoles allow access to the systems during boot, but
might not be supported by the BIOS.  I think this is worth looking
into, since the APC power switches aren't much use in diagnosing a
machine that hangs during boot.

More information can be found here:

http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/

and here:

http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/bios.html

(and on the talk page for the link Shaihulud provided)

-Bill Clark


from_name: Tim Starling

subject: [Wikitech-l] Re: Rewards for developers

body:
I'm concentrating my comments on this subject in the meta page, but I
just wanted to make a wry comment on the subject line of this thread.
MediaWiki development is the most rewarding job I've had so far, despite
the fact that I've never made any money from it.

-- Tim Starling


from_name: leonard.vertighel at web.de

subject: [Wikitech-l] Can't delete a 0 byte image

body:
Hello all,

can anybody tell me why I can't delete this file:
http://it.wikipedia.org/wiki/Immagine:Mrdoctor.jpg
If I click the "canc" (="del") link next to it, I get
'Non ? stato possibile cancellare il file "/usr/local/apache/htdocs/wikipedia.org/upload/it/d/d6/Mrdoctor.jpg"'
(='Could not delete the file ...'). Trying to open the image itself gives a 404.

I don't think this is related to the lenght of 0 byte, as I already successfully deleted other 0 byte uploads. Is this just a minor database inconsistency? Should I ignore it?

On a related note: is there a way of getting a list of images where the image description was deleted instead of the image itself? I can't do that working on a database dump, right? Any suggestions? (Sorry if this is a FAQ - I'd expected it to be one, but I couldn't find an answer neither on meta nor in the gmane archive).

Thanks,
[[it:Utente:Leonard Vertighel]]

________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193


subject: [Wikitech-l] Re: __ADDSEC__ keyword - A new (unfinished) feature

references:
<51dd1af804072217033709ab7d@mail.gmail.com>
	<cdtms2$3it$1@sea.gmane.org> <51dd1af80407240857e1ef13c@mail.gmail.com>

body:
Aevar, I like it.  I've often thought that many non-article pages need
one of those links... ~~sj~~

On Sat, 24 Jul 2004 15:57:57 +0000, ?var Arnfj?r? Bjarmason
<avarab at gmail.com> wrote:
> Because sometimes thats just not feasable, In tha case of the village
> pump for example the talk page is where people talk about the actual
> chat page, it's layout and such. There is a need for this because
> people already have "Add to this conversation" links all over the
> place and this would just provide a standard way to let people do this
> on all pages.
>
>
>
> On Sat, 24 Jul 2004 15:06:12 +0200, Ashar Voultoiz <thoane at altern.org> wrote:
> > ?var Arnfj?r? Bjarmason wrote:
> > > I thought of a neat feature today while browsing the Village pump,
> > > pages in all talk namespaces have a neat + link besides the Edit link
> > > so you can add a new section to it, so i thought it would be nice for
> > > things like the Village pump to be able to have that link added with a
> > > keyword to every page that had that keyword in the wikitext. I named
> > > that keyword ADDSEC for "add section" and it's invoked with
> > > __ADDSEC__.
> >
> > <snip>
> >
> > Why not moving that talk page to the talk namespace ?
> >
> > Aka : [[Talk:Village pump]] instead of [[Village pump]] :o)
> >
> > --
> > Ashar Voultoiz
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

--
--:-------.-.--------.--.--------.-.--------.--.--------[...]
+sj+