body:
> > 1) Not allowing people to add links to external URLs to pages without
> > first logging in.
>
> So, they log in, which doesn't solve anything. 21c3.ccc.de and
> is-root.de were hit with more of this wikitikitavi spam today, and it
> all came from logged in users. All this does is prevent people seeing
> the spammer's IP, making it harder to block them on other languages or
> other projects, and making it harder to find all the spam from one
> user when they change usernames more easily than they change IPs.

Nevertheless, the vast majority of spam on inactive _Wikipedias_ is
from unloggedin users. To write a spambot that registers and logs in
at multiple inactive Wikipedias is more trouble. It won't solve
isolated incidents, of course.

But it would hopefully act as a deterrent, removing so many inactive
WPs as sitting ducks.

> > 2) Not allowing people to add #REDIRECT ... to pages without first
> > logging in. If they tried to, they'd get a "preview" window and a
> > warning message.
>
> Although redirects within a wiki are a little harder for non-admins to
> revert than normal vandalism, I don't think this problem is common
> enough to warrant more confusion to unregistered users. The lack of
> ability to move pages already causes problems. Wikimedia already
> disables cross-wiki and special page redirects, so I don't think we
> need more restrictions in this area.

I guess that's true. The only real problems have been people who are
vandalising rather than spamming, such as redirecting [[Main Page]]
to, say, [[Dsapiodfpioipoasdf]]. However, people who do this log in
more often, and use the pagemove function instead. So far, Afar god
(hit one Wiki), Willy on Wheels (hit 3 wikis so far), and a few other
less memorable users (Afar god was actually a bit funny, and Willy on
Wheels hit multiple Wikis).

> > 3) Not allowing people to replace, say, 30kb of text with two words,
> > without first logging in. If they tried to, they'd get a warning
> > message and woudln't be able to submit it.
>
> Wouldn't this make it harder to maintain these small wikis? They have
> no admins, so deleting a page means blanking it or putting {{delete}}
> on it for the benefit of some future admin. How can anyone clear up
> junk and copyvios if they can't easily (ie - without logging in) blank
> a page? Expecting people to log in on small wikis is more of a demand
> than expecting them to do so on a large one, since there is less
> benefit. If all you ever want to do is blank one page there, why make
> an account? And if you have an account, you probably don't use it
> often enough to stay logged in.

Although that's certainly true... hmm... the only possible solution to
the issues you raise would be to whitelist certain IP ranges, which
although feasible is probably not something that anybody would agree
with for whatever reasons.

> > 4) Not allowing ANYBODY to have one or more external URLs as the sole
> > contents of a page, except perhaps stewards or admins
>
> That would be so easy to get round that it would be pointless, and
> perhaps even damaging. If I see a page full of URLs, it's very quick
> to recognise it as spam. If we force the spammers to be clever and
> start mixing content with the spam, it's going to be harder to spot,
> especially if that content is in a language you don't know.

True...

> > 5) Not allowing anybody to add words like "motherf*cker", "c*nt",
> > "as*hole", "sh*t", that-medicine-that-starts-with-v,
> > that-medicine-that-starts-with-c (including replacing the "a" with an
> > @ sign), "pha ... ceu ... cals", or strings such as "is gay", "is so
> > gay", etc. While allowing such things may be needed on larger
> > Wikipedias, on _inactive_ Wikipedias it would prevent probably 50% of
> > vandalism.
>
> I think there is a setting for this in MediaWiki already, but it's
> only editable by developers. You need to be very careful about what
> goes in it though. Blocking "that-medicine-that-starts-with-c" will
> prevent anyone writing about socialism (which was rather a problem for
> socialism.wikicities.com) :)

See-eye-a-ell-eye-ess is related to _socialism_?? Not sure that
medicine is widely used in the UK, but here it's used as a medicine
for... well... that problem that some middle-aged guys have that would
set off some spam filters if I referred to it by name. I have gotten
plenty of spam about it, and so have Wikis. The pha ... ceu ... cals,
however, needs to be added to that list if it does indeed exist --
lots of spam seems to include that word.

> If the wikis are really inactive, wouldn't a system where every edit
> must be approved, or at least time-delayed, make more sense? Another
> option is to "retire" a wiki. It becomes non-editable, but has a
> button that allows anyone to relaunch it very quickly (perhaps with a
> captcha to prevent spam bots), with no knowledge needed, and no
> bureaucracy about new language edition policies. This could send a
> warning to the people monitoring inactive wikis.
>
> > It solves many of the problems caused by inactive WPs:
> >
> > 1) Vandalism, spamming.
>
> Which of those do you find is the more common problem on inactive/small wikis?

Spamming, by far. Spamming is usually done by bots, vandalism is
usually done by (presumably) teenagers with nothing better to do who
think it's really funny to replace the contents of the Fijian mainpage
with "haha poop is a funny word", or move all the pages on the Xhosa
Wikipedia to "(subject) is so gay", or whatever.

> > 3) The second proposed solution to problem #1 is to _monitor_ inactive Wikis
>
> The reliance on unrelated third party tools to monitor these makes it
> much harder. In my experience, feed readers can't be relied on. The
> ones I've tried do not catch all edits, and and will not scale to more
> than about 300 wikis. This is something that MediaWiki, or a tool made
> specifically for wiki monitoring, needs to do for itself.

This is unfortunately the truth. It would be nice if there were some
feature that listed suspicious edits separately, so that I or you or
someone else could revert them ASAP, and less-suspicious edits (such
as copyvios or pages in the wrong language) could be reverted within
about 2 days.

I used to browse the list of inactive Wikis every few hours, but it
became so inconvenient that I do it perhaps twice or even once every
day now. I really don't feel that pages in the wrong language or
copyvios are hugely crucial to be reverted ASAP, but I do check my
e-mail often enough that if I were to receive an e-mail every two
hours with a list of suspicious edits, I could revert them immediately
as nessecary.

Mark


list: wikipedia-l

source: pipermail-mbox

from_name: Mark Williamson

subject: Ant: [Wikipedia-l] Serbo-Croatian Wikipedia - a policy question?

body:
Expressions and phrases, as far as I know, are not mutually exclusive
in the two countries.

One expression or phrase will certainly be more common in one country
or another, but ultimately I think there are relatively few phrases
which differ.

Now, if you're referring to such terms as Zemljopis/Geografija or
Spanija/Spanjolska, these are quite easily convertable although
perhaps difficult to gather a comprehensive list.

A good list of vocabulary differences can be made quite easily by any
native speaker with good experience in all varieties (presumably
yourself -- not sure of your exact experience, but you seem like the
sort of person with well-rounded experience in Bosnian and Serbian as
well as Croatian), but it will of course still be far from complete.

Whatever terms they miss will, however, be noticed in a testing phase
by editors who will notice that, in actual usage in actual articles, a
particular word sounds distinctly "Croatian" or whatever, and it will
be added. Even after this, it would be impossible for the list to ever
be complete, but it would be good enough hopefully that words needing
conversion but still unconverted would be rare, and there would be a
prominent link for people to report errors in conversion, as on
zh.wiki.

Mark

On 04/11/05, Josip Rodin <joy at srce.hr> wrote:
> On Mon, Oct 10, 2005 at 03:14:57AM -0700, Mark Williamson wrote:
> > In the future sh.wiki hopes to implement an automatic converter
> > between Cyrillic, Latin, Ijekavski, and Ekavski, so these
> > stylistic/dialect/variety issues won't be a problem anymore.
> >
> > Now, with such conversion, you wouldn't have to worry about edit wars
> > over what norm is used, because no matter what norm it is written in,
> > it is displayed in the chosen norm (possibly based on IP range-- users
> > in Croatia and Bosnia get Ijekavian, users in Serbia get Ekavian;
> > users in Croatia, Bosnia, and Montenegro get Latin alphabet, users in
> > Serbia get Cyrillic, but of course you can change these preferences).
>
> It's possible to convert those things, but it's much more troublesome to
> convert expressions and phrases which also differ, let alone style.
> I never heard of anyone making such a comprehensive converter work.
>
> (Sorry for the slow reply.)
>
> --
>      2. That which causes joy or happiness.
>

--
If you would like a gmail invite, please send me an e-mail.
Si ud. quiere que le env?e una invitaci?n para ingresar gmail, env?eme
un mensaje.
Si vous voulez que je vous envoie une invitation ? joindre gmail,
envoyez-moi s.v.p un message.
Se vce. gostaria que lhe envie um convite para juntar gmail, favor de
envie-me uma mensagem.
Se vuleti chi vi manu 'n invitu a uniri gmail, mandatimi n messaggiu.


body:
I think the remedy to this is to not attempt to unify Croatian,
Bosbian, and Serbian, but _only_ their Wikipedias.

Thus, there would still be separate subdomains for bs.wiki, sr.wiki,
and hr.wiki, and even separate mainpages, but they would all use the
same database and bulk of articles.

Mark

On 04/11/05, Josip Rodin <joy at srce.hr> wrote:
> On Sun, Oct 16, 2005 at 02:35:42PM +0200, Jimmy Wales wrote:
> > I do think we should try to respect the will of a great majority of the
> > three peoples, but my sense of it is that the great majority of people
> > do not think that it is wise that we have three separate wikipedia
> > editions.
>
> Milos has previously stated something that cannot be stressed enough: all
> attempts which try to unify Croatian, Bosnian and Serbian would be treated
> as an attack by all communities (and not only by Wikipedian communities).
> That is, I do not believe your impression is correct.
>
> --
>      2. That which causes joy or happiness.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
If you would like a gmail invite, please send me an e-mail.
Si ud. quiere que le env?e una invitaci?n para ingresar gmail, env?eme
un mensaje.
Si vous voulez que je vous envoie une invitation ? joindre gmail,
envoyez-moi s.v.p un message.
Se vce. gostaria que lhe envie um convite para juntar gmail, favor de
envie-me uma mensagem.
Se vuleti chi vi manu 'n invitu a uniri gmail, mandatimi n messaggiu.


list: wikien-l

from_name: Wikiacc

subject:
[WikiEN-l] RFA idiocy (was Slipping quality as Wikipedia gets
	bigger (formerly Can you trust Wikipedia?))

body:
On 11/2/05, Michelle <jareth at crimsonblade.net> wrote:
> I was seriously considering becoming an admin, but after a quick view of
> RFA, I decided it wasn't worth that.
>
>  - Jareth

Some recent RFAs went quite smoothly (for example mine).

--
http://en.wikipedia.org/wiki/User:Wikiacc


from_name: Michelle

body:
Wikiacc wrote:

>
>
>Some recent RFAs went quite smoothly (for example mine).
>
>--
>http://en.wikipedia.org/wiki/User:Wikiacc
>
>
>
Thanks Wikiacc, it could be that I've just seen a few bad examples.
That wouldn't be terribly surprising, since the ones that go well
probably don't get much PR.

- Jareth


list: wikitech-l

from_name: Rowan Collins

subject: [Wikitech-l] Whatlinkshere

body:
On 04/11/05, Robert Jones <bob at jones-cliffe.freeserve.co.uk> wrote:
> I am using Mediawiki 1.5.1, and I Imported my entire collection of pages in
> XML. Now, Special:Whatlinkshere does not show any pages on many of those
> which I've tested.

