I hereby decree, in my usual authoritarian and bossy manner, that today shall
forever be known as Magnus Manske day. Wikipedians of the distant future will
marvel at the day when the new software era dawned upon us.
Tonight at dinner, every Wikipedian should say a toast to Magnus and his many
After much deliberation, and after due consideration for all of the
arguments and discussions here, and taking into account what appears
to me to be a general consensus, I have chosen to ban Helga for a
period of 3 months.
After that time, she can reapply to me personally for re-instatement.
I know that not everyone will be happy with this decision, although
the vast majority will be. Such is the nature of consensus. I can't
wait for unanimity, or we will wait forever.
I am fully aware of the dangers of precedent, which is why I have
waited so long to take action in this case. Banning should always be
a "last resort". After more than a year of trying to work with Helga,
and after losing more than one highly valued contributor because of
her, we are now at a last resort stage.
To my mind, the difficulty with Helga is not her idiosyncratic views
on history, but her inability or refusal to work co-operatively to
resolve differences. Even here, on the mailing list, where I invited
her to discuss these issues, she prefers to ignore discussions about
her posting style in order to re-iterate accusations of censorship and
to repeat her strange historical claims.
In order to contribute to a restoration of the peace, I will be mostly
avoiding further public comment, although everyone who likes is more
than invited to write to me privately to support or decry this
Helga, in particular, is welcome to write to me to discuss this, but
there is really no appeal possible at this point. The ban is not
permanent, and with good behavior, she can come back and try again in
3 months time.
>>First, those choices are not the only ones; second, your reasoning with #2
>>is flawed. Your other choices:
>> 3. You can simply ignore the policy, as you have done in practice.
Why have a policy in the first place, then?
> 4. You can express your disagreement on the Talk page or on meta or on
> your user page or on the mailing list.
I thought your point was that everybody should just be editing the
policy if they disagreed ("policy is decided by editing the policy
pages"), so then this would not be an option.
>The flawed reasoning with #2 is simply that changes to a page do not an edit
>war necessarily make. If that were so, then Wikipedia wouldn't work. A quote
>from the FAQ: "We assume that the world is full of reasonable people and
>that collectively they can arrive eventually at a reasonable conclusion,
>despite the worst efforts of a very few wreckers. It's called optimism."
There's a big difference between Wikipedia articles and policy pages.
The articles are about things that we do not have control of. We may
have opinions about them, but it's been agreed that we try to present
these opinions neutrally. However, we DO have control over the Wikipedia
policies, and our own opinions DO count. Even if I'm reasonable, my
opinion on many issue may be completely different with that of other
Wikipedians (it frequently is), but there is no NPOV to "neutralise" our
policies. The only way to change or formulate policy is by discussing it
first. The policy pages are meant for Wikipedians to use as a reference.
If I'd just go and change it to my personal opinion, that gives a wrong
picture (unless that personal opinions happens to be the de facto
policy) and things could get really messed up.
User:octal has a suggestion:
It looks like some of the "too many files open" problems are being caused by the large numbers of session files being used by PHP. Is the site maintaining a session for every anonymous visitor? This might cause the problem. (See www.php.net/manual/en/ref.session.php for info on custom session handlers, if you need to store so many sessions but the filesystem is not robust enough, you can move session handling into a database).
Either that, or something in the site is dependant on having a lot of concurrent files open. Good luck with wikipedia. -- octal
I see that a couple of people are busy porting Encyclopedia Libre
( http://enciclopedia.us.es/ ) articles to the Spanish Wikipedia. This raises
a /very/ important question;
Which project are we going have our interlanguage links point to?
AstroNomer has already finished translating language-ES.php and wants the
developers to install the new Phase III software for the Spanish Wikipedia on
the Wikipedia server.
This of course would be a slap in the face of the Encyclopedia Libre folks -
many of whom want more cooperation with Wikipedia. But there is a very vocal
few who hate Wikipedia.
What is everybody's preference here? Should we majorly help revive the
Spanish Wikipedia by upgrading their software or should we put our support
behind Encyclopedia Libre. Remember, EL broke away from the Spanish Wikipedia
over a misunderstanding (and they still have slanderous and unfair statements
about Wikipedia on their about page see:
Encyclopedia Libre currently has more articles and more users/contributors
but they don't seem to have a software development team (just a person or
two). Also many thousands of their "articles" are just templates so their
absence from the Spanish Wikipedia isn't that big of a deal. Also, simplified
logistics is a reason why it makes more sense to keep everything on server(s)
that our developers can access.
However, my gut feeling tells me that we should at least try to work with EL
and then if that doesn't work our fallback plan would be to upgrade the
Spanish Wikipedia and put all of our support behind them. However, if we do
go this route and EL upgrades and we point our interlanguage links there,
then what about all the work that is going on right now at the Spanish
I just want to have this decided so that I can start contributing (I'm such a
WIkipediaholic that I could majorly help revive the Spanish Wikipedia by
porting EL material but I don't want to have duplicated effort between two
very similar projects if it can be avoided).
I think this is very important because the project that gets our new
software, inter-language links, support and future inter-language
functionality is probably the project that will endure. I know it will be the
project I contribute to.
Any other thoughts on this?
-- Daniel Mayer (aka mav)
I've added a (presently for sysops only) Special:Undelete, which should
appear as "View and restore deleted pages" in the special pages list. It
lists the archived deleted pages (the majority of which are pure drivel
and should be flushed at some point), and you can view the archived
pages and their histories and optionally restore them to life.
Restoring a page with the same title as one that currently exists will
tack the deleted page's history onto the end of the existing one's.
The interface is still rather rough and not yet fully integrated with
the deletion log (ie, links to undelete perhaps should appear next to
deletion notices, and restorations should definitely be listed in the
same log), and I probably haven't tested it as thoroughly as I ought to
It is to be considered experimental, so please be gentle with it. If Lee
wants to set it up on the piclab server, less gentle testing is I'm sure
welcome there. :) I'd offer my own test server, but it's currently
behind a modem (wah!)
(File is in CVS.)
-- brion vibber (brion @ pobox.com)
>> I have found a problem with the Wikipedia entries on Outlook: If one tries
>> to get a Wikipedia page with a name that is made of more than one words, it
>> tries to get the page with spaces instead of underscores. Could that be
>Sorry, 'Outlook' should be 'OneLook' of course...
I tested it out, and it's still resulting in the right address ... are there times when it doesn't?
The Cunctator wrote:
>I didn't say that was a good option. But let me ask you; why do you
>ignore the explicit policy?
The policy I follow is the "de facto" policy. These are mostly based on
the policy on the pages, but if I see that it is common use to do
something slightly different (and by common I mean it is done by other
sysops), I'll accept it as "de facto" policy. I do occasionally check
for changes on the policy pages, but when these seem to be made by
individuals rather than by consensus or majority vote, I take the same
liberty as the person that singlehandedly updated the policy and ignore it.
>No. Direct editing should be the first choice; not the only choice. And
>you're confusing two different threads here; I was adding to Engels'
>list, not delineating my own conception.
OK, from your previous mails it appeared your opinion was that direct
editing was (in your eyes) the only choice - but that's apparently not
what you meant.
>There is an equivalent to the NPOV, and that is consensus. Your belief
>that changing policy to your personal opinion would automatically mess
>things up is based on flawed reasoning.
How exactly do we reach consensus by just editing policy pages right away?
Warning: open(/tmp/sess_9ecc625f94c1103cbc8e9fed033dd472, O_RDWR) failed: Too many open files in system (23) in /usr/local/apache/ htdocs/w/wiki.phtml on line 7
Warning: Failed opening 'Setup.php' for inclusion (include_path='.:/usr/local/lib/php') in /usr/local/apache/htdocs/w/wiki.phtml on line 12
Fatal error: Undefined class name 'outputpage' in /usr/local/apache/htdocs/w/wiki.phtml on line 14
Warning: open(/tmp/sess_9ecc625f94c1103cbc8e9fed033dd472, O_RDWR) failed: Too many open files in system (23) in Unknown on line 0
Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0