headers
Happy-melon | 1 Apr 2011 02:37

Re: Bugzilla upgrade on April 1st at 17:00 GMT


"Priyanka Dhanda" <pdhanda <at> wikimedia.org> wrote in message 
news:4D94C498.7050606 <at> wikimedia.org...
> Hello,
>
> bugzilla.wikimedia.org is scheduled to be upgraded to version 4.0

\O/

> on April 1st ...

Wait a minute...

> If you see any problems after the upgrade, please report them using
> https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia and use
> the component Bugzilla.

And if that problem is "can't submit any bug which has 'bugzilla' in the 
title"?   :-P   That would make an awesome April Fool's joke... :-D

--HM
Permalink | Reply | 0 comments |
headers
Max Semenik | 1 Apr 2011 13:19
Picon
Gravatar

Re: GSoC 2011 proposal

On 01.04.2011, 2:00 Sumana wrote:

> Since very few people can see the formal proposal, there is a copy to 
> view at:

> http://www.mediawiki.org/wiki/User:Zhenya

I'm not registered as a mentor or anything, but I can see his
proposal nevertheless.

--

-- 
Best regards,
  Max Semenik ([[User:MaxSem]])
Permalink | Reply | 0 comments |
headers
Arthur Richards | 1 Apr 2011 22:56
Picon
Gravatar

want to work on a GSoC project with massive reach and impact?

Still trying to figure out what GSoC project to work on with the 
Wikimedia Foundation?  Want to work on something that will make a 
profound impact, reaching people all over the world - both online AND 
offline?

The Wikimedia offline [0] team is looking for a developer passionate 
about leveraging Wikipedia and it sister projects for social good.  We 
are looking for someone to port the WP 1.0 Bot [1] to a Mediawiki 
extension and expand its feature set.  The WP 1.0 Bot is a critical tool 
in the offline content creation tool chain.  It simplifies the processes 
of building collections of articles to be used offline while also 
facilitating article quality assessment.

It's already being used to create offline versions of Wikipedia, but 
communities all around the world have been asking for ways to build 
their own offline collections of articles for use [2] in places where 
access to to the same breadth and depth of knowledge as Wikipedia is not 
available.  Think: schools that do not or cannot have access to the 
internet [3]; places where access to the web and certain types of 
knowledge is restricted; or even just having the freedom to look up 
Wikipedia articles without needing to be connected to the 'net.

The current tool lives on the Toolserver as a collection of Perl scripts 
[4].  They require some degree of manual intervention at the code level 
in order to run, are only primarily useful for en.wikipedia and 
currently do not provide an easy way to manage article selections.  We 
want to port the tool to a Mediawiki extension and expand its feature 
set so that it can be used by any of the wiki projects, make the process 
of building article collections more accessible, be easy to translate 
(via translatewiki.net) and have greater visibility/maintainability of
(Continue reading)

Permalink | Reply | 0 comments |
headers
MZMcBride | 2 Apr 2011 01:51

Re: Focus on sister projects

Ryan Kaldari wrote:
> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
> clean-up on a few wikis, but I usually just get chewed out by the local
> admins for not discussing every change in detail (which obviously
> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
> to address this problem.

This caught my eye as Wikimedia has far more than 200 wikis. There seems to
be a shift happening within the Wikimedia Foundation. The sister projects
have routinely been ignored in the past, but things seem to be going further
lately....

Personally, I'm in favor of disbanding all of the projects that Wikimedia
has no intention of actively supporting in the near-future or even mid-range
future. I think the current situation in which certain sister projects are
supported in name only is unacceptable to the users and to the public.

MZMcBride
Permalink | Reply | 23 comments |
headers
jidanni | 2 Apr 2011 02:00
Favicon
Gravatar

svn: Failed to add directory 'config': an unversioned directory of the same name already exists

Dear fellow SVN users, if you encounter
$ svn update
...
svn: Failed to add directory 'config': an unversioned directory of the same name already exists
Then you had better move that directory and all its contents elsewhere,
and do "svn update" again, to avoid a half updated wiki.
Permalink | Reply | 0 comments |
headers
Ryan Kaldari | 2 Apr 2011 02:11
Picon

Re: Focus on sister projects

Can you possibly get any more hyperbolic? For your information, I've 
been trying to clean up the Javascript of en.wiktionary.org this past 
week, which is a total nightmare (and it's a sister project!). If you'd 
like to help, feel free to join the discussions:
http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js
http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library

Ryan Kaldari

On 4/1/11 4:51 PM, MZMcBride wrote:
> Ryan Kaldari wrote:
>> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
>> clean-up on a few wikis, but I usually just get chewed out by the local
>> admins for not discussing every change in detail (which obviously
>> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
>> to address this problem.
> This caught my eye as Wikimedia has far more than 200 wikis. There seems to
> be a shift happening within the Wikimedia Foundation. The sister projects
> have routinely been ignored in the past, but things seem to be going further
> lately....
>
> Personally, I'm in favor of disbanding all of the projects that Wikimedia
> has no intention of actively supporting in the near-future or even mid-range
> future. I think the current situation in which certain sister projects are
> supported in name only is unacceptable to the users and to the public.
>
> MZMcBride
>
>
>
(Continue reading)

Permalink | Reply | 11 comments |
headers
Happy-melon | 2 Apr 2011 02:24

Re: Focus on sister projects


"MZMcBride" <z <at> mzmcbride.com> wrote in message 
news:C9BBCF19.1056A%z <at> mzmcbride.com...
> Ryan Kaldari wrote:
>> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
>> clean-up on a few wikis, but I usually just get chewed out by the local
>> admins for not discussing every change in detail (which obviously
>> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
>> to address this problem.
>
> This caught my eye as Wikimedia has far more than 200 wikis. There seems 
> to
> be a shift happening within the Wikimedia Foundation. The sister projects
> have routinely been ignored in the past, but things seem to be going 
> further
> lately....
>
> Personally, I'm in favor of disbanding all of the projects that Wikimedia
> has no intention of actively supporting in the near-future or even 
> mid-range
> future. I think the current situation in which certain sister projects are
> supported in name only is unacceptable to the users and to the public.
>
> MZMcBride

I would be very interested to hear what criterion you would use to separate 
out a group of 200 (or any number other than zero, one or all [1]) wikis 
which are "maintained" from the rest which are "unmaintained"; where the 
distinction in quality of service, the ratio of Foundation resources to 
userbase or readership, or any other meaningful statistic, showed any
(Continue reading)

Permalink | Reply | 1 comment |
headers
Conrad Irwin | 2 Apr 2011 02:53
Picon
Gravatar

Re: Focus on sister projects

Ryan — what is your goal with the cleanup? Part of the reason I think
you're getting nowhere on Wiktionary is that as far as anyone there
can tell you're just changing stuff for the fun of changing stuff (and
breaking it in the process...). If you can tell us what you're trying
to achieve, then (given that we wrote the code, and have a reasonably
good idea of how it's used), we can probably help you.

Conrad

On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldari <rkaldari <at> wikimedia.org> wrote:
> Can you possibly get any more hyperbolic? For your information, I've
> been trying to clean up the Javascript of en.wiktionary.org this past
> week, which is a total nightmare (and it's a sister project!). If you'd
> like to help, feel free to join the discussions:
> http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js
> http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library
>
> Ryan Kaldari
>
> On 4/1/11 4:51 PM, MZMcBride wrote:
>> Ryan Kaldari wrote:
>>> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing
>>> clean-up on a few wikis, but I usually just get chewed out by the local
>>> admins for not discussing every change in detail (which obviously
>>> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how
>>> to address this problem.
>> This caught my eye as Wikimedia has far more than 200 wikis. There seems to
>> be a shift happening within the Wikimedia Foundation. The sister projects
>> have routinely been ignored in the past, but things seem to be going further
>> lately....
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ryan Kaldari | 2 Apr 2011 03:40
Picon

Re: Focus on sister projects

Good idea. After the 1.17 deployment, I've been trying to go through and 
clean-up some of the Javascript cruft that has built up on the various 
wikis over the years. One of the main goals of 1.17 was improving page 
loading speeds by optimizing Javascript delivery. Of course if all the 
wikis are serving lots of old redundant Javascript, the optimization 
doesn't accomplish that much. On wiktionary specifically, the 
importScript and importExternalScript functions are redundant, and the 
Wiktionary:PREFS system should be retired now that Gadgets are 
available. I admit I was much too gung-ho in my clean-up regarding 
Wiktionary, and I intend to let the admins there handle it from here.

As long as we're on the subject of wiktionary, I notice that there's a 
lot of custom Javascript there for handling specialized editing tasks 
like editing glosses, managing translations, etc. It seems like some of 
this functionality could be improved further and developed into 
full-fledged extensions (making it easy for other wiktionaries to use as 
well). Would you have any interest in working up a couple Wiktionary 
project proposals for the upcoming Hackathon in Berlin?

Ryan Kaldari

On 4/1/11 5:53 PM, Conrad Irwin wrote:
> Ryan — what is your goal with the cleanup? Part of the reason I think
> you're getting nowhere on Wiktionary is that as far as anyone there
> can tell you're just changing stuff for the fun of changing stuff (and
> breaking it in the process...). If you can tell us what you're trying
> to achieve, then (given that we wrote the code, and have a reasonably
> good idea of how it's used), we can probably help you.
>
> Conrad
(Continue reading)

Permalink | Reply | 7 comments |
headers
Conrad Irwin | 2 Apr 2011 04:11
Picon
Gravatar

Re: Focus on sister projects

Ok — yes loading speeds are definitely something worth improving.

WT:PREFS to become gadgets has been discussed ever since gadgets was
released, it will happen one day :). Luckily that code is only loaded
for people who are using WT:PREFS, so it should have minimal impact.

I'd be pretty interested to — do you have a guideline as to the
expected format. In particular I think the "core" of the editor, which
provides a framework for javascript to load, edit, undo, redo, and
save the page (with edit summaries) would be pretty useful everywhere.
It's documented in the first half of
http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and
there's a tutorial at
http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js —
but it could do with "new-ification" (in particular some jQuery would
be nice, and there's probably a better javascript API wrapper than
JsMwApi :).

Conrad

On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari <rkaldari <at> wikimedia.org> wrote:
> Good idea. After the 1.17 deployment, I've been trying to go through and
> clean-up some of the Javascript cruft that has built up on the various wikis
> over the years. One of the main goals of 1.17 was improving page loading
> speeds by optimizing Javascript delivery. Of course if all the wikis are
> serving lots of old redundant Javascript, the optimization doesn't
> accomplish that much. On wiktionary specifically, the importScript and
> importExternalScript functions are redundant, and the Wiktionary:PREFS
> system should be retired now that Gadgets are available. I admit I was much
> too gung-ho in my clean-up regarding Wiktionary, and I intend to let the
(Continue reading)

Permalink | Reply | 6 comments |

Gmane