I think maybe the import tool doesn't pre-process the new pages it's
creating in the way a normal page would; this includes recording the
links, and updating the search index.

> Is this a bug?

Presumably ;)

> Can the whatlinkshere database be flushed somehow?

If you have shell (ssh/telnet/etc) access to your host, you can use
the appropriate PHP script in the maintenance sub-directory; it's
called something like "rebuildLinks.php" IIRC.

--
Rowan Collins BSc
[IMSoP]


from_name: James D. Forrester

subject: [Wikipedia-l] unblocking - bureaucrats?

body:
David Gerard wrote:

> On Wikipedia, the reward for a job well done is another three jobs.

Oh, gods, is that ever true. ;-(

I think that should become one of our standard quotes to give to the
press, really.

Yours sincerely,
--
James D. Forrester
Wikimedia : [[W:en:User:Jdforrester|James F.]]
E-Mail    : james at jdforrester.org
IM (MSN)  : jamesdforrester at hotmail.com


from_name: charles matthews

subject:
[WikiEN-l] RFA idiocy (was Slipping quality as
	Wikipediagetsbigger (formerly Can you trust Wikipedia?))

body:
"Puddl Duk" wrote

>There is no simple formula for what makes a good admin. Rather, it
takes all types.

True. I would say the point is this, though: the good admin, in saying 'I
speak for the community' or 'I act for the community', carries conviction.
Because that's backed up with enough experience and understanding of the
actual requirements for the work that goes on, not just legal forms.

Charles


from_name: Timwi

subject: [Wikitech-l] Re: LiquidThreads

body:
> If this (misrepresenting what I wrote) happens only once to *my* comments,
> it is a significant problem for me. Up to the point where I would stop
> posting comments *at all* until the website makes sure that my comments
> are not edited and still show my signature.

Of course you are always free to not participate in any discussion. I
don't see any problem with that.


subject: [Wikitech-l] Re: LiquidThreads

body:
>>>Shouldn't it be the decision of the users, or community leaders,
>>>whether they would want comments edited or not?
>>
>>Yes. And at least some of those users are reading this mailing list :)
>
> But I still get the idea that we will not even have the option to lock
> comments because some don't want this at all. :-(

It is entirely up to the implementor what and how they will implement
it. If I were to implement it, I would make all comments editable except
by blocked users, so existing Wikipedia policies against disruption and
vandalism can continue to function. Someone else might make comments
editable only by their author. It is then up to Wikimedia to decide
whether to enable the feature as implemented, request a change to the
implementation and hope that someone goes for it, or keep the feature
disabled forever without telling anyone why. Given that the latter one
is currently happening to the article-validation feature, and that its
author (Magnus Manske) is getting visibly frustrated and agitated about
it, I fear the same will happen to this feature, and as a result, I have
discarded my willingness to implement this.

Timwi


subject: [Wikitech-l] Re: LiquidThreads

body:
> Agreed. This discussion has degenerated, on Timwi's side at least, to
> ad hominem attacks and straw man arguments. Why do you persist in
> saying that opinions on talk pages have the same ownership/POV claims
> as articles in mainspace?

Firstly, I am not aware of any ad hominem attacks from me. Since the
definition of ad hominem attack is vague, though, it is easily possible
that people mistake my argumentation for such.

As for strawman arguments, I know they are notoriously difficult to
spot, so I cannot claim I haven't made any. On the other hand, no-one
has pointed out any to me.

As for the second part, who is the "you" you are referring to? If it's
me, the answer is: I don't, and I never did. I feel misunderstood by
about half of the participants in this discussion.

Timwi


from_name: Michael Snow

subject: [WikiEN-l] Re: status correction

body:
steve v wrote:

>--- "Ben E." <bratsche1 at gmail.com> wrote:
>
>
>>What we had was a transfer of the duties of ArbCom
>>to the community,
>>seemingly against their own principles and ours at
>>[[Wikipedia:Administrators]], which shows that
>>adminship can only be removed
>>by Jimbo Himself or by that very ArbCom.
>>
>>
>>Hopefully, the committee can expand and define
>>the case to completely reflect it and the
>>
>>
>community's > wishes.
>
>To resurrect a case requires dabbling in the sinister
>arts -- not often associated with justice or fairness.
>I would argue that 're-deciding' a case cannot be
>fairly done without actually 're-hearing' the case.
>
>Understandably, the Arbcom would prefer to make things
>easy on themselves (theyve been through a lot after
>all), but --just to cheer things up --I contend that a
>re-deciding an old case without re-hearing it is
>improper -- putting aside the /double-jeopardy/
>hung-jury/ mistrial/ precedents involved.
>
>
Well, you were right to put those aside, because even if people in
arbitration cases were entitled to the rights associated with criminal
procedure (which they're not), double jeopardy wouldn't apply in this
case. After a mistrial or hung jury, the next step normally is to have a
new trial if the parties still want to litigate. Since no final verdict
was reached, it's not a second proceeding in the double jeopardy sense;
it's a resumption or a restart of the first proceeding. Which is exactly
what you're getting, since the Arbitration Committee has retaken the
case after the RfA "jury" declined to reach a resolution to the case.

--Michael Snow


subject: [Wikitech-l] Re: rcid in default sig? (was LiquidThreads)

body:
Rowan Collins wrote:
>
> I'd been pondering this myself recently, but it looks like it doesn't
> - and probably can't - know its ID soon enough. Not only does the
> Revision object not get an ID until the insert function (obviously too
> late for text manipulation) but it has to actually be saved in MySQL
> for the autoincrement field to autoincrement. [...etc.etc.etc.]

All throughout this you're assuming that the diff link, or indeed
anything that isn't the comment proper, would have to be part of the
comment text. I understand this assumption may seem self-evident because
this is the way signatures are done on Talk pages now, but from a
development point of view, it's a dangerous assumption to make because
it will clearly lead to an extremely bad implementation.

Timwi


body:
Angela wrote:
>>>I wouldn't mind seeing the timestamp on signatures be a diff link ,
>>>actually: makes it easy to see what was originally posted and doesn't
>>>add more to the standard sig.
>>
>>Thoroughly excellent idea! (Does an edit know what its revision ID is
>>going to be while it's saving?)
>
> It only sounds a good idea if these links are not going to show up in
> the edit text or in diffs.

Obviously, they wouldn't. They aren't part of the comment text.

Timwi


from_name: geni

subject: [WikiEN-l] Try out the rating scheme

body:
On 11/4/05, Poor, Edmund W <Edmund.W.Poor at abc.com> wrote:
> If testing this new feature does NOT cause the servers to slow down
> immediately, then there is no reason not to try it out. Someone had
> claimed an immediate TRIPLING of access time, but Magnus says "I doubt
> it will degrade performance in the initial phase", and I believe him.
>
> Magnus is one of the three people whom we all trust the most at
> Wikipedia. If he says there's no risk in a live test of a new feature,
> then I say there's no risk.
>
> Tim Starling, do you agree?
>
> Ed Poor
> Former Developer

If people are really worried we could:

1.)Try this on one of the smaller languaes

2.)try it around 3am on a monday

3.)I can't be the only one involved in a non wikimedia project. Give
it to one of them to test.
--
geni


subject: [Wikitech-l] Re: Question re. MediaWiki_FAQ

body:
> A last question:
> It appears to be safe to delete user entries from table user for users
> who haven't made edits (can you confirm this ?)

No. Even if they haven't made edits, moves, deletes, protections, and
don't have any watchlist entries, even then there could be entries for
them in 'user_groups' and/or 'user_newtalk'. You're safe only if you
remove all of these, and I'm not making any guarantees that I haven't
forgotten any ;-).

Timwi


from_name: Alphax

subject: [WikiEN-l] Don't call them "anon"

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

Koltwills at aol.com wrote:
>
> In a message dated 11/3/2005 7:51:56 P.M. Eastern Standard Time,
> alphasigmax at gmail.com writes:
>
> See, I  have proved it! :)
>
> (Of course, I could always be a *third* sockpuppet  of these two... ;) )
>
>
> Silly drivel.
>
> Instigator! :p
>

I further prove my point that you two are sockpuppets by the fact that
NEITHER of you are able to quote correctly. The fact that I am able to
do so suggests a split personality emerging; so here we have one person
split into two personalities, one of which is pretending to be two
people, the other is noting how similar the other two are (and somehow
managing to write coherently).

Now stop listening to me and get back to pretending to not be not
someone else's sockpuppet who isn't a sockpuppet just because they act
in exactly the same way which conclusively proves that they are indeed a
sockpuppet.

I rest my lack of a case.

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ2sj2bMAAH8MeUlWAQi2hQgAsVgfaoN/e35WJhNrW1Jegsj2kRygBnSl
pn82hqAc85ePn+OGGz6Pb8pLsz2Mj8mKB4oj65r2XQ/zBn6L2o0sIRDRlO9wQ9/V
yklJx5MFhU1ldzyXAWoCeAk7jez040c/QDS1nAHdLN/KXAO65LHpDK9hpTndY+KU
4jdWtpD7b//cLeVvjb8Jv6637qtfIw8j+BLgrMC8CwG+F5yuBh6rObCskeFZYxY0
w6t5bBlxf0EqlPXDbjtQMhCS4TSu5RHFFRKshevjZUbhs9+w6lJxtCagjriKRglK
rBtMDn4vYuuD+nVxX3WGxBEpab9ePqNQpnE5ntaA+5r7uo56EYocmA==
=dN+X
-----END PGP SIGNATURE-----


subject: [WikiEN-l] status correction

body:
On 11/4/05, steve v <vertigosteve at yahoo.com> wrote:
> > Geni is to be commended, not "suffer a penalty"!
>
> Well, Geni seems like he's just a kid and I didnt mean
> to pick on him. I would prefer to have just let the
> issue go, but hes basically claiming that:
>
>   'I dont need to give due attention or make
>   intelligent discernments when I take upon myself
>   enforcer duties -- I just need to robotically
>   respond to requests on WP:AN/I and hope that people
>   are equal in tattling on each other.'

It's a pretty safe assumption. I've run across two cases where it was
not the case (if we exclude false reports which are really a different
issue).  If you belive you could do a better job than me on inforceing
the 3RR you were free to do so (technicaly you still are however I
don't think it would look too good if you tried). A less robotic
aproach doesn't help your case because I could take the following into
account:

You are an admin and should know better
You reverted more times
The page is protected so CJK can't revert it anyway

Result? Well logicaly I should block you for longer than CJK.

> Like you said 'the violations were minor' -- is this
> all because I argued with an improper block, one which
> Geni himself said was done improperly, and done under
> "time constraints", and limited only to "reported
> violations" (which was never in any 3RR draft that Ive
> read/edited):
>
>     I stand by my initial block under the 3RR. Yes I
>     should have blocked the other party but it wasn't
>     reported and due to time restriants I only cheak
>     reported violations. I was contacterble by email
>     for as long as the block lasted. Geni 10:08, 14
>     August 2005 (UTC)
>

You didn't argue. You pull the block. You could have contacted me by
email. You could have contacted almost any admin by email (if you know
of any any admins who can't be contacted by email please tell me so I
can leave polite notes on thier talk pages). In fact contacting
another admin to unblock you is probably the best move since I don't
know of any case where an admin has not has thier block pulled early
as a result.

> Well, sure -- the case system is, just like Geni's
> inerpretation of the blocking system, means singling
> people out.

Singleing people out? I've probably carried out over 100 3RR blocks

> And even though there were other policy
> violations, those can be overlooked because my lack of
> "gracefulness" tips the scales in your view. I'll go
> run and consult the Virgin. (Why not just add sarcasm
> to the charges?)

Because useing test would have to be outlawed.

--
geni


subject: [WikiEN-l] Don't call them "anon"

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

Koltwills at aol.com wrote:
>
> In a message dated 11/4/2005 4:06:29 A.M. Eastern Standard Time,
> alphasigmax at gmail.com writes:
>
>> I  further prove my point that you two are sockpuppets by the fact  that
>> NEITHER of you are able to quote correctly. The fact that I am able  to
>> do so suggests a split personality emerging; so here we have one  person
>> split into two personalities, one of which is pretending to be  two
>> people, the other is noting how similar the other two are (and  somehow
>> managing to write coherently).
>>
>> Now stop listening to me and  get back to pretending to not be not
>> someone else's sockpuppet who isn't a  sockpuppet just because they act
>> in exactly the same way which conclusively  proves that they are indeed a
>> sockpuppet.
>>
>> I rest my lack of a  case.
>>
>
>
> My God.
>
> U need a life!  And, very possibly, your meds adjusted.
>

I get emails for free! I don't get Wikipedia for free.

If someone can develop a Mediawiki "edit by email" extension, I will be
very happy!

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ2spSbMAAH8MeUlWAQivrAf8CpIGJaPbAVVKMzoWnMxdOAluMR2VTfHX
9+/YVC762ciqtaPxEGiTQDjdOYJ2ikhyZW9Fsd7jvzhuN6dlVHxJ/yiYk4ETp/tO
m3HULSbdH2caC3QibekYTu47h7U4t8XWLosuIq2tnIYJstJNPxNYB4g/0B+76aS7
1umRg0oCnNrNfYXA0whPaPJKs/CyyRmEakFq6QlQb+qR8aOyFzn+Upd9aNrouSfK
dSEMPpt2nQKu1XTr7aeYRvixHHH7GQN9gXjWArW9X7Anb1zcdsLWBNkWZspjIDJo
U5mh3ctGq2rXrRxU1WpgOOjvs0XSwFSzOASCxVPBcvzo7wuQ6SqZtQ==
=+ynY
-----END PGP SIGNATURE-----


body:
Gregory Maxwell wrote:
>
> We're talking about a new feature which [...]

Oh, I see. Looks like I didn't quite follow the change of topic. I
apologise.


list: foundation-l

from_name: Michael Bimmler

subject:
[Foundation-l] Fwd: [Pressemeldungen] Anfrage zu Partnerschaft,
	Kooperation und Linktausch

body:
The list it was sent to was definitely the wrong one, maybe you want to have
a look at...

---------- Forwarded message ----------
From: Christian Rieger <christian.rieger at dantotec.de>
Date: 04.11.2005 11:28
Subject: [Pressemeldungen] Anfrage zu Partnerschaft, Kooperation und
Linktausch
To: pressemeldungen at wikimedia.org

Sehr geehrte Damen und Herren,

hiermit m?chten wir bei Ihnen anfragen, ob Sie gerne mit unserer Firma, der
Dantotec GmbH (**www.dantotec.de <http://www.dantotec.de>), eine
Partnerschaft bzw. Zusammenarbeit starten wollen.
Wir arbeiten seit Jahren mit sehr renommierten Seiten wie Pocketnavigation,
PPC-Welt, WorldofPPC, KFZ-Auskunft und vielen mehr in einer sehr angenehmen
Art und Weise zusammen.

Wichtig w?re uns ein Linktausch mit Ihrer Seite, denn heutzutage steht das
"Suchen und Gefunden werden" im Internet an allerh?chster Stelle.
Gesch?ftserfolge und positive Entwicklungen sind oft davon abh?ngig, welche
Relevanz ein Interauftritt f?r Suchmaschinen wie Google, MSN, AOL, Yahoo,
usw. hat. Deshalb suchen wir Partner im Bereich GPS, PocketPC, Palm, GPS mit
PDA und Palm, GPS Systeme, GPS Entwicklung, GPS Zubeh?r, etc. um unsere
Bekanntheit im Internet zu steigern. Im Gegenzug profitieren Sie mit einem
Link Ihrer Seite bei uns mit einem gestiegenen Listing bei Suchmaschinen

Zum Prozedere:
Der Voragng ist sehr einfach. Wir setzen von Ihnen (Ihre Homepage) einen
Link auf unsere Seite, Sie setzen im Gegenzug einen Link von uns (**
www.dantotec.de <http://www.dantotec.de>) auf Ihre Seite. Sollten Sie
mehrere Seiten haben, so k?nnen wir auch mehrere verschiedene Seite bei uns
verlinken. Wir besitzen 34 Domains mit verschiedenem Inhalt, die sich mit
dem Thema GPS und drumherum besch?ftigen.

F?r unseren Link ist noch eine Kurzbeschreibung sinnvoll, so werden die
Links von den Suchmaschinen besser indiziert:

**www.dantotec.de <http://www.dantotec.de>
Dantotec GmbH - Der Profishop f. mobile GPS Navigation mit Pocket PC, PDA,
Palm, Navigationssoftware, GPS Empf?nger kabelgebunden o. Bluetooth, Brando
u. OnScreen Plus Schutzfolie, alles von Krusell, Piel Frama, Proporta,
Brodit Autohalterung, gute Preise

Der pers?nliche Kontakt zu unseren Partnern ist uns sehr wichtig, deshalb
k?nnen Sie uns nat?rlich auch jederzeit anrufen.

F?r weitere Fragen stehen wir gerne zur Verf?gung!

Mit freundlichen Gr??en,

Christian Rieger
Marketing Assistant

Ihr Dantotec Team
Dantotec GmbH, your solution for success...
Georg-Knorr-Str. 23
85662 Hohenbrunn
Tel.: 08102-7776-0
Fax: 08102-7776-10

eMail: **info at dantotec.de
Internet: **www.dantotec.de <http://www.dantotec.de>
Allgemeine Gesch?ftsbedingungen (AGB): **

_______________________________________________
Pressemeldungen mailing list
Pressemeldungen at wikinews.org
http://mail.wikipedia.org/mailman/listinfo/pressemeldungen

--
An eternity is very, very long, especially towards the end


list: wikimedia-l


subject: [WikiEN-l] Re: Try out the rating scheme

body:
> Theres no issue of trust in the developers, but
> prudence is always prudent : I agree with Geni (in
> this case): simple.wikipedia.org would be a good place
> to do it, as would drive a little added interest in
> simple. (I dont know if thats a good idea or not).

I thought simple was going to get shut down.

Of course, it could still be used as a guinea pig for new features, but
I didn't realise that there is still interest in reviving it.


from_name: Jean-Baptiste Soufron

subject:
[Wikipedia-l] Re: [Foundation-l] Privacy policy and
	editing	anonymously notice.

body:
Once again, such a disclaimer must clearly state the agreement of the user.

My proposal is :

Unless you are [[Special:Userlogin|logged in]], by editing Wikipedia you
agree that your edit will be signed with your [[IP address]]. If you are
[[Special:Userlogin|logged in]], by editing Wikipedia you agree that
your edit will be signed with [[Special:Userlogin|logged in]]. In both
cases, you agree that these personal data will be used internally and
publicly available. Please see our [[wikipedia:privacy policy|privacy
policy]].

Jean-Baptiste Soufron, juriwiki-l

Chris Jenkinson wrote:
> Bryan Derksen wrote:
>> I'm afraid I don't understand your objection. My proposed wording says
>> "Unless you are [[Special:Userlogin|logged in]] your edit will be signed
>> with your [[IP address]] when you click 'Save'," which explicitly says
>> your IP address _will_ be made public (signatures are public by
>> nature) - it's the whole point of the thing. It doesn't say one way or
>> another whether your IP address will be recorded if you're logged in,
>> so that's not factually incorrect either. I addressed that in my comment.
>
> It doesn't explicitly say it, it implicitly says it - if you take
> "signed" to mean publically. I have never been aware of a signature to
> be public.
>
> Your proposed wording also implies that your IP address will not be
> "signed" with your edits if you are logged in, which might be true
> according to your definition of a signature, but your phrasing is
> ambiguous and confusing.
>
> Chris
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


subject:
[WikiEN-l] Re: [Wikipedia-l] Re: [Foundation-l] Privacy policy and
 editing	anonymously notice.


body:
On 11/4/05, Timwi <timwi at gmx.net> wrote:
> Of course, it could still be used as a guinea pig for new features, but
> I didn't realise that there is still interest in reviving it.

It has it's uses. Allowing people to destress while still being
productive for one.

--
geni


from_name: Angela

body:
On 11/4/05, Michael Bimmler <mbimmler at gmail.com> wrote:
> The list it was sent to was definitely the wrong one, maybe you want to have
> a look at...

It's just link exchange spam. We get hundreds of these sent to the
Board address. I recommended ignoring them.

Angela.


body:
geni wrote:
> On 11/4/05, Timwi <timwi at gmx.net> wrote:
>
>>Of course, it could still be used as a guinea pig for new features, but
>>I didn't realise that there is still interest in reviving it.
>
> It has it's uses. Allowing people to destress while still being
> productive for one.

If that is its only use, then doing so isn't productive. :-p


from_name: Ray Saintonge

body:
Josip Rodin wrote:

>On Sun, Oct 16, 2005 at 02:35:42PM +0200, Jimmy Wales wrote:
>
>
>>I do think we should try to respect the will of a great majority of the
>>three peoples, but my sense of it is that the great majority of people
>>do not think that it is wise that we have three separate wikipedia
>>editions.
>>
>>
>Milos has previously stated something that cannot be stressed enough: all
>attempts which try to unify Croatian, Bosnian and Serbian would be treated
>as an attack by all communities (and not only by Wikipedian communities).
>That is, I do not believe your impression is correct.
>
I sounds to me as though you oppose not only the implimentation of a
single sh:wikipedia, but anything that might make it easy for anyone who
would like to work at one.

Ec


from_name: Andrew Gray

body:
On 04/11/05, Wikiacc <wikiacc at gmail.com> wrote:
> On 11/2/05, Michelle <jareth at crimsonblade.net> wrote:
> > I was seriously considering becoming an admin, but after a quick view of
> > RFA, I decided it wasn't worth that.
> >
> >  - Jareth
>
> Some recent RFAs went quite smoothly (for example mine).

I was quite surprised how smoothly mine went...

--
- Andrew Gray
  666th admin on en.wiki. This may indicate something.
  andrew.gray at dunelm.org.uk


body:
On 04/11/05, Michelle <jareth at crimsonblade.net> wrote:

> Thanks Wikiacc, it could be that I've just seen a few bad examples.
> That wouldn't be terribly surprising, since the ones that go well
> probably don't get much PR.

Yeah. There's ten to twenty at a time; if one is contentious, you
remember that and not the nineteen others. Which suggests that even
5-10% of RFAs being messy is enough to make the process look a lot
worse than it is...

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


from_name: Josip Rodin

body:
On Mon, Oct 10, 2005 at 03:14:57AM -0700, Mark Williamson wrote:
> In the future sh.wiki hopes to implement an automatic converter
> between Cyrillic, Latin, Ijekavski, and Ekavski, so these
> stylistic/dialect/variety issues won't be a problem anymore.
>
> Now, with such conversion, you wouldn't have to worry about edit wars
> over what norm is used, because no matter what norm it is written in,
> it is displayed in the chosen norm (possibly based on IP range-- users
> in Croatia and Bosnia get Ijekavian, users in Serbia get Ekavian;
> users in Croatia, Bosnia, and Montenegro get Latin alphabet, users in
> Serbia get Cyrillic, but of course you can change these preferences).

It's possible to convert those things, but it's much more troublesome to
convert expressions and phrases which also differ, let alone style.
I never heard of anyone making such a comprehensive converter work.

(Sorry for the slow reply.)

--
     2. That which causes joy or happiness.


from_name: Tim Starling

subject: [Wikitech-l] Re: Edit bailouts

body:
Nikola Smolenski wrote:
> On Friday 04 November 2005 01:37, Tim Starling wrote:
>
>>Evan Prodromou wrote:
>>
>>>I guess there's not an easy way to find out how many people are bailing
>>>out of edits that they really want to make... except maybe to ask them.
>>>Perhaps a pop-up poll for folks who navigate away from an edit page in
>>>some way besides saving? Kind of intrusive but it might have interesting
>>>results.
>>
>>You could tell the difference between red link clicks and edit tab clicks
>>by checking the referrer, or by adding an extra parameter to the URL.
>
>
> Even simpler solution: if the article existed when the URL was accessed it is
> certainly an edit, otherwise it's not (might have been attempt of creation of
> a new article, but we can't know that anyway).

You can't tell that from apache logs. Checking the referrer can be done
solely with the apache logs, changing the URL is a one-line change to
MediaWiki. Checking whether a title exists in the database is more
complicated, especially if you want to do it efficiently.

-- Tim Starling


body:
On Sun, Oct 16, 2005 at 02:35:42PM +0200, Jimmy Wales wrote:
> I do think we should try to respect the will of a great majority of the
> three peoples, but my sense of it is that the great majority of people
> do not think that it is wise that we have three separate wikipedia
> editions.

Milos has previously stated something that cannot be stressed enough: all
attempts which try to unify Croatian, Bosnian and Serbian would be treated
as an attack by all communities (and not only by Wikipedian communities).
That is, I do not believe your impression is correct.

--
     2. That which causes joy or happiness.


from_name: steve v

subject: [WikiEN-l] Re: status correction

body:
--- Michael Snow <wikipedia at earthlink.net> wrote:

> Well, you were right to put those aside, because
> even if people in
> arbitration cases were entitled to the rights
> associated with criminal
> procedure (which they're not), double jeopardy
> wouldn't apply in this
> case. After a mistrial or hung jury, the next step
> normally is to have a
> new trial if the parties still want to litigate.
> Since no final verdict
> was reached, it's not a second proceeding in the
> double jeopardy sense;
> it's a resumption or a restart of the first
> proceeding. Which is exactly
> what you're getting, since the Arbitration Committee
> has retaken the
> case after the RfA "jury" declined to reach a
> resolution to the case.

Well if you can call the RFA a "jury," I can rightly
call for some elementary due process, no double
jeopardy, time already served, c&u, etc.

SV

__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs


subject: [Wikipedia-l] Methods of protection of minor Wikipedias

body:
> 1) Not allowing people to add links to external URLs to pages without
> first logging in.

So, they log in, which doesn't solve anything. 21c3.ccc.de and
is-root.de were hit with more of this wikitikitavi spam today, and it
all came from logged in users. All this does is prevent people seeing
the spammer's IP, making it harder to block them on other languages or
other projects, and making it harder to find all the spam from one
user when they change usernames more easily than they change IPs.

> 2) Not allowing people to add #REDIRECT ... to pages without first
> logging in. If they tried to, they'd get a "preview" window and a
> warning message.

Although redirects within a wiki are a little harder for non-admins to
revert than normal vandalism, I don't think this problem is common
enough to warrant more confusion to unregistered users. The lack of
ability to move pages already causes problems. Wikimedia already
disables cross-wiki and special page redirects, so I don't think we
need more restrictions in this area.

> 3) Not allowing people to replace, say, 30kb of text with two words,
> without first logging in. If they tried to, they'd get a warning
> message and woudln't be able to submit it.

Wouldn't this make it harder to maintain these small wikis? They have
no admins, so deleting a page means blanking it or putting {{delete}}
on it for the benefit of some future admin. How can anyone clear up
junk and copyvios if they can't easily (ie - without logging in) blank
a page? Expecting people to log in on small wikis is more of a demand
than expecting them to do so on a large one, since there is less
benefit. If all you ever want to do is blank one page there, why make
an account? And if you have an account, you probably don't use it
often enough to stay logged in.

> 4) Not allowing ANYBODY to have one or more external URLs as the sole
> contents of a page, except perhaps stewards or admins

That would be so easy to get round that it would be pointless, and
perhaps even damaging. If I see a page full of URLs, it's very quick
to recognise it as spam. If we force the spammers to be clever and
start mixing content with the spam, it's going to be harder to spot,
especially if that content is in a language you don't know.

> 5) Not allowing anybody to add words like "motherf*cker", "c*nt",
> "as*hole", "sh*t", that-medicine-that-starts-with-v,
> that-medicine-that-starts-with-c (including replacing the "a" with an
> @ sign), "pha ... ceu ... cals", or strings such as "is gay", "is so
> gay", etc. While allowing such things may be needed on larger
> Wikipedias, on _inactive_ Wikipedias it would prevent probably 50% of
> vandalism.

I think there is a setting for this in MediaWiki already, but it's
only editable by developers. You need to be very careful about what
goes in it though. Blocking "that-medicine-that-starts-with-c" will
prevent anyone writing about socialism (which was rather a problem for
socialism.wikicities.com) :)

If the wikis are really inactive, wouldn't a system where every edit
must be approved, or at least time-delayed, make more sense? Another
option is to "retire" a wiki. It becomes non-editable, but has a
button that allows anyone to relaunch it very quickly (perhaps with a
captcha to prevent spam bots), with no knowledge needed, and no
bureaucracy about new language edition policies. This could send a
warning to the people monitoring inactive wikis.

> It solves many of the problems caused by inactive WPs:
>
> 1) Vandalism, spamming.

Which of those do you find is the more common problem on inactive/small wikis?

> 3) The second proposed solution to problem #1 is to _monitor_ inactive Wikis

The reliance on unrelated third party tools to monitor these makes it
much harder. In my experience, feed readers can't be relied on. The
ones I've tried do not catch all edits, and and will not scale to more
than about 300 wikis. This is something that MediaWiki, or a tool made
specifically for wiki monitoring, needs to do for itself.

Angela.


from_name: Walter Vermeir

subject: [Wikipedia-l] Re: unblocking

body:
Ray Saintonge schreef:

> The important thing is to find some sort of balance.  A bureaucrat
> does need the freedom to make decisions and act, often unilaterally,
> on

> A bureaucrat does need the freedom to make decisions and act, often
> unilaterally, on them.  He needs to pay attention to his community
> and use that to guide his actions.  There will nevertheless be times
> when he will act in a way contrary to the community's wishes.  That
> is not inherently wrong, but the bureaucrat proceeds at his own
> peril.

I do not understand. Are you talking about Wikipedia-bureaucrats?

A bureaucrat is only a sysop who can make other sysops and other
bureaucrats. The can not even revoke the sysop-powers.

What has being a bureaucrat to do whit having "power"?

Besides on a wiki where there totally no law and order an bureaucrat is
not allowed to grant sysop rights to a user with authorisation. For all
other situations the fact of a user is a bureaucrat is irrelevant.

--
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be


from_name: Jack Lynch

body:
Ok already, obviously the process works ''sometimes''. The problem is
that it often does not work. We cannot continue to allow random people
to harass and blackball qualified candidates. The process is
unrewarding, and discourages contributions. Nuff said. ~~~~

On 11/4/05, Kelly Martin <kelly.lynn.martin at gmail.com> wrote:
> On 11/4/05, Andrew Gray <shimgray at gmail.com> wrote:
> > On 04/11/05, Wikiacc <wikiacc at gmail.com> wrote:
> > > On 11/2/05, Michelle <jareth at crimsonblade.net> wrote:
> > > > I was seriously considering becoming an admin, but after a quick view of
> > > > RFA, I decided it wasn't worth that.
> > > >
> > > >  - Jareth
> > >
> > > Some recent RFAs went quite smoothly (for example mine).
> >
> > I was quite surprised how smoothly mine went...
>
> Mine went far better than I ever expected.
>
> Kelly
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: kelvSYC

subject: [WikiEN-l] MOS to sports-related tables?

body:
Is there a MOS relating to sports-related tables, such as standings,
boxscores, etc.?


from_name: Wikipedia Romania (Ronline)

subject: [Wikipedia-l] Re: Serbo-Croatian Wikipedia - a policy question?

body:
As an outsider, I don't really have any interest as to
what way is chosen with the Serbo-Croatian language/s,
but I think it's very important we settle on *one*
way.

Having Serbian, Bosnian and Croatian Wikipedias, and
then having a Serbo-Croatian Wikipedia, is not only a
doubling of efforts, but nonsensical. I think we
should decide now, while it's still fairly early,
whether we will either have a single Serbo-Croatian
Wikipedia (or, as Node says, a single database which
features automatic conversion), or whether we will
continue having Serbian, Croatian and Bosnian
Wikipedias. In the latter case, the Serbo-Croatian
Wikipedia should be closed down.

I know it's hard to say to people who believe in the
Serbo-Croatian language that they should contribute to
either Serbian, Croatian or Bosnian, but it will have
to be done. Even though the languages are nearly
identical, they have been recognised as separate by
the various nations, and politically they are
recognised separately. That is why it is better to
have separate Wikipedias, and abolish the sh.wiki.

If, however, the conversion project continues, then a
unified sh.wiki must be proclaimed, either with bs, hr
and sr being closed down, or them using the same
database. This is a good idea, though I don't know how
it will work in practice.

In any case, it's important to decide now, before it's
too late.

The other thing I'd like to bring up is the case of
the Zlatiborian Wikipedia. There is a proposal over at
http://meta.wikimedia.org/wiki/Requests_for_new_languages
to form a Wikipedia in Zlatiborian. Until now,
however, Zlatiborian has either been declared as a
hoax or as a language too similar to Serbian. I have
talked to various Zlatiborian speakers at meta, and
they have convinced me that indeed this is a separate
language. There is, however, one weak spot - there is
*no* Internet coverage of this language, so
technically there is nothing to prove that it isn't a
hoax... What is the policy towards these proposals?

Thanks,

Ronline
http://ro.wikipedia.org/wiki/Utilizator:Ronline

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com


