Re: Donation History

As the expenses for Wikipedia have generally before just recently been paid
by Jimbo himself there was no need for accounting. Now it seems we should do
what you suggest as there is a public interest in where the money goes.
Donating is pretty much a new thing at this point for us.

Fred

> From: "Adam Hunt" <adam.r.hunt@...>
> Reply-To: Wikimedia developers <wikitech-l@...>
> Date: Wed, 31 Dec 2003 23:50:10 +0100 (MET)
> To: wikitech-l@...
> Subject: [Wikitech-l] Donation History
> 
> I don't suppose that there is a history graph of the donations to Wikimedia.
> I was currious 
> how much of the US$31k was raised as a result of Jimmy Wales' December 28
> letter and the 
> associated Slashdot coverage.  I was also wondering if Wikimedia's
> accounting ledegers are
> open to the public.  If not, why (this isn't a flame, I'm sure that there is
> a good enough 
> reason)? 
> 
> Thanks for the great site.  In my opinion Wikimedia deserves at least
> another US$30k in 2004.
> 
> --adam 
> 
> -- 
> "Any society that would give up a little liberty to

Re: Wikimedia on-site documentation

Erik Moeller wrote:

>Dan-
>
>>If the documentation used a "Help:" namespace, then none of
>>the links would have to be updated, and all an administrator of a new
>>site would need to do would be to download the documentation database
>>dump and upload it.
>>
>
>Yes, a Help: namespace would probably make sense. Compare:
>
>        Help:Edit conflicts     Wikipedia:Edit conflicts
>        Help:Editing            Wikipedia:Editing help
>        Help:Sections           Wikipedia:Sections
>
>Besides, our own spin-off projects have the exact same problems as Memory  
>Alpha when it comes to these help texts.
>
>Offering this for download would be very easy if it contains no self- 
>references and is nicely isolated. For bonus points, write a script that  
>automatically fetches and installs the latest version of the help texts  
>(preserving older versions and warning if they exist).
>
The Help: namespace seems to be a workable idea, but only for the more 
mechanical issues, and not for policy issues.  At Wikisource there has 
been a demand for this sort of thing, and it would be helpful to be able 
to import a few files from one of the other projects.  For the user it 
would be helpful to know that the same query format will achieve the 
same result on all the the projects.  Perhaps too just typing "help:" 

Re: Single-sign-on

Jimmy Wales wrote:

> I think we should do this ASAP, because the issues are only going
> to get harder.  But the main issue, Timwi, is social -- there are
> certainly cases where two different people have the same username
> but in different languages.

I have already suggested a solution for this some time ago. I'll repeat 
it here because I feel like it 

The basic idea is to mark all accounts as "old" (and make them 
unloginnable), and require everybody to create a new account. Then allow 
users to merge their old contribution-lists into this new account 
provided they know the password to the old account.

So, for example, I would then create a "new" account named "Timwi" and 
then merge "old:en:Timwi", "old:de:Timwi", "old:fr:Timwi", etc. into it.

Timwi

Re: Re: Single-sign-on

On Wednesday 31 December 2003 09:38 pm, Timwi wrote:
> Jimmy Wales wrote:
> > I think we should do this ASAP, because the issues are only going
> > to get harder.  But the main issue, Timwi, is social -- there are
> > certainly cases where two different people have the same username
> > but in different languages.
>
> I have already suggested a solution for this some time ago. I'll repeat
> it here because I feel like it 
>
> The basic idea is to mark all accounts as "old" (and make them
> unloginnable), and require everybody to create a new account. Then allow
> users to merge their old contribution-lists into this new account
> provided they know the password to the old account.
>
> So, for example, I would then create a "new" account named "Timwi" and
> then merge "old:en:Timwi", "old:de:Timwi", "old:fr:Timwi", etc. into it.

Umm, this sounds like an incredibly bad idea:

1. Hassle
2. Account stealing: This would be a feast day for any trolls or malcontents 
(and wikipedia seems to have quite a few of those)
3. Solution in search of a problem

