Would you like to improve our debugging, logging, or monitoring
infrastructure to make it faster to troubleshoot problems?
"Gimme more debug info" bugs:
* Wikimedia Labs: Make instance creation failures more verbose
* MediaWiki core: Report more information about php warnings
* MWSearch extension: include the debug comment about where search
results originated even for empty result sets
Bigger implementation gaps:
* Rework API error reporting
* ResourceLoader: Implement feature for logging in debug mode
* ResourceLoader: Support source maps for debugging production
ResourceLoader JS
Bug list:
https://bugzilla.wikimedia.org/buglist.cgi?bug_id=43086,37763,45514,45843,4…
(Thanks to Andre Klapper for assembling this.)
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hi everyone,
As you may have remembered reading. Huib--our longtime volunteer moderator
for mediawiki-l and wikitech-l--resigned from his positions back in February[0].
I let this slip longer than I should've, but I'd like to now make the
call for a new
batch of list moderators for mediawiki-l and wikitech-l.
I think it's very important to have more than one moderator per list,
so I'm looking
for several candidates to help with moderation with one (or both)
lists. It's a pretty
low maintenance job (the occasional spammer), as Huib and myself have always
had a very light-handed moderation policy and have preferred to let discussions
run their course.
So, if this is something you're interested in helping out with, please
respond to
this off-list and tell me why. Don't need an essay, just a sentence or two about
who you are and why you'd like to volunteer. I'll give it a couple of
days for people
to think about it and e-mail me, and I'll pick some people by late next week.
Thanks, and have a good weekend :)
-Chad
[0] http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066320.html
Hi,
I am Praveen Singh, a final Year Computer Science Graduate student at JIIT,
India. I wish to apply for GSoC 2013 and I am thinking about jQuery.ime
extensions for Firefox and Chrome as a project for the same.
What I understood about the jQuery.ime project after going through its Github
repository <https://github.com/wikimedia/jquery.ime> is :
- It provides multilingual input support for the editable fields on a
page.
- Rules and keyboard mappings for different languages are defined in
different js files for corresponding languages.
Does the project simply aims at packaging the source files into an
extension ?
If so, doesn't that sounds a pretty small project for the complete GSoC
timeline ? (Your thoughts ?)
Or is it the fact that we need to develop two different extensions (for
firefox and chrome), that makes it a good enough project for GSoC ?
Enlighten me if I am not clear with the objectives of the project.
Thanks,
Praveen Singh
Hello,
This morning was very quiet so I have been bold and upgraded our Zuul
installation.
The new version comes with:
- faster reporting (we have been hit by that a few weeks ago)
- various performances improvement
- configuration validation (I have setup the Jenkins job already)
- support for Gerrit events introduced in 2.5/2.6
- statistics reporting (though that needs statds)
- customization of success and failure messages
Overall, there is no user facing change.
Next steps would be customizing the messages a bit and complete the
Debian package to make upgrades easier.
Thanks to Faidon for all his help while packaging the python modules
dependencies.
cheers,
--
Antoine "hashar" Musso
For wider distribution!
---------- Forwarded message ----------
From: Jon Robson <jdlrobson(a)gmail.com>
Date: Tue, Apr 23, 2013 at 5:13 AM
Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins
To: mobile-l <mobile-l(a)lists.wikimedia.org>
I've been playing around with skins a lot recently. The MobileFrontend
extension has had to do various transformations to the content
pre-rendering to ensure certain things do not get rendered on mobile
(for example table of contents) as well as allow us to do collapsible
sections.
When rendering content skins are currently limited to rendering the
'bodytext' key. They cannot retrieve the underlying content. I would
like to remove restrictions to skin designers - for instance currently
a skin designer has no control over where the table of contents should
do. They could not easily put it in a side bar for instance.
I was experimenting with using the onOutputPageParserOutput hook [1]
(running based on the current skin) and think it might be a better
approach to run the transformations on smaller chunks of data. For
instance the table of contents is known to be in the lead section so
it seems like it would be more efficient to look for it there rather
than throughout the entire document. The solution is not complete but
provides an approach that I think would be more efficient on the long
term.
It seems like a good idea to experiment with this approach in
MobileFrontend extension with the goal to upstream it to core.
Would appreciate comments from people who know this area of code
rather well - Max comes to mind :)
Thoughts welcomed!
[1] https://gist.github.com/jdlrobson/5439509
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Yuvi Panda T
http://yuvi.in/blog
I am completely amazed by a particularly brilliant way that Wikipedia uses
Wikidata. Instead of simply displaying the data from Wikidata and removing
the local data, a template and workflow is proposed, which...
* grabs the relevant data from Wikidata
* compares it with the data given locally in the Wikipedia
* displays the Wikipedia data
* adds a maintenance category in case the data is different
This allows both communities to check the maintenance category, provide a
security net for vandal changes, still notice if some data has changed,
etc. -- and to phase out the local data over time when they get comfortable
and if they want to. It is a balance of maintenance effort and data quality.
I am not saying that is the right solution in every use case, for every
topic, for every language. But it is a perfect example how the community
will surprise us by coming up with ingenious solutions if they get enough
flexibility, powerful tools, and enough trust.
Yay, Wikipedia!
The workflow is described here:
<
http://en.wikipedia.org/wiki/Template_talk:Commons_category#Edit_request_on…
>
There is an RFC currently going on about whether and how to use Wikidata
data in the English Wikipedia, coming out of the discussion that was here a
few days ago. If you are an English Wikipedian, you might be interested:
<
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Wikidata_Phase_2
>
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Based on a discussion I had with YuviPanda and MaxSem on #wikimedia-mobile,
I've got a few things to add:
- It might be a good idea to let Wikidata detect when it's being accessed
through a mobile device and then have it adjust the widths and such of the
box-structures accordingly and then pass them to MobileFrontend.
Maybe we can set up a Wikilabs instance with MobileFrontend like Quim Gil
suggested and then we can see how much work there is involved with trying
to make WIkidata mobile-friendly.
If we can get it to work with MobileFrontend, that'll be excellent but if
it turns out to be too complex or too dirty a solution, it would make more
sense to make a completely new extension for it.
Although the scope of the project is not very clear at the moment, I think
that a feasible implementation plan could be worked out with respect to the
GSoC timeline and if it's required, I can continue to work on the project
after GSoC ends.
On Tue, Apr 9, 2013 at 6:49 PM, Quim Gil <qgil(a)wikimedia.org> wrote:
> On 04/09/2013 02:39 AM, Denny Vrandečić wrote:
>
>> I would hope
>>
>
> It would also be extremely good to look
>>
>
> > I would assume
>
> I don't think
>>
>
> Can the Wikidata and Mobile teams please answer with the best of your
> knowledge to the questions at
>
> Bug 43065 - WikibaseRepo to be mobile friendly (tracking)
> https://bugzilla.wikimedia.**org/show_bug.cgi?id=43065<https://bugzilla.wikimedia.org/show_bug.cgi?id=43065>
>
> Beyond hope and believe, the fact is that I couldn't get any answer more
> precise than "Interesting" when asking about this project to people in
> those teams. And as for today I'm not confident to tell to a candidate like
> Pragun whether this project is too complex or too simple, and where the
> complexity/simplicity relies.
>
> In case of doubt I'd prefer to play safe and actually not encourage GSOC /
> OPW to apply for a project like this, before we regret around August.
>
> Is it possible to have a Wikidata / WikidataRepo test instance somewhere
> with MobileFrontend enabled, so we can all have a look and know more about
> the gap this project should fill?
>
> --
> Quim Gil
> Technical Contributor Coordinator @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/**User:Qgil<http://www.mediawiki.org/wiki/User:Qgil>
>
>
> ______________________________**_________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
--
Pragun Bhutani
http://pragunbhutani.in
Skype : pragun.bhutani