subject: [WikiEN-l] Try out the rating scheme

body:
On 11/5/05, Alphax <alphasigmax at gmail.com> wrote:
> 3am in which timezone? UTC?

Yes from what I recall between 3 and 6 is pretty quite on that day.

--
geni


body:
On 11/4/05, Mark Williamson <node.ue at gmail.com> wrote:

> Nevertheless, the vast majority of spam on inactive _Wikipedias_ is
> from unloggedin users.

But only because we don't make them log in, not because it's hard to
do so. It's far more of a deterrent to genuine editors than to spam
bots.

> > Blocking "that-medicine-that-starts-with-c" will
> > prevent anyone writing about socialism (which was rather a problem for
> > socialism.wikicities.com) :)
>
> See-eye-a-ell-eye-ess is related to _socialism_??

At the risk of ending up in everyone's spam bins, I'll spell it out:
"so...Cialis...m". Blocking the word blocks any words that contain it.

> if I were to receive an e-mail every two
> hours with a list of suspicious edits, I could revert them immediately
> as nessecary.

I'd also be more likely to check edits sent to me by email. Perhaps
http://meta.wikimedia.org/wiki/EmailNotification could be adapted.
Currently, I don't think it will send diffs, and there's no way of
filtering for "suspicious" edits.

Angela.


from_name: Mark Williamson

body:
> > Nevertheless, the vast majority of spam on inactive _Wikipedias_ is
> > from unloggedin users.
>
> But only because we don't make them log in, not because it's hard to
> do so. It's far more of a deterrent to genuine editors than to spam
> bots.

Unfortunately, that's probably true.

> > > Blocking "that-medicine-that-starts-with-c" will
> > > prevent anyone writing about socialism (which was rather a problem for
> > > socialism.wikicities.com) :)
> >
> > See-eye-a-ell-eye-ess is related to _socialism_??
>
> At the risk of ending up in everyone's spam bins, I'll spell it out:
> "so...Cialis...m". Blocking the word blocks any words that contain it.

Ohh. Duh. But, surely, it would take only a few lines of code to add a
feature so that it only blocked the _whole word_?

I mean, does anybody get spam e-mails that say "Free socialism! Click
here now"... or even "Get free soCialiSm! cl**k here no*" or anything
like that? I don't think spammers are sophisticated enough to realise
that there are legitimate words that contain spam-filter'd words.

Also, there is the occurance of _phrases_: "free (name of product or
medicine)" is significantly more likely to be spam than even "(name of
product or medicine) is a". If you add "get" before the "free", that
is even more likely (exponentially?) to be spam. Add a "now"
afterwards, and more likely. Add "by" after that, or "for"... For the
_second_ one, add the word "nat**al". Then add "h*rb*l"... then
"s*p*l*m't", then "for", then "m*le", then that word that you know
oh-so-well comes next due to the extreme odds!

Of course, anything that filtered on something as complex as this
would be very, very complex programming.

Perhaps instead, somebody could adapt a Free numerical rating system
for spam e-mails (which gives "likelyhoods" that e-mails are spam) --
Google may or may not be willing to help out there given how massive
their database must be and their commitment to Goodness on the
Internet, but if not there would be another project I'm sure.

>From that, some things could be adapted. For example, the "from",
"to", and "cc" lines aren't present, and neither is the subject. HTML
codes would have to have aliases using WikiCode. Things which might be
"automatic kill" for a spam killer would, in many instances, have to
be significantly downgraded, at least for the English Wikipedia (for
example, the-medicine-that-starts-with-c is a legitimate topic, but in
very limited contexts). Talk pages would have to give a certain degree
of slack. The greater the length of a page, the more times its title
should occur within it, or *related* terms (ie, links to articles
which link back to it). So, to a certain extent, "subject" and
"article title" would correspond, although the length-title ratio
would be significantly different.

Certain IPs would be greylisted based on the relative frequency of
spam from them. In fact, every IP range would be assigned a %age based
on existing data. If 90% of the content from an IP range is spam, the
system might notice if any subranges or particular IPs had a
significantly less frequency, and if they did, semiwhitelist them (ie,
"good" percentage points). An IP range with 90% of submissions
legitimate, on the other hand, would have "good" points. If there were
any particular subranges or IPs with a significantly higher perentage
of spam, they would be semiblacklisted ("bad" percentage points, or
less "good" percentage points, depending on the exact frequency).

I'm going into too much detail here, and obviously it would be a
massive undertaking, but given the massive amount of work it would
solve, it's not the sort of pipe dream that I feel guilty bringing up
in front of people who could actually bring it to fruition (I know I
couldn't without learning a programming language first -- right now, I
have very rusty Qbasic, medium-to-advanced HTML, a bit of UNL, but
nothing else, and the latter two aren't exaclty programming
languages).

> > if I were to receive an e-mail every two
> > hours with a list of suspicious edits, I could revert them immediately
> > as nessecary.
>
> I'd also be more likely to check edits sent to me by email. Perhaps
> http://meta.wikimedia.org/wiki/EmailNotification could be adapted.
> Currently, I don't think it will send diffs, and there's no way of
> filtering for "suspicious" edits.

Ahh, but there are already three-halves party applications (meaning,
by Wikipedians, but not software integrated to MeW) which monitor for
"suspicious" edits. Nothing complex, but helpful nonetheless in
filtering out The Good Edits to give only the bad ones, based on a few
very basic observations, as well as feedback.

Mark


from_name: Gregory Maxwell

subject:
[Wikitech-l] Thoughts and measurments related to a new storage
	framework for large wikis.

body:
In many modern wikis (such as mediawiki) every version of a page
through it's life is made accessable. There are many options on how to
store this information, the most simple being to store a complete copy
of every article. Another popular option is grouping up old versions
into one record and gzipping the stack together, block compression.
Versions can be gziped by themselves but this isn't a huge win for
most articles. Duplicate versions can eliminated, diffs can be
computed.. there are many options.

Every one of these options has a time/space tradeoff. Different
options are better for different access patterns.   For Wikipedia we
mostly use whole versions, with a little bit of block compression
thrown in every once in a while for good measure.  This makes deletion
fairly easy although the requirement to truly support deletion is not
that clear.  It is believed that this has reasonable performance
characteristics, but I will explain at the end that it might not be
ideal even from a performance perspective. It is not obvious not ideal
from a space perspective.

I'd like to propose a new framework for storage of archive versions. I
will then back up this concept with some measurements.

When a page is moved into the archive (or sometime before), we compute
its cryptographic hash. If the archive already has that hash, we are
done. This eliminates the bit identical duplicates that come out of
reverting.

If the hash is new, we compute a binary delta between the new version
and the previous version of the page. The previous version is obtained
from version_cache (discussed below). If it is the first version we
diff against the empty string. We store an archive row:
new_page_hash,old_page_hash,delta_blob.

We then insert the new page into version_cache (keyed on the hash). If
the page is large (100K?) it is gziped before inserting if the storage
backend doesn't do this for us (some DB's like PostgreSQL do...).  it
is flaged to mark that it is 'second from top' in its record. We
update the entry for the previous version to indicate that it is no
longer second from the top.

When someone requests a non-current version, we check the
version_cache. If the version is there, we return it. We might keep a
hit counter or a last used date, if we do, we update that. If it is
not in the cache, we find the delta, and check to see if it is in the
cache. We walk back deltas until we find the most recent version in
the cache. We then forward apply diffs to generate all versions up to
the desired cached copy. All generated versions are inserted into the
version cache, although the hitcount/lastused on the middle versions
should not be set as high as the desired version if we maintain that.

Periodically or based on fixed storage pressure, objects in the
version cache are purged. 'Second from the top' objects are never
purged, objects used less often and less recently are dropped first,
however, we try to maintain a version for every 50(? a tunable)
revisions of a page or so.

So thats basically the idea. Now I want to show you some data which
makes this proposal compelling.

Let us consider the article "Anarchism" on enwiki, it's reasonably
large (average 57k over its entire life, 66k currently) but not huge,
and its had a reasonably large number of revisions (4370 in the 10/29
dump)... it's also near the top of the dump which makes it quick to
extract. :) It's not subject to an abnormal amount of editwarring or
vandalism... pretty typical for what we probably want articles to be..

The concatination of all versions of the article is 242MB in size.
This is how much it would take to store ideally without any
compression. In reality the storage size for this article would be
much larger due to non-ideal packing.

If we gzip -9 the concatination, it is reduced to 80MB. This
represents the savings we could get with completely ideal block
compression. If we group the article into blocks of 5 revisions, we
find the storage to require 85MB, which is a little more realistic.

If we store based on the content hash, we eliminate 673 versions.
Without gziping the size is now 206MB. Gzip -9ing each version alone
reduces it to 69MB. (I didn't measure block compression for this one).

If we compute a diff -du for each version with a new hash from the
previous versions we find the concatenation of the diffs are 15MB.
Gzipping the diffs one at a time gives us a 5.2MB file while gziping
in blocks of 5 gives us 3MB.

If we use bsdiff (http://www.daemonology.net/bsdiff/ fast and
efficent, if you ignore the anti-social license) rather than diff -du,
and work on the non-duplicate files we get a total output of 1.4MB.
Plus bsdiff is much faster than diff -du, and much faster to apply
than patch.

If we use xdelta (1.1.3 tested) the total is 1.5MB. Xdelta is almost
much faster than diff/patch. If we disable gzip in xdelta and block
compress in groups of 5, the total is 968K. We can get that down to
500k in blocks of 100 with lzma.. 378k lzma all deltas.  It takes my
system about 4 seconds to apply all 3697 deltas recover the most
recent version from the empty string.. and I suspect most of that time
is spent in fork() since I'm starting xdelta once per diff. If we our
cache tends to keep 1 full version around for every 50 that will only
add a couple of megs of storage.

So frankly, given the size of the current dumps and these results, I
believe that it is likely that  it would be possible to get the entire
working set of Wikipedia article text into ram on the sort of hardware
we could easily afford (a couple of 1u AMD64 boxes running some
imaginary non-sucky version of memcached). Based on these numbers, the
growth we've seen, and the cost curves for dram,  I think we could
continue to keep our working set in ram for the forseeable future.

The computational costs of my proposed model can be substantially
reduced by smart cache management, and are in any case infinitesimal
by comparison to the reduction in IO cost by getting the 160:1
compression and getting the entire working set into ram..

As the wiki grows the gains will only be greater, and there will be
less and less interest in most old page versions.

Thoughts?


subject: [WikiEN-l] Try out the rating scheme

body:
On 05/11/05, Alphax <alphasigmax at gmail.com> wrote:

> More helpful than speculating about "3am saturday morning sounds good"
> would be to check the server logs (assuming they exist) to get some
> ACTUAL DATA.

http://noc.wikimedia.org/stats.php

Times appear to be given in UTC, judging by "Last updated" being only
a couple of hours behind current UTC time - it looks like load is
lowest around 0000 to 0600 UTC on Saturdays and Sundays, with Saturday
generally being a quiet day.

So all things considered, 3am Saturday morning looks good ;-)

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


from_name: Amgine

subject: [Foundation-l] Re: check user policy/Tor