The only problem with the merge is the collision of accounts (eg. there exists 
a [[de:Jan]] and [[en:Jan]], but they are not the same person). Your proposal 
does not solve this, but would need to solve it in the same way as the simple 
merge would: In the rare cases that this happens, people need to discuss and 
come to an amicable sollution. (I would suggest that whoever registered that 

January 1 backup dump online (and old Tomeraider copies)

Enjoy! http://download.wikimedia.org/

Since Geoffrin is still out of service, Ursula is serving this up from 
.204.

The December update to the Tomeraider archives isn't online yet. I'll 
see if I kept a local copy; if not I'll either have to get them from 
Erik again or wait until Geoffrin is back up.

Happy new year, eveybody... and let's not forget that Wikipedia turns 3 
on January 15! The terrible twos are coming to an end. :)

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Donation History

Adam Hunt wrote:
http://mail.wikipedia.org/pipermail/wikitech-l/2003-December/007581.html

Response at:
http://mail.wikipedia.org/pipermail/wikipedia-l/2004-January/013579.html

Please respond there. This topic is not appropriate
for the tech list. 

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Mailing list archives

Does anyone know offhand how easy/difficult it would be to import stuff 
sent through the backup MX into the mailing list archives on the main 
server?

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Re: Re: Single-sign-on

Sascha Noyes wrote:

> The only problem with the merge is the collision of accounts (eg.
> there exists a [[de:Jan]] and [[en:Jan]], but they are not the same
> person). Your proposal does not solve this, but would need to solve
> it in the same way as the simple merge would: In the rare cases that
> this happens, people need to discuss and come to an amicable
> sollution. (I would suggest that whoever registered that account name
> first should have priority.)

Since the en:Wikipedia is longer with us, fist-come-first-serve would 
favor Accounts from en, possibly causing some unhappyness, but it's the 
most straightforward solution. Ambiguous accounts could be simply 
numbered (jan1, jan2). Very nice would be a feature to rename the (own) 
account resp. the ability for admins to do this.

In any case the editing history and the signatures on talk pages etc. 
have to be synchronized with these changes; this could be either done by 
a bot, but it would be non trivial (when is the account on which 
Wikimedia site being changed, when does the bot start renaming, when 
does it finish, when can the account be used again) and cause much load, 
if many accounts have to be merged, or (probably preferred) by direct 
database manipulations when the database is read-only until all changes 
are completed and the integrity is verified somehow. Or is there a 
simpler way?

Regards,
-asb

Re: Re: Single-sign-on

What about keeping accounts as they are, but letting users define links between 
them?

For instance, EnUser on en: declares his user matches DeUser on de:, does the 
reverse. And automatically when s/he logins on either of the sites, login occurs 
on the other sites. Because the system knows that EnUser on en: <=> DeUser on 
de: (obviously you need both declarations for the match to occur).

Ok that would still let users with different accounts on different wikipedias. 
But you could retrive interwiki modifications from the user, using linked 
information.
And it would let users keep their current accounts, so no friction.

OTOH, it means 'User' on en: is not necessarily the same as 'User' on de:.

Just my 2 cents of €

Nicolas

New system ideas

I throught I would throw some ideas of configurations for new wikipedia
systems:

Assuming we have a fast and reliable infrastructure for wikipedia to
operate on, I would hope and expect many more people to benefit from the
gret project. The new hardware configuration needs to have redundancy
built in and reliability.

The DNS system is, by nature, distributed and designed to have many
systems adding redundancy to the resolution service.

A single ip address will always be a single point of failure as the
routers leading up to the physical ip destination will take some time to
propogate a new physical destination for the ip address.

It therefore makes sense to have redundancy switching at the DNS level
and having systems located at different network locations offering
equivalent service.

This brings issues of updates and authentication into the question. The
slave machine cannot authenticate or take database updates. A mechanism
is needed to automatically nominate a machine as master or slave. The
DNS system and each machine would respond to this.

Each wiki server, when booted, will, by default, be a slave. Each wiki
server will periodically request master status from the arbitration
server. The arbitration server can have an algorithm thus:

a)Each wiki server requests master status every 5 minutes.
b)The arbitration/master DNS server checks whether the wiki server