headers
Neil Harris | 1 Dec 2008 03:16
Picon

Re: EN Wikipedia Editing Statistics

Thomas Dalton wrote:
>>> Not to years but yes the English Wikipedia dumps very rarely work.
>>> De.wikipedia is starting to suffer the same issues and image database
>>> dumps don't happen.
>>>       
>> No, I think it really has been two years (September 2006 to be
>> precise).  I'm pretty sure there have been no complete dumps this
>> calendar year.  I believe there was one (or two?) full dump process
>> that claimed to run to completion in 2007 but it was later found to
>> have been truncated (i.e. it didn't really dump all of enwiki, only a
>> portion of it).
>>
>> If I am wrong and there really is a more recent complete history dump
>> of enwiki floating around somewhere, then I'd love to hear about it,
>> but I don't believe that is the case.
>>     
>
> That sounds about right to me. I think the confusion may come from
> there being lots of different dumps - the smaller dumps of enwiki do
> succeed (occasionally, at least!), it's the full dump of every
> revision of every page that fails routinely.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@...
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
reporter | 1 Dec 2008 04:00
Picon

Bugzilla Weekly Report

MediaWiki Bugzilla Report for November 24, 2008 - December 01, 2008

Status changes this week

Bugs NEW               :  93                                  
Bugs ASSIGNED          :  4                                   
Bugs REOPENED          :  10                                  
Bugs RESOLVED          :  45                                  

Total bugs still open: 3168                                

Resolutions for the week:

Bugs marked FIXED      :  31                                  
Bugs marked REMIND     :  0                                   
Bugs marked INVALID    :  5                                   
Bugs marked DUPLICATE  :  3                                   
Bugs marked WONTFIX    :  2                                   
Bugs marked WORKSFORME :  3                                   
Bugs marked LATER      :  1                                   
Bugs marked MOVED      :  0                                   

Specific Product/Component Resolutions & User Metrics 

New Bugs Per Component

General/Unknown                     6                                   
Site requests                       6                                   
General/Unknown                     3                                   
Templates                           3
(Continue reading)

Permalink | Reply | 0 comments |
headers
Siebrand Mazeland | 1 Dec 2008 09:09
Picon
Picon
Favicon
Gravatar

FW: [FOSDEM] Your devroom request has not been accepted

FYI.

This is too bad. It would have been a great opportunity for our project to
go forward by bringing a substantial number of developers together in the
official part of FOSDEM 2009.

On the other hand: I and a few others will definitely be going to FOSDEM
2009[1]. Is it worth exploring possibilities to have some kind of thing in
Brussels in the same weekend, should we try and organise something
completely different as soon as possible, or should we cancel the idea for
the next 6 months altogether?

Cheers! Siebrand

[1] http://www.mediawiki.org/wiki/Project:FOSDEM_2009

-----Oorspronkelijk bericht-----
Van: Pascal Bleser [mailto:loki@...] 
Verzonden: maandag 1 december 2008 1:37
Aan: Siebrand Mazeland
CC: FOSDEM DevRooms
Onderwerp: [FOSDEM] Your devroom request has not been accepted

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

We're sorry to give you bad news, but your developer room request for FOSDEM
2009 has not been accepted.

We realize that this must be disappointing news, but unfortunately we don't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Aronsson | 1 Dec 2008 10:29
Picon
Favicon

Stub quota


After some more thought on the origins of stub articles and a 
better overview of the contents of the Swedish Wikipedia, it is 
clear that very few individuals are responsible for creating large 
numbers of stubs, a few years back.  Now, depending on religion 
(mergists, deletionists...), these should either be deleted, 
improved, merged or put on lists of necessary quality 
improvements. Either way, it's a lot of work and it would have 
been better to have stopped those invidiuals back then.  At least 
we want to stop such individuals today, so the same mistake isn't 
repeated while the old mess is being cleaned up.

What we want is to foster a spirit of writing better articles, 
improving the one you started, before you start the next one.

But instead of increased patrolling and speedy deletions, this 
could be implemented in the Mediawiki software.  If a user (logged 
in or IP address) tries to create a new page, their recent 
contribution history could be checked, and if any of their five 
most recently created articles (except redirects) are shorter 
than, say, 300 bytes, they would simply be unable to create 
another article.  This would be a very soft kind of blocking (as 
soon as you have improved your existing article, you can start the 
next one), each case being completely an affair between the user 
and the software, not involving opinions of individual admins.

Such an extension (is there an "article creation hook"?) could be 
fully parameterized, so each community could decide where to set 
the limits (5 recently created articles, 300 bytes), and what 
message to show to the user who violates these limits.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Neil Harris | 1 Dec 2008 12:18
Picon

Re: EN Wikipedia Editing Statistics

Robert Rohde wrote:
> On Sun, Nov 30, 2008 at 10:29 PM, Nikola Smolenski <smolensk@...> wrote:
>   
>> On Monday 01 December 2008 04:09:11 Robert Rohde wrote:
>>     
>>> On Sun, Nov 30, 2008 at 6:16 PM, Neil Harris <usenet@...>
>>>       
>> wrote:
>>     
>>>> Is the data replicated anywhere outside the Tampa data centre (such as
>>>> in Amsterdam or Seoul)? If not, just one fire, flood or hurricane could
>>>> destroy the entire en: Wikipedia.
>>>>         
>>> There are database mirrors of every wiki, including en, as part of the
>>> toolserver cluster in Amsterdam.
>>>       
>> Unfortunately, enwiki mirror doesn't include article text :(
>>     
>
> Ouch, I hadn't realized they gave up on text replication.  Apparently
> quite a while ago too.  (That will teach me for never bothering to
> learn to use the toolserver.)
>
> So I guess we are back to the meteor impact destroys Wikipedia scenario.
>
> -Robert Rohde
>   
That's scary: are there any off-site backups of the full database, 
including the article text, made anywhere, other than the constantly 
failing dumps? Given that Wikipedia is the Wikimedia Foundation's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Kinzler | 1 Dec 2008 12:48
Picon
Favicon
Gravatar

Re: [Foundation-l] EN Wikipedia Editing Statistics

> That's scary: are there any off-site backups of the full database, 
> including the article text, made anywhere, other than the constantly 
> failing dumps? Given that Wikipedia is the Wikimedia Foundation's 
> principal asset, I would hope that fixing this single point of failure 
> would be a priority for the Foundation.

Yes, all databases are replicated to another cluster located in amsterdam.

But you are right: the situation does suck. We got the new hardware to get
working dumps again now, we just have to sit tight and hope this fresh dump of
enwiki works. If it does, things should go smothly again.

-- daniel
Permalink | Reply | 1 comment |
headers
Aryeh Gregor | 1 Dec 2008 15:47
Picon

Re: Stub quota

On Mon, Dec 1, 2008 at 4:29 AM, Lars Aronsson <lars@...> wrote:
> After some more thought on the origins of stub articles and a
> better overview of the contents of the Swedish Wikipedia, it is
> clear that very few individuals are responsible for creating large
> numbers of stubs, a few years back.  Now, depending on religion
> (mergists, deletionists...), these should either be deleted,
> improved, merged or put on lists of necessary quality
> improvements. Either way, it's a lot of work and it would have
> been better to have stopped those invidiuals back then.  At least
> we want to stop such individuals today, so the same mistake isn't
> repeated while the old mess is being cleaned up.

That depends on your point of view.  An inclusionist might well say
that they should be kept and improved, but that in the meantime,
better to have the stubs than not.  After all, that might encourage
people to improve them more than having nothing at all; it allows them
to be categorized so that people interested in the subject can go
through the stubs in their specialty systematically; a couple of
sentences can sometimes be useful; etc.  That would be my personal
position, in fact.

> But instead of increased patrolling and speedy deletions, this
> could be implemented in the Mediawiki software.  If a user (logged
> in or IP address) tries to create a new page, their recent
> contribution history could be checked, and if any of their five
> most recently created articles (except redirects) are shorter
> than, say, 300 bytes, they would simply be unable to create
> another article.  This would be a very soft kind of blocking (as
> soon as you have improved your existing article, you can start the
> next one), each case being completely an affair between the user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bence Damokos | 1 Dec 2008 15:58
Picon

Re: Stub quota

On the Hungarian Wikipedia we have implemented a community solution for
this:articles that do not contain a minimum number of facts (let's say a
minimum of 10 pieces of information on the subject) get tagged as
"sub-stubs" and after 7 days if there is no improvement, they are deleted.

Best regards,
Bence Damokos

On Mon, Dec 1, 2008 at 10:29 AM, Lars Aronsson <lars@...> wrote:

>
> After some more thought on the origins of stub articles and a
> better overview of the contents of the Swedish Wikipedia, it is
> clear that very few individuals are responsible for creating large
> numbers of stubs, a few years back.  Now, depending on religion
> (mergists, deletionists...), these should either be deleted,
> improved, merged or put on lists of necessary quality
> improvements. Either way, it's a lot of work and it would have
> been better to have stopped those invidiuals back then.  At least
> we want to stop such individuals today, so the same mistake isn't
> repeated while the old mess is being cleaned up.
>
> What we want is to foster a spirit of writing better articles,
> improving the one you started, before you start the next one.
>
> But instead of increased patrolling and speedy deletions, this
> could be implemented in the Mediawiki software.  If a user (logged
> in or IP address) tries to create a new page, their recent
> contribution history could be checked, and if any of their five
> most recently created articles (except redirects) are shorter
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Dalton | 1 Dec 2008 16:39
Picon

Re: Stub quota

> But instead of increased patrolling and speedy deletions, this
> could be implemented in the Mediawiki software.  If a user (logged
> in or IP address) tries to create a new page, their recent
> contribution history could be checked, and if any of their five
> most recently created articles (except redirects) are shorter
> than, say, 300 bytes, they would simply be unable to create
> another article.  This would be a very soft kind of blocking (as
> soon as you have improved your existing article, you can start the
> next one), each case being completely an affair between the user
> and the software, not involving opinions of individual admins.
>
> Such an extension (is there an "article creation hook"?) could be
> fully parameterized, so each community could decide where to set
> the limits (5 recently created articles, 300 bytes), and what
> message to show to the user who violates these limits.
>
> Has this been suggested before?  Has it been implemented?  Would
> it be a really bad idea to suggest this?

I can't see any reason why it couldn't be implemented (I don't know
how easy it would be). Before anyone actually spends time coding it,
though, is there a consensus on the Swedish Wikipedia to use such a
system or is it just your idea? If it's the latter, then you should
probably establish a consensus first (since I'm not sure other
projects would use the extension, it's not really worth writing if you
aren't going to use it).
Permalink | Reply | 0 comments |
headers
Andre Engels | 1 Dec 2008 17:11
Picon

Re: Stub quota

On Mon, Dec 1, 2008 at 10:29 AM, Lars Aronsson <lars <at> aronsson.se> wrote:

> But instead of increased patrolling and speedy deletions, this
> could be implemented in the Mediawiki software.  If a user (logged
> in or IP address) tries to create a new page, their recent
> contribution history could be checked, and if any of their five
> most recently created articles (except redirects) are shorter
> than, say, 300 bytes, they would simply be unable to create
> another article.  This would be a very soft kind of blocking (as
> soon as you have improved your existing article, you can start the
> next one), each case being completely an affair between the user
> and the software, not involving opinions of individual admins.

Sounds like a bad idea. If the community doesn't want these stubs, the
better way to act would be to create an easy method to get these pages
deleted. A system such as you propose would punish people who make
short pages for perfectly good reasons (like disambiguation pages),
and would likely be subverted using lengthenings that make the article
worse rather than better (like subst-ing rather than including
complicated templates).

--

-- 
André Engels, andreengels <at> gmail.com
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Permalink | Reply | 0 comments |

Gmane