body:
> Wiki projects do not need to know my IP address, and I'm not going to
> provide it. If you don't want my edits under those conditions, it's your
> loss

I agree entirely with this statement. When I compare (anecdotally) the
cost of accepting Tor edits with their benefit, the cost far outweighs
any gain. I would not easily suggest limiting any source of positive
contributions, but anonymizing hosts are not a net positive; quite the
opposite. We should not need to know your IP, but by insuring we cannot
know your IP you also add yourself to a class of users who are not
beneficial to the Wikimedia projects. This is an opt-in situation for
you, and Wikimedia has no ability to separate you from the spammers and
vandals who likewise prevent us from knowing their IP.

Anonymizers should not be considered a problem, but rather a very useful
identifying tool. Make their anonymity a feature, rather than a drawback.

Amgine


from_name: Sean Barrett

subject: [WikiEN-l] Re: status correction

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

James D. Forrester stated for the record:

> steve v wrote:
>
>> Well if you can call the RFA a "jury," I can rightly
>> call for some elementary due process, no double
>> jeopardy, time already served, c&u, etc.
>
>
> Call all you want.

SV:	I can call an unrecognizably new purpose from the vasty ArbComm.

James:	Why, so can I, or so can any man;
	But will they come when you do call for them?

- --
 Sean Barrett     | Give us the gate key.
 sean at epoptic.com | I have no gate key.
                  | Fezzik, tear his arms off.
                  | Oh, you mean this gate key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDbN65MAt1wyd9d+URAr0UAJ4gYgwsEiuA8X+cdUDIWegVX4aVdQCggf0y
NwthYXxhIN+qtO/M2P7US0U=
=QUmf
-----END PGP SIGNATURE-----


from_name: James D. Forrester

subject: [WikiEN-l] Re: status correction

body:
steve v wrote:

> Well if you can call the RFA a "jury," I can rightly
> call for some elementary due process, no double
> jeopardy, time already served, c&u, etc.

Call all you want.

Yours,
--
James D. Forrester
Wikimedia : [[W:en:User:Jdforrester|James F.]]
E-Mail    : james at jdforrester.org
IM (MSN)  : jamesdforrester at hotmail.com


from_name: Gerrit Holl

subject:
Spamfilters (was: Re: [Wikipedia-l] Methods of protection of minor
	Wikipedias)

body:
Mark Williamson wrote:
> > > > Blocking "that-medicine-that-starts-with-c" will
> > > > prevent anyone writing about socialism (which was rather a problem for
> > > > socialism.wikicities.com) :)
> > >
> > > See-eye-a-ell-eye-ess is related to _socialism_??
> >
> > At the risk of ending up in everyone's spam bins, I'll spell it out:
> > "so...Cialis...m". Blocking the word blocks any words that contain it.
>
> Ohh. Duh. But, surely, it would take only a few lines of code to add a
> feature so that it only blocked the _whole word_?

This kind of spamfiltering doesn't really work. Spammers will write
CCialiss, __cialis__, "C1al1s", etc. To properly fight spam one needs a
bayesian spamfilter. If edits get flagged as spam or non-spam, a
database can be built up that allows new edits to be compared with them.
These will then get a 'spam chance' P_s flag, and we could define a
treshhold P_t where P_s>P_t prevents an edit from getting through.
The regular expression 'c[i1][a@][l1][i1]s' has 14 hits in my hammie.db
database for Bayesian Spamfiltering using Spambayes, and I'm sure I've
missed some.

> I mean, does anybody get spam e-mails that say "Free socialism! Click
> here now"... or even "Get free soCialiSm! cl**k here no*" or anything
> like that? I don't think spammers are sophisticated enough to realise
> that there are legitimate words that contain spam-filter'd words.

No, but they do replace letters by characters or introduce spaces in
between.

> Of course, anything that filtered on something as complex as this
> would be very, very complex programming.

Not really.

> Perhaps instead, somebody could adapt a Free numerical rating system
> for spam e-mails (which gives "likelyhoods" that e-mails are spam) --
> Google may or may not be willing to help out there given how massive
> their database must be and their commitment to Goodness on the
> Internet, but if not there would be another project I'm sure.

The good thing about bayesian spamfiltering is that the database is
suited to the own need, and the accuracy grows very very quickly as the
database gets larger.

> I'm going into too much detail here, and obviously it would be a
> massive undertaking, but given the massive amount of work it would
> solve, it's not the sort of pipe dream that I feel guilty bringing up
> in front of people who could actually bring it to fruition (I know I
> couldn't without learning a programming language first -- right now, I
> have very rusty Qbasic, medium-to-advanced HTML, a bit of UNL, but
> nothing else, and the latter two aren't exaclty programming
> languages).

Let us have a look at components of Spambayes. Those can certainly be
used and suited to our task. As tokens we can use IP-addresses, numbers
indicating the amount of code removed (needs some more thinking),
negative points when text is removed/positive when it's added (e.g.
*removing* 'cialis' has the opposite effect as *adding* it), etc.

I can help with adopting Spambayes or using Spambayes components for our
needs. I am not an expert, but I know some.

Gerrit.

--
Temperature in Lule?, Norrbotten, Sweden:
| Current temperature   05-11-05 09:39:55    8.1 degrees Celsius ( 46.7F) |
--
Det finns inte d?ligt v?der, bara d?liga kl?der.


from_name: Peter Mackay

subject: [WikiEN-l] Re: Press badges

body:
> From: wikien-l-bounces at Wikipedia.org
> [mailto:wikien-l-bounces at Wikipedia.org] On Behalf Of steve v
>
> --- Nathan Reed <nathanreed at gmail.com> wrote:
> > We've had this discussion quite a bit on Wikinews -- accreditation
> > does you little good unless a press pass is also issued by whatever
> > event/organization/governmental agency you wish to cover. Some have
> > discussed a meta press corps -- would the bar be higher
> there than on
> > Wikinews? Our concept of an accredited wikinewsie is still citizen
> > journalist. This is a radical concept, of course, and I'm
> not sure the
> > world is ready to deal with it.
> > -N.
>
> A news organization, by definition, is an organized
> newsgathering entity with some degree of accountability.
> Press passes offer people some degree of authority and
> access, and likewise suggest that individuals have
> demonstrated professional credentials.
>
> Just throwing this out there: I dont see how any
> anti-credentialist organization can be in the business of
> giving out credentials.

In the same wiki-way that everything else works here. The community decides
who, based on their contributions, is able to present a professional face to
the real world and a useful contribution to Wikipedia/WikiNews. I use
"professional" here in the sense of "adhering to industry standards", rather
than "being paid for".

I don't know how it is in other countries, but in Australia journalists
aren't licensed. Anyone can be a journalist. Freelancers are common.

As noted previously, Wikipedia is gaining a certain measure of respect and
exposure in the general community. We don't need to sell our encyclopaedic
credentials, just our audience. Nobody considers tabloid newspapers to hold
to high standards of journalistic integrity, but they command wide
readerships, and their journalists find little difficulty in gaining access
to events. All we really need do is say "Google such-and such a subject" and
Wikipedia is generally in the first ten entries, so we've got that sort of
leverage to use with people who are after media exposure.

And realistically, it's a win-win situation. We get information and (most
importantly) free-use photographs, and the organisation or event gets web
exposure that they just can't buy.

Peter (Skyring)


from_name: John Ky

subject: [Wikitech-l] One wiki, multiple websites

body:
Hello,

I want to setup up a number of websites which share a single
wiki underneath.  The only difference between the websites
will be:

* The URI used to access the website
* The main page
* The navigation links

For instance:

I want to be able to have two websites with the following
navigation links:

marrickville.community.org:
  Main page -> Marrickville community
  News -> News at Marrickville
  Events -> Events at Marrickville

bankstown.community.org:
  Main page -> Bankstown community
  News -> News at Bankstown
  Events -> Events at Bankstown

But, I want both websites to use the same wiki, so that they can
share pages, and have the same sign on.

Is it possible, and how much work is involved in configuring
such a wiki?

Thanks

-John


from_name: Tels

body:
-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Saturday 05 November 2005 08:48, Gregory Maxwell wrote:
> In many modern wikis (such as mediawiki) every version of a page
[snip]
> Thoughts?

Sounds great - now someone has to write code to experimentally implement
it :)

Even if we don't manage to keep the data in RAM, reducing the database
size by a factor 100 would be really great.

Best wishes,

Tels

- --
 Signed on Sat Nov  5 10:46:47 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "The UAC is making safer worlds through superior firepower."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2x/yHcLPEOTuEwVAQFQdwf8Cc9qd+4snb8jRrMw226lCDn/i1Tl/r2S
WTerP7+hvM0awZWIOCBIu1XG9qaSabTwxZ2CMTvtNe0oY9//Yuf8dXGnVWKjNLko
bO8DLIluI01I4t4yncFs4CtE63mt3as1fev8uZairaA7HhYqDl1bo/BdN94xR4tT
BwcTQt2izijOfr8BCizLaqvmgmpbEETiiObBLRPxotYQAySB1+IOHSIDBvMZZthL
XKmPTK/ZP8M0eeG4dCaUyQD1zFKmR9Pu9R+uJdpOJF7L5DDds+6CF6X2rPLLhL7x
SvfdYZXgz0Bsco0kl0phuZikY2ZotmdG8YD3kWAu5S8eQc4REpRIng==
=5joF
-----END PGP SIGNATURE-----


from_name: Ray Saintonge

body:
Wikipedia Romania (Ronline) wrote:

>As an outsider, I don't really have any interest as to
>what way is chosen with the Serbo-Croatian language/s,
>but I think it's very important we settle on *one*
>way.
>
>Having Serbian, Bosnian and Croatian Wikipedias, and
>then having a Serbo-Croatian Wikipedia, is not only a
>doubling of efforts, but nonsensical. I think we
>should decide now, while it's still fairly early,
>whether we will either have a single Serbo-Croatian
>Wikipedia (or, as Node says, a single database which
>features automatic conversion), or whether we will
>continue having Serbian, Croatian and Bosnian
>Wikipedias. In the latter case, the Serbo-Croatian
>Wikipedia should be closed down.
>
>I know it's hard to say to people who believe in the
>Serbo-Croatian language that they should contribute to
>either Serbian, Croatian or Bosnian, but it will have
>to be done. Even though the languages are nearly
>identical, they have been recognised as separate by
>the various nations, and politically they are
>recognised separately. That is why it is better to
>have separate Wikipedias, and abolish the sh.wiki.
>
>If, however, the conversion project continues, then a
>unified sh.wiki must be proclaimed, either with bs, hr
>and sr being closed down, or them using the same
>database. This is a good idea, though I don't know how
>it will work in practice.
>
>In any case, it's important to decide now, before it's
>too late.
>
I think that the worst thing that can be done is to rush the decision in
either direction.  I happen to believe that the single project would be
more sensible and productive in the long term, but it cannot happen
unless an atmosphere of mutual trust between the parties can be built.
Political separation is a fact, but it should not be an excuse to
prevent putting something together that is greater than the sum of the
national territories.

If the conversion project succeeds then the sh:wiki.must be the best
place for it.  Having it live in sr:wiki alone (or either of the other
two for that matter) will only give the impression of favoring that nation.

