Greetings,
I wanted to share with folks two new WikiProjects we're trying out on MW.org. I recognize that this is not a preferred method of organizing for some developers - but the hope is to reach the group of volunteers who are visiting the website and looking for ways to help. WikiProjects follows a model used successfully on Wikipedia that Wikimedians new to MW.org may recognize and feel more comfortable with than say mailing lists or IRC rooms - which I've heard multiple times from folks seem "intimidating". Not an opinion I share, but I recognize ignoring it or dismissing it doesn't help us grow volunteer efforts. :)
Constructive feedback is always welcome and any folks interested in updates or supporting these efforts is welcome to sign the participants list. The hope is to develop the base work and infrastructure over the coming weeks and begin recruiting participants and putting the model to use in 2012. Specifically helping organize folks with particular interests in MW documentation, perhaps helping organize GIT transfers/training for extension developers, prepare folks for MW1.19 and future releases, etc.
Specifically, these two WikiProjects hope to organize folks working on third-party extensions and third-party sysadmins. Folks with ideas on how to help those groups, but not necessarily the time to tackle the idea alone (or maybe at all) are encouraged to share their "utopian" ideas. :) There has also been discussions about one or two more wikiprojects to help the Enterprise Wiki community and possibly the academic field.
http://www.mediawiki.org/wiki/Project:WikiProject_SysAdminshttp://www.mediawiki.org/wiki/Project:WikiProject_Extensions
Also looking for developers and staff types interested in helping with a "town hall" to assist third-party developers prepare for any changes coming in MW1.19.
-greg aka varnent
PS. If these are put to use, I plan on updating the design to be more mobile device friendly. The WikiProjects can also evolve to suit the needs of MW.org - so feedback on ways to make these more MW.org specific and less enWP-like are welcome as well. ;)
PPS. Thank you to Sumana for morale support on this experiment.
-------
Gregory Varnum
Lead, Aequalitas Project
Lead Administrator, WikiQueer
Founding Principal, VarnEnt
@GregVarnum
fb.com/GregVarnum
Harry Burt (jarry1250) now has extensions access in order to commit his
extension TranslateSvg and towards the goal of getting it internationalized.
Welcome, Harry!
Aaron Schulz, when reviewing Harry's many past patches, noted that he's
given us "Lots of useful code contributions" but also suggests, "that
SVG extension should really be a core change." :-)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
After the Platform Engineering meeting yesterday, I've added a couple of
queries to the sidebar in Bugzilla for users in the "editbugs" group.
The first is "Day old patches" and should return a list of patches from
the last 24 hours.
The second is "WMF Materials highest priority". This works by checking
only a selected list of Products and Components in Bugzilla and
returning only the highest priority bugs in that list. It is limited in
that it is a whitelist, and may miss some products and categories. I
hope you'll point out any problems you find with it to me.
Of course, you can remove either or both of these queries from your
sidebar: just uncheck the box under your preferences' "Saved Searches"
tab. Or use this URL:
<https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches>
Hopefully, these queries will help provide us with some tools to get
issues resolved and (till the magical world of git) integrate
contributed code.
Let me know your thoughts,
Mark.
Friends.
Tamil Wikipedia announced a Media Contest to increase the commons
media files like photos, audio and video in the wikipedia world.
see the announcement here.
http://ta.wikipedia.org/wiki/Contest/en
To upload the photos there are two ways available so far.
1. The web based upload wizard
http://commons.wikimedia.org/wiki/Special:UploadWizard
2. Java based upload tool - Commonist
http://commons.wikimedia.org/wiki/Commons:Tools/Commonist
We have to provide a detailed filename and description to the images
for uploading.
When we have a bunch of photos to upload, we have to select them,
crop, or edit them before uploading.
Found that that "GThumb Image Viewer" can show the files, edit the
files and add IPTC tags to the images.
We can view,edit,delete,rotate,crop and add the required Description
and Title to the images
for uploading to wikimedia commons.
How to upload the files?
There are two tools already.
But, I wanted to plugin to any image viewer to upload to wikimedia
commons directly.
No image viewer has that plugin.
DigiKam has it, but due to some issues, the mediawiki plugin is not released.
So, I started to write my own script for uploading all the files in a
folder to upload to mediawiki.
Here is it.
http://code.google.com/p/mediawiki-uploader/
Usage details are available in INSTALL and README files.
Thanks for the wikipedia users Surya and Sodabottle for their valuable
suggestions.
Please report if there are any issues.
Provide your suggestions for improving too.
Thanks.
--
Regards,
T.Shrinivasan
My Life with GNU/Linux : http://goinggnu.wordpress.com
Free/Open Source Jobs : http://fossjobs.in
Get CollabNet Subversion Edge : http://www.collab.net/svnedge
Here's the demo, where you can edit some canned texts (but not actual
Wikipedia articles, yet):
http://www.mediawiki.org/wiki/Special:VisualEditorSandbox
Post bugs here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
And here's the blog post, which puts it more in context.
http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-deve…
This new editor was mostly written by Trevor Parscal and Inez
Korczyński, although lots of others have contributed. I've sat a desk
away from them for a few months and I have to say I'm extremely
impressed with what they've put together. If you're expecting Google
Docs, we're not there yet. But the basics are starting to solidify, and
it's getting easier and easier to add cool features.
Hey MediaWiki developers, surely you're not going to let Trevor and Inez
have *all* the fun?
--
Neil Kandalgaonkar (| <neilk(a)wikimedia.org>
Hi everyone,
Thank you to everyone who has been reviewing code. Since December 3,
there's been a decline from 1183 unreviewed new revisions, to 644 [1]
That's the good news. The bad news is that we hadn't done so well in
the week prior to that, and we haven't yet made up for lost ground.
By the goals set for a 2012-01-31 review completion date[2], we should
have been down to 644 "new" sometime during December 5, and 360 is
where we should be now. That would seem to put us roughly 8-9 days
behind where we wanted to be.
Some of this is keeping the pace on code review, and everyone seems to
be doing a more-than-credible job there. However, that effort is
going to be wasted if the pace of new code outstrips our capacity to
review it. A bunch of us in Platform have been discussing ways to
make sure we don't backslide, and came up with a few ideas. We're
going to try to get to some important reviews first, as documented on
the 1.19 roadmap page[3]. If we can make any ok/revert decisions on
these revisions soon enough, and we have to revert, we'll leave
ourselves enough time to deal with the consequences.
Speaking about reverting, one pattern the reviewers are going to be
especially sensitive to: refactoring without mailing list discussion
or any clear consensus. If you're doing core work that's not in
service to getting 1.19 finished, and you commit it without discussing
it much, don't be surprised if your work is unceremoniously reverted.
No one likes being trigger happy about reverting, but we really mean
it about needing to finish up 1.19. We need to get caught up for a
whole raft of reasons (getting to faster release cycles, getting moved
over to Git, getting FileBackend done and deployed for Swift). Even
if we weren't in this particular crunch, there's a lot of fatigue
about unilateral refactoring decisions. Let's at least talk about
them before lobbing them out.
One thing that's been tough about the 1.18 deployment has been that
we're just now stumbling into issues that were introduced as early as
January of this year. With the 1.19 deployment, we'll not only close
that gap quite a bit (only stretching back to July now), but also
potentially make it possible to deploy code not long after it's
written, even if its committed early in the deploy cycle. Please work
with us to get there.
Thanks!
Rob
[1] http://toolserver.org/~robla/crstats/
[2] https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Agte_lJNpi-OdD…
[3] http://www.mediawiki.org/wiki/MediaWiki_1.19/Roadmap
I'd like to invite you to the hackathon Wikimedia Foundation is putting
on next month in San Francisco.
https://www.mediawiki.org/wiki/San_Francisco_Hackathon_January_2012
We're focusing on outreach for this one, teaching new developers how to
build stuff using Gadgets and our web-accessible API and Phonegap. A
bunch of WMF's San Francisco engineers will be there, plus (we're
planning) Derk-Jan Hartman, Maarten Dammers, Daniel Kinzler, and a few
more experts from out of town. Whatever your level of expertise, we
welcome you, as a learner and as a hacker.
Please spread the word and please consider coming. Thanks!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hello,
(sorry if someone already got this on an other list)
please try out Sztakipedia toolbar, which is meant to show how AI
technology could help Wikipedia editing.
The 90 sec intro video explains everything:
http://www.youtube.com/watch?v=8VW0TrvXpl4
alternatively, please check out the home page of the tool:
http://pedia.sztaki.hu, for installation instructions, etc.
Please give me feedback, good or bad at the talk page of the tool:
http://en.wikipedia.org/wiki/User_talk:MHeder/Sztakipedia
For me, your feedback is the most essential thing. As a PhD student my
resarch topic is about how to bring some AI into the editor interfaces
where people create knowledge. My primary target was Wikipedia, even though
I'm an occasional contributor only. Dealing the wiki system is no easy
matter though, so the system I introduce today is not implementing the
whole vision I had when we started the development with some other
students. Not even close.
However, I hope that the new visual editor the foundation is working will
could open up new options for the integration of AI. So even if you do not
prefer the current form of Sztakipedia, please share your vision on how we
should do this in the future.
Many thanks,
Mihály Héder
Computer and Automation Research Institute
Hungarian Academy of Sciences
Hey,
I recently added a bunch of wfDeprecated calls to deprecated functions in
core using the new version argument and got a lot of flak for this, since
it caused notices for a lot of people. What a lot of people told me to do
is wait with adding these one or two releases, or at the very least replace
all callers with new equivalent code. This might seem reasonable at first
glance, but sort of undoes the whole point of wfDeprecated IMO. As
extension author I want to be able to see if my code is using any
deprecated functions, not just functions deprecated more then 2 releases
ago. Furthermore, expecting people to release all callers is often
unrealistic, since putting in new code might be context dependent, and
break compatibility with older versions of MediaWiki in extensions where
this is not wanted. So lot's of deprecated methods end up without a
wfDeprecated call at all, causing stuff to suddenly break. Those are 2 very
good reasons why wfDeprecated calls should be added immediately after
deprecating a function.
So what about the notices? Since we have $wgDeprecationReleaseLimit you can
set it to 2 releases back and achieve exactly the same result as delaying
adding the wfDeprecated calls without all the problems associated with that
approach.
This appears to much effort for people though, so what about changing the
default value of $wgDeprecationReleaseLimit from false to $rel - 2? Any
objections to that?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
We gave extensions access to two new committers:
* Nils (kroocsiogsi) will be working on the extension SoundManager2Button.
* Kaseluris-Nikos (synagonism) will be working on the "synagonism" skin.
Welcome!
(By the way, I added a few items to my commit access checklist at
https://wikitech.wikimedia.org/view/Svn.wikimedia.org#Add_users . Every
time I add a committer, I ensure that I link their mediawiki.org
username to their commit username so they get code review emails, give
the mediawiki.org username coder rights, and add the committer to
http://www.mediawiki.org/wiki/Developers . If there are other gotchas I
missed, let me know.)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation