Right now our coding conventions manual never touches on method chaining,
nor have I personally seen this practice in core. So I'm interested in what
the rest of the community feels about adapting this practice more, and if
there are trade offs I'm not aware of. Let's make an example, take this
code from Abuse Filter:
$out = $this->getOutput();
$out->setPageTitle( wfMsg( 'abusefilter-examine' ) );
$out->addWikiMsg( 'abusefilter-examine-intro' );
So, instead of writing it like that, it could be written
$this->getOutput()
->setPageTitle( wfMsg( 'abusefilter-examine' ) )
->addWikiMsg( 'abusefilter-examine-intro' );
It's just another style I've encountered on other projects and I personally
like.
--
John Du Hart
Forwarding...
---------- Forwarded message ----------
From: emijrp <emijrp(a)gmail.com>
Date: 2011/11/11
Subject: Old English Wikipedia image dump from 2005
To: wikiteam-discuss(a)googlegroups.com
Hi all;
I want to share with you this Archive Team link[1]. It is an old English
Wikipedia image dump from 2005. One of the last ones, probably, before
Wikimedia Foundation stopped publishing image dumps. Enjoy.
Regards,
emijrp
[1] http://www.archive.org/details/wikimedia-image-dump-2005-11
I think we finally have a complete copy from December 2007 through
August 2011 of the pageview stats scrounged from various sources, now
available on our dumps server.
See http://dumps.wikimedia.org/other/pagecounts-raw/
Ariel
Hi,
I think developer accounts on the Wikimedia SVN repository should be
easier to get. I say this because a consultant of ours at WikiWorks,
Ike Hecht, asked for a developer account last week and was rejected.
He created his first major MediaWiki extension, Ad Manager, recently,
which I added to the repository a few weeks ago - you can see it here:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/AdManager/
When he requested access, this was the relevant part of the response
from Sumana:
"Right now, we are not approving your request for commit access. I'm
sorry. We'd like for you to get more practice writing code for
MediaWiki, submit patches for review via Bugzilla attachments, and ask
us for comments... Please come back and request access again in a few
months."
I don't know whether this is WMF policy now, or a personal decision
from Sumana, or a decision made by someone else, but in any case I
don't understand it. It seems to me that there are two valid reasons
for not simply allowing everyone to get a developer account: the
first, and major, reason is to prevent malicious users from
vandalizing or deleting code. The second is to prevent
well-intentioned but incompetent developers from checking in buggy
and/or badly-written code that requires lots of fixes and review time
by the reviewers. In both cases, the person's presence in SVN would
cause more harm than good.
Neither of those cases apply here - the Ad Manager code was
well-written, and it works. If you're curious, you can see for
yourself the kinds of fixes and changes that were made to the code
after it was checked in - all minor stuff, the only major thing being
that the extension originally included support for MediaWiki 1.15,
which people thought was unnecessary. Clearly a higher bar is being
applied here than what's spelled out in the mediawiki.org
documentation - which only says that "we don't have time to train
programmers from scratch":
http://www.mediawiki.org/wiki/Commit_access#Prerequisites
Note, by the way, that if there's a more stringent policy in place
now, it's not being applied consistently, because the students in this
year's Google Summer of Code got developer access after much less
proof of programming ability.
It seems to me that if someone writes an extension that basically
matches the MediaWiki guidelines, works, and does something useful,
they should pretty much be granted automatic access to an account,
because they will have proved that their presence will be a net
positive overall. Any thoughts on this?
And out of curiosity - is there a new policy in place?
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
Just granted extensions access to Remco de Boer as remco (User:Rcdeboer
on mediawiki.org) to work on various extensions, especially those in the
semantic bundle.
Welcome!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
What: Weekly Patch Review
When: Wednesday, Nov 16, 2130UTC
Time zone conversion: http://hexm.de/a6
Where: #wikimedia-dev on freenode
Use http://webchat.freenode.net/?channels=wikimedia-dev
if you don't have an IRC client
To keep the patch queue down to a reasonable level, I'm going to start
weekly patch review session. The first one of these will be tomorrow
and, if everything goes well, we'll probably end up doing this weekly.
What: UploadWizard Triage
When: Thursday, Nov 17, 2130UTC
Time zone conversion: http://hexm.de/a7
Where: #wikimedia-dev on freenode
Use http://webchat.freenode.net/?channels=wikimedia-dev
if you don't have an IRC client
Sumana and I were discussing what to focus the triage on this week and,
after a bit of poking at Bugzilla, we decided that UploadWizard would
make a good candidate.
Hope to see you at one or both of these!
Mark.
A few months ago I opened a bug asking for en-CA support in MediaWiki:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31016
For reference en-CA is neither strictly en-US or en-GB. en-CA uses some
spellings en-GB use and in other cases some spellings that en-US use, and
there are a slight few en-CA specifics as well.
Examples of the differences: en-CA and en-GB uses 'colour' while en-US
uses 'color'; en-CA and en-US use 'Uncategorized' while en-GB may use
'Uncategorised'; en-US and en-CA use 'program' while en-GB use
'programme'; And I believe the CA/GB/AU grammar idiom where 'the' may end
up omitted on some cases applies to 'in process of' instead of en-US' 'in
the process of'.
Extension wise; We use "Expiry date" rather than "Expiration date", I'm
not sure what en-GB uses other than "Use by" but "Expiry" seams to be
en-CA specific.
Moving on.
That bug was closed as INVALID and I was told I could start translating
the language at translatewiki.
I signed up at TWN and asked for translation permissions. A day or so
later I got them and started translating en-CA.
After finishing translating en-CA for MediaWiki and being halted part way
through translating extensions after realizing that one extension had
several hundred messages that were almost entirely the same and I had to
translate a single word in all of them... Siebrand deleted every en-CA
translation from TWN with the comment "en-ca not needed in MediaWiki".
https://translatewiki.net/w/i.php?title=Special%3ALog&type=delete&user=SieB…
I've poked Siebrand about en-CA on his talkpage, and several times in irc
when he's recently been active. But it seams he's simply ignoring what I
say about en-CA.
I would like to get en-CA support into MediaWiki though it looks like
that's been shot dead in the water.
I'm noticing a related trend lately in regards to TWN:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31229https://bugzilla.wikimedia.org/show_bug.cgi?id=32264
Whenever someone reports a bug asking for a translation change, we seem to
mark it as INVALID, and then tell the reporter to go to translatewiki, go
through the process of getting translator permission, and then translate
it themselves.
To me that's like marking a bug with a patch as INVALID and saying that
the reporter should get svn commit access and commit it themselves
Rather than closing bugs as INVALID and shoving off people reporting bugs
to another site IMHO when we see a translation bug we should try to fix it
inside the translation, mark the bug as FIXED, and remind the reporter
that if they have more translations to be fixed they should sign up at TWN
and help out with the translations.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
I have to say that I have the same expirance with the current process for
requesting commit access.
I currently have access to SVN, it was given to me 2 years ago by
TimStarling. But i changed my key(s) but it didn't change for Wikimedia. So
I requested Sumana to close my old account and give me a new account with a
better name.
This was her responds:
Hi Huib,
I apologize for the late response. After some discussion, we decided that
the best
way to proceed is for you to submit your proposed improvements as a patch in
bugzilla.wikimedia.org, or make your extension public on mediawiki.org
(http://www.mediawiki.org/wiki/Category:Extensions). This gives us a much
better
idea of what your proposal is and makes it a lot easier to review.
Sincerely,
Priyanka Dhanda
So I was already given access, but by error I lost the key and now got
removed.
I don't really think the current proces is helping to get more volunteers...
Best,
Huib Laurens
2011/11/5 Neil Kandalgaonkar <neilk(a)wikimedia.org>
> Olivier, I'm truly sorry you had such a negative experience. This is not
> an acceptable situation. We have an inconsistent process, and one which
> is a bit heavyweight when our resourcing for it is rather lightweight.
>
> I wish you had found the patience to assume good faith. There is no
> reason for accusations that we don't want good developers. Of course we
> *want* them. If we are failing to act like it, it wasn't a personal slam
> at you.
>
> And, if I may be forgiven for white-knighting, Sumana's job is to needle
> the rest of us so we don't forget about concerns like yours and she
> generally does it very well. And she did sound an apologetic note into
> the email she sent you. So IMO she's not the problem here. Why she
> played a game of telephone here is a bit of a mystery to me though --
> maybe she just wanted to be sure that *someone* pinged you since it had
> been so long. IMO the developer who reviewed your code should have
> contacted you directly.
>
> I had a look at the module you wrote. I share some of the same concerns
> about scalability, but that's not really the issue.
>
> I have some experience with user-contributed module archives, having
> administered some shared community resources for Perl, Python, and so
> on. The cultural differences and relative successes were interesting.
> The Python people wanted to have a review process, and a GUI interface,
> and binary modules precompiled, and so on and so on, and their projects
> never really got off the ground. Perl's CPAN started off as a simple FTP
> site where almost anyone could upload code. Guess which one ultimately
> succeeded. The point is, IMO there's relatively little payoff for having
> *any* review process for modules. Just have a way to report and remove
> malware and be done with it. As long as it's clear that the Foundation
> doesn't endorse the software there, what is the problem? Maybe we can
> also have some kind of badge for "reviewed" or "as seen on Wikipedia"
> for the stuff we consider good enough to deploy on big sites.
>
> We already more or less do this -- for instance, there are modules by
> GSoC students that are clearly not ready for prime time, and they are
> marked accordingly.
>
>
>
> On 11/4/11 11:47 PM, MZMcBride wrote:
>
> > The long and short of my advice is this: fuck MediaWiki. If they're
> > unwilling to accept your contributions, there are a lot of other FOSS
> > projects that would be happy to have you. Thrilled to have you, even. I'd
> > strongly encourage finding one. :-)
>
> And why should he listen to you, when you are unwilling to follow your
> own advice?
>
> --
> Neil Kandalgaonkar |) <neilk(a)wikimedia.org>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
Kind regards,
Huib Laurens
WickedWay.nl
Webhosting the wicked way.
Sorry I don't understand, a lot of people are complaining about their distro not shipping "late" version, not latest...
I perfectly understand, i've a server with a CentOs frozen in time somewhere in 2007... and I'm SCARED to touch anything... It run and old version of mysql, kernel 2.18.something, old Perl... but it runs... and does the job without any problems... In short I will never think to install nothing except a munin plugin...
The point is: are you using an extra stable distro, with extra tested software and do you want to INSTALL a bleeding edge ?
--
Roy Bellingan
admin(a)tsmt.eu
CG & ArchiVIZ *http://archidea.us*
Programmazione & SysAdmin *http://tsmt.eu*