I understand perfectly that the present state of things implies a
doubling of effort, and it wouldn't surprise me to know that the
contributors to each of the four projects draw heavily on the other
three -- particularly in topics that have nothing to do with Balkan
politics.  I don't think that the doubled effort is a big deal at this
stage.  Simply put, the current desire for these groups to work
separately must be acknowledged, but the opportunity to work together
must be available, and it must be promoted with a gentle hand.
Heavy-handed tactics are already too deeply engrained in the history of
this region.

Ec


from_name: Alphax

subject: [WikiEN-l] Try out the rating scheme

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

geni wrote:
> On 11/4/05, Poor, Edmund W <Edmund.W.Poor at abc.com> wrote:
>
>>If testing this new feature does NOT cause the servers to slow down
>>immediately, then there is no reason not to try it out. Someone had
>>claimed an immediate TRIPLING of access time, but Magnus says "I doubt
>>it will degrade performance in the initial phase", and I believe him.
>>
>>Magnus is one of the three people whom we all trust the most at
>>Wikipedia. If he says there's no risk in a live test of a new feature,
>>then I say there's no risk.
>>
>>Tim Starling, do you agree?
>>
>>Ed Poor
>>Former Developer
>
>
>
> If people are really worried we could:
>
> 1.)Try this on one of the smaller languaes
>
> 2.)try it around 3am on a monday
>

3am in which timezone? UTC?

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ2wER7MAAH8MeUlWAQgLcwgAlPtiIJSfOL1yyNSNOsv/WiZiRPcdhnDr
TRqQK7Q1a1VZGlt3/1CcOld6A/1QYHA3v3hW5Jg7hKvReDFtzinB7Xm9FWGDIABV
MgiEYgEhtgHqWrHH5DwicjDjlf7NJdyUGWh5IWY6JiDaajElr/6QfgfLxBlvrUN8
o5N+vpvw4CksEtuPxCvezffhY+HatkyefT0IPlQInxtl8vp9ea1nWZ9MNe3GKLEh
Br2Gqv4dfz40ejFPycMFBaUwowNo3yrbDO0LThNVpwvJxVDFMSC8R+i9hH3JhfvR
RLgOpytHUy8yBGmMac3MMtOoUN6tb5uk12coOmqtYRzpC+H5pvi9Uw==
=K3fq
-----END PGP SIGNATURE-----


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

Andrew Gray wrote:
> On 04/11/05, Michelle <jareth at crimsonblade.net> wrote:
>
>
>>Thanks Wikiacc, it could be that I've just seen a few bad examples.
>>That wouldn't be terribly surprising, since the ones that go well
>>probably don't get much PR.
>
>
> Yeah. There's ten to twenty at a time; if one is contentious, you
> remember that and not the nineteen others. Which suggests that even
> 5-10% of RFAs being messy is enough to make the process look a lot
> worse than it is...
>

The number need not even be that high, and our critics often use the
same comparisions with our articles to judge our overall quality (eg.
Encarta implies that Wikipedia barely functions because of all the
vandalism).

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ2wFALMAAH8MeUlWAQifCQf+MBu4ozzd12WuHK8nHdX0WeNuo/PI715b
j6//MgmBk1wjrg+pYUpwbFjvJjwWTMk8hbzb908tpHX5F8YosrQaip8+Tf3z713d
aoA3B/3ydmTEP1mjbwp5+TdKn3I+ZNW9/wI5UdroEx9oCV6Dl5phfwB2dta3kbwC
aAqDLlHe4sOCmsUsnM3rhlU3jrbnDaLZIL83Aw7+JP0vseDnGTJLQc+CRLaTJ9OQ
RxxRhrYnfcFzok8gg6tGgWnM+dqGVRGFmxcuM54ICETBdVLEXBe9vf1GeVeF6NMg
hsT7uhKIBSKi7psMPN4AY25Ty83X7faeaR6p3jsxCwegP5HQPJZD0w==
=d/8a
-----END PGP SIGNATURE-----


from_name: Timwi

subject: [Wikipedia-l] Re: Methods of protection of minor Wikipedias

body:
> As most people who are veterans of this list will know very well by
> now, I am strongly against the "locking" of inactive Wikipedias.
> However, due to a recent increase in vandalism on inactive Wikipedias,
> I have decided to suggest a few more minor technical sanctions:

No, no, and no again! Spam filtering is not going to solve anything. I
would have thought our wiki history has shown this time and again: You
don't use technical means to fight vandalism (or spam or whatever)! You
use technical means to make it easier for humans to fight vandalism.

The "correct" wiki way, of course, would be to make it easier for
everyone to check the smaller wiki projects without having to check
hundreds of pages. I've been saying this for years, and I'll say it
again: RecentChanges, Watchlists and Newpages need to go inter-language!

E-mail notification comes close to this, because it allows for the
notifications to reach a central place (his inbox) and doesn't require
him to keep checking Watchlists and Newpages on hundreds of wikis. I
would prefer if both were available so that everyone can choose whatever
they find easiest, thereby making spam fighting as efficient as possible.

Timwi


subject: [WikiEN-l] Try out the rating scheme

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

geni wrote:
> On 11/5/05, Alphax <alphasigmax at gmail.com> wrote:
>
>>3am in which timezone? UTC?
>
>
> Yes from what I recall between 3 and 6 is pretty quite on that day.
>

What about in other parts of the world? Not everone (especially people
who use Wikipedia!) lives in Western Europe.

At 3AM UTC, the West Coast of the USA (UTC -8) is at 7PM, the East Coast
of the USA (UTC -5) is at 10PM, with the rest of the US inbetween.
Australia is between 11AM and 2PM depending on where you are and if it's
daylight savings or not.

More helpful than speculating about "3am saturday morning sounds good"
would be to check the server logs (assuming they exist) to get some
ACTUAL DATA.

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ2wZ27MAAH8MeUlWAQgtmQgAlFq7R3mJ/RquHJp/Z5oH5LRnmJEtkpYc
yJzpBIIu+EDjngq2wUbU+fSZaNAo9ClkQWaOREMK14Ks4mFxanqxjmOPkDy1Ck3L
SNrFcANgmU6GXmOP7HpA2MMeuzWo8TieuOgwZGNjcEIYvsSV+I6WyqZAopq6nazc
WHxX1A6KUshNExNa1f5PuloN6ynieWaZmM/i/OyjW4CHakg+qBeAot4TNhjcTpjK
J8K/njvgpUwGgH1Ms7ABPEJ5M/5ibuUxH/lVs7bsrs9ir+Gsg2rVHWj0fqCO5fvj
jYcwcYaPMJXRXqnlwUsDVmtdsGLcL7e88sq+ckoM7tPoyeEiZu1yIw==
=KKXJ
-----END PGP SIGNATURE-----


subject: [Wikipedia-l] Re: Zlatiborian, again

body:
> I was thinking and I can say that I am not oppose to creation of
> Zlatiborian Wikipedia no articles about "Zlatiborian language" on
> English Wikipedia.

I can't make sense of this sentence. What does it mean?

> If people from community want to support hoaxes, I completely agree.

I'm beginning to think that Zlatiborian may be to Serbian as Scots (sco)
is to English and Plattd??tsch (nds) and Alemannic (als) are to German:
commonly considered dialects rather than separate languages, and without
an official orthography.

I used to think they're just hoaxes, too, and indeed the first articles
created in Plattd??tsch were just jokes (i.e. clearly aimed at being
funny to German speakers rather than at conveying encyclopedic
knowledge/information to Plattd??tsch speakers); [[nds:Nokieksel]] is
still like that and hasn't changed since 2nd June 2003. Now, I'm not
particularly active on sco, nds or als, so I don't know if this has
changed and whether those Wikipedias are now treated more seriously, but
I wouldn't be surprised if they're still mainly a playground for
dialectal silliness.

Nevertheless, I don't care that they exist. I think a "playground" can
help increase productivity in the serious projects, but even if it
doesn't, a humorous joke encyclopedia is a productive endeavour too.

Timwi


from_name: Evan Prodromou

subject: [Wikitech-l] Re: Edit bailouts

body:
On Wed, 2005-02-11 at 20:13 -0700, Mark Williamson wrote:

> Don't think that would happen at Wikipedia. You could certainly try it
> at Wikitravel, though... perhaps it would be better-accepted if it
> only popped up for every 3rd bailout? (not per person, but total).

My guess was about once in every 10 bailouts, and only ask the same IP
address once, and only ask if the user's never had a successful saved
edit.

I think it would make a good academic paper for someone -- analyzing
barriers to entry for first-time Wiki contributors. It'd be interesting
to compare across large vs. small wikis, different wiki engines,
different kinds of edits (red link vs. edit tab). A clever grad student
could probably get some money from e.g. SocialText or JotSpot to sponsor
the research.

Anywho. Might be something I pick up in my plentiful spare time.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel (http://wikitravel.org/) -- the free, complete, up-to-date
and reliable world-wide travel guide


from_name: Milos Rancic

subject: [Wikipedia-l] Zlatiborian, again

body:
Now, Mark supports creation of Zlatiborian Wikipedia.

And people on Meta thinks that the situation with Zlatiborian and
Montenegrin is similar.

And people talk about Zlatiborian seriously.

I was thinking and I can say that I am not oppose to creation of
Zlatiborian Wikipedia no articles about "Zlatiborian language" on
English Wikipedia. And this is my last email/edit about this issue.

If people from community want to support hoaxes, I completely agree.
If the relevancy of Wikipedia is not important for them, what should I
do? Just to keep relevancy on Serbian and/or to work on some more
relevant project.


from_name: Magnus Manske

subject: [WikiEN-l] Try out the rating scheme

body:
Poor, Edmund W wrote:
>>
>
> If testing this new feature does NOT cause the servers to slow down
> immediately, then there is no reason not to try it out. Someone had
> claimed an immediate TRIPLING of access time, but Magnus says "I doubt
> it will degrade performance in the initial phase", and I believe him.
>
> Magnus is one of the three people whom we all trust the most at
> Wikipedia. If he says there's no risk in a live test of a new feature,
> then I say there's no risk.
>
Thanks :-)

I'd like to add that *if* I'm wrong about this, someone flip a switch in
LocalSettings to turn it off again. So, worst-case scenario is the
servers getting slow for a few minutes.

Magnus

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


from_name: Jens Frank

subject: [Wikitech-l] (no subject)

body:
We now provide sitemaps for all Wikimedia wikis. The sitemaps
can be found at http://sitemap.wikimedia.org/sitemap/

Sitemaps are XML lists of all the pages in a website. We also
provide the last-modified timestamp for each page and a
"priority". We use a high priority for articles and lower
priorities for the other namespaces.

In mapping.txt there's a  mapping from website name to the URL
of the sitemap. The sitemaps are split by namespace, so if
you're only interested in one namespace, you can get it without
downloading the rest of the files.

A descirption of the XML schema is available
at
http://www.google.com/webmasters/sitemaps/login?sourceid=gsm&subid=us-et-about2

If your application uses our sitemaps we'd be happy to hear about
it.

Regards,

JeLuF

--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f?r Mail, Message, More +++


subject:
[Wikitech-l] Re: Thoughts and measurments related to a new
	storage framework for large wikis.

body:
On 11/5/05, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> Sounds good. If you're serious about coding this, then there's some
> implementation details I'd like to discuss. Just stylistic, nothing
> fundamental. Otherwise, I'd say go for it.

Sure, I'll give a crack at it...
Either email me your thoughts or grab me on irc..


from_name: SJ

body:
On 11/5/05, Amgine <amgine at saewyc.net> wrote:

> beneficial to the Wikimedia projects. This is an opt-in situation for
> you, and Wikimedia has no ability to separate you from the spammers and
> vandals who likewise prevent us from knowing their IP.

But we do.  Allowing anonymous users to create respected user accounts
is an important service that we should offer the community of editors.
 Especially if we want to encourage editors from parts of the world
where even editing such a body of work is prohibited.

++SJ


body:
On 11/5/05, SJ <2.718281828 at gmail.com> wrote:
> On 11/5/05, Amgine <amgine at saewyc.net> wrote:
>
> > beneficial to the Wikimedia projects. This is an opt-in situation for
> > you, and Wikimedia has no ability to separate you from the spammers and
> > vandals who likewise prevent us from knowing their IP.
>
> But we do.  Allowing anonymous users to create respected user accounts

Which is to say, we could easily develop the ability to separate
respected, truly-anonymous accounts (which have proven their
respectability over time), from spammers and vandals.   SJ


from_name: Cormac Lawler

subject: [Foundation-l] Vote to create Wikiversity Vote

body:
On 11/3/05, Ray Saintonge <saintonge at telus.net> wrote:

> When I first suggested the name Wikiversity in an exchange with Mav it
> was only semi-serious.  While I sincerely believe in the idea, I also
> see that no-one has yet appeared with the vision needed  to really take
> this idea forward.  The vision that Jimbo provided to the development of
> Wikipedia is simply not there for Wikiversity.  The "Vision" section of
> the proposal starts with "Wikiversity could ...".  Great visions do not
> start with a conditional verb.
>
> The vision must go further than a mere listing of proposed courses or
> textbooks.  Relying too much on our experiences with established
> universitie (or our rebellion against them) is nothing more than a
> recipe for "same old, same old".  If a Wikiversity is to really succeed
> it must offer something different.  An electronic version of traditional
> techniques is not different enough.  Nothing in what I have read in
> these discussions shows that anybody has any idea about the nature of
> education and how people learn.  Has anyone considered why it is that
> critical thinking can only start when the prejudiced logic of earlier
> education has been unlearned?  How does Wikiversity adapt to NPOV?

Ray (et al.),

you might be interested in a conversation I had with
JWSchmidt/JWSurf/Memenen about wikiversity (which for the moment I've
put in my user space):
http://meta.wikimedia.org/wiki/User:Cormaggio/Wikiversity_chat_04Nov2005

I mentioned your last email, and I hope you don't feel misrepresented
by the reaction. But we both feel that Wikiversity needs to grow
through a collaborative process, and that asking for what it's 'going
to be' is premature and inappropriate (there will probably be a range
of ideas about how individual courses will run, for example - to
account for different learner and teacher styles). However, I think we
both have a pretty well-formed vision about how we see wikiversity
developing and working - an indication of which you can find in this
conversation - although there are other views and debates which you
can find at wikibooks:Wikiversity:About and its talk page:
http://en.wikibooks.org/wiki/Wikiversity:About

Regarding Wikiversity's identity, there will probably be courses that
are quite conventional, not much more than teaching materials and
associated questions. But some courses will be quite different - I
would be interested (and JW is too) in creating learning communities
that work and learn together, possibly even creating content for
Wikipedia or Wikibooks. You can see my brief ideas on how people learn
on the meta page learning community, which I've linked to from
Wikibooks:Wikiversity:
http://meta.wikimedia.org/wiki/Learning_community
and a more detailed explanation in my dissertation, linked from my
Wikipedia user page
http://en.wikipedia.org/wiki/User:Cormaggio

Critical thinking will be central to what I and JW will be doing - see
my sketch for a course on media literacy, which I would like to form a
large collaboration on:
http://en.wikibooks.org/wiki/Wikiversity:Media113

I hope this gives an indication of some visions of wikiversity. Part
of the problem at the moment is that debate/info is spread over too
many locations, which would be eased by having a dedicated project.
But I'd like to invite anyone reading this to contribute to this
vision instead of criticising it from afar - the meta:Wikiversity page
is a compendium of ideas through time and is possibly the best place
to collate everything together. Alternatively, you could start your
own ideas for a course at Wikiversity's current location at wikibooks,
and outline what you would like to teach and/or learn and how you
would like to do it..

Cormac / Cormaggio


from_name: GerardM

subject: [Foundation-l] Wikiversity and language training

body:
Hoi,
On Meta we wrote an article about the teaching of languages.
http://meta.wikimedia.org/wiki/Language_training_in_Wikiversity Please have
a read.

There are two things that are important to mention; the University of
Bamberg is working on the implementation of what is written. The software
will be a toolkit that can be used by people developing a curriculum or by
people defining targeted exercises for specific conditions. As the
University of Bamberg is in the business of teaching Italian to Germans,
many if not most of the exercises will be created. When the curriculum is to
be used for speakers of other languages, it will be a matter of defining the
meta data about these languages and making sure that the translations for
the key Italian words exist in the Ultimate Wiktionary

One other key thing in computer based training is how and where and under
what conditions do you store information about the educational process. When
the curriculum for the learning of a language gets to the stage where many
of the exercises can be handled by the computer including evaluating and
reporting to a possible teacher, it will free the teacher to teach the
things where a computer is at a disadvantage; stimulating the active use of
a language comes to mind.

There is always this argument that a good teacher cannot be replaced by
material and I agree. What we can do is creating material where there is
much more personalisation of the learning material to the student. When we
have a broad array of texts, we can use these texts to find material that is
of interest to a student. He/she still needs to learn all the basic words
for a language the inflections and everything but this can be wrapped in
topical texts that are of interest to the students. In Wikipedia we have
LOADSA text. In Wikibooks we have even more texts and when we get a
reputation, we may interest newspaper to use their current articles and in
the process let students learn their product..

Thanks,
GerardM


from_name: steve v

subject: [WikiEN-l] Re: status correction

body:
--- "James D. Forrester" <james at jdforrester.org>
wrote:

> steve v wrote:
>
> > Well if you can call the RFA a "jury," I can
> rightly
> > call for some elementary due process, no double
> > jeopardy, time already served, c&u, etc.
>
> Call all you want.

ROFL. Ill admit that its a bit tempting to just say
'YHBT, HAND' etc., just to confirm this specific
generic notion you must have that Im a troll and
anything I might say is just trolling. Any venom that
I might imagine is between the lines of your statement
is at least understandable -- all recent voting and
open discussion considered.

But please know that I am deeply fond of this grand
project, and that I am as sincere as you are in
wanting to help you improve the Arbcom -- at the very
least so that the recent
what-is-sure-to-someday-be-called-a fiasco doesn't
happen again. Help often comes from unexpected
directions -- in this case: me.

:|
SV

__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


from_name: Gregory Maxwell

body:
On 11/5/05, Felipe Ortega <glimmer_phoenix at yahoo.es> wrote:
> Actually, I have another idea (possibly incremental to
> this one): how about starting to prove with a version
> control system (for example, subversion)? I mean,
> moving *gradually* from database to filesystem
> framework.
>
> Obviously, for the short term the idea of being
> capable of storing the entire database in RAM, if
> possible, is better and faster for recovering
> wikitext, but with a filesystem you could even think
> about content distribution...

Well part of the challenge there is that the output files are quite
small... and most filesystems stink at efficiently storing small file.

Actually, what I might implement at first is a read only archive
retriever that latches to a mmaped file, you ask it for an object, it
goes and builds it from the archive and hands it back... It's the sort
of thing we could drop in to take care of serving up old versions
without really redesigning anything.


from_name: JAY JG

subject:
[WikiEN-l] RFA idiocy (was Slipping quality as Wikipedia
	getsbigger (formerl

body:
>From: Wikiacc <wikiacc at gmail.com>
>
>On 11/2/05, Michelle <jareth at crimsonblade.net> wrote:
> > I was seriously considering becoming an admin, but after a quick view of
> > RFA, I decided it wasn't worth that.
> >
> >  - Jareth
>
>Some recent RFAs went quite smoothly (for example mine).

>From what I've seen on the RfA page, the majority of nominations go very
smoothly.

Jay.


from_name: Bryan Derksen

subject: [WikiEN-l] Try out the rating scheme

body:
Magnus Manske wrote:

>Alphax wrote:
>
>
>>The servers just went slow, did you turn it on? :)
>>
>>
>No, but I thought really hard about it :-)
>
>
Aww. So once again, we go right up to the brink and then back off?

Throw ze svitch!


from_name: Felipe Ortega

body:
 --- Gregory Maxwell <gmaxwell at gmail.com> escribi?:

> So frankly, given the size of the current dumps and
> these results, I
> believe that it is likely that  it would be possible
> to get the entire
> working set of Wikipedia article text into ram on
> the sort of hardware
> we could easily afford

> As the wiki grows the gains will only be greater,
> and there will be less and less interest in most old
page versions.

Thoughts?
>
=== message truncated ===

Sounds good, in fact I think it's the logical
evolution for the storage framework. Diff's can be
managed and compressed much more efficiently.

Actually, I have another idea (possibly incremental to
this one): how about starting to prove with a version
control system (for example, subversion)? I mean,
moving *gradually* from database to filesystem
framework.

Obviously, for the short term the idea of being
capable of storing the entire database in RAM, if
possible, is better and faster for recovering
wikitext, but with a filesystem you could even think
about content distribution...

______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, m?s seguridad
http://correo.yahoo.es


from_name: Mark Williamson

subject: [Wikipedia-l] Zlatiborian, again

body:
> Now, Mark supports creation of Zlatiborian Wikipedia.

Yes. You and your Serbian nationalist crew have been repressing the
Zlatiborian national identity for far too long. As you can find in
many credible sources, Zlatiborian is an independent language with an
independent history, spoken by the proud people of Mt Zlatibor, whose
history is glorious and decidedly separate from that of Serbia.

> And people on Meta thinks that the situation with Zlatiborian and
> Montenegrin is similar.

The only difference is that Montenegro has some degree of political
autonomy, whereas Serbian oppression continues to this day in
Zlatibor. I think it is high time you quit trying so hard to repress
the collective Zlatiborian national identity, and allow Zlatiborians
their Wikipedia in peace.

> I was thinking and I can say that I am not oppose to creation of
> Zlatiborian Wikipedia no articles about "Zlatiborian language" on
> English Wikipedia. And this is my last email/edit about this issue.

I have to agree with Timwi -- what on earth does this sentence mean?

> If people from community want to support hoaxes, I completely agree.
> If the relevancy of Wikipedia is not important for them, what should I
> do? Just to keep relevancy on Serbian and/or to work on some more
> relevant project.

The Zlatiborian language is not a hoax. It is the independent language
of a glorious peoples with a long and proud history.

Cheers
Mark