Forwarding from <https://bugzilla.wikimedia.org/show_bug.cgi?id=40124#c0>:
---
A lot more functionality around user preferences was added with
https://gerrit.wikimedia.org/r/#/c/5126/
Thank you for that.
Recently I found that one can add new options (''keys''). This is very
useful for Community scripts. So I hope this was intentional behaviour and
this bug is about clarifying that.
What in particular, I'd like to know is:
* Will it be supported in future?
* Which max. size (i.e. how many bytes) can the pref have?
* How many prefs can be added?
* Is it possible to remove one particular pref without having to reset all?
Again, it would be really useful if I could get started using this feature.
Currently I have to publicly store user prefs for my scripts using (
https://commons.wikimedia.org/wiki/MediaWiki:Gadget-SettingsManager.js ) in
their common or <skin>.js. Having a private place to store them would be
great, especially because one can retrieve them with both, the API and they
are by default in mw.user.options JavaScript RL module.
---
Any help in answering these questions on this list and/or on the bug would
be great.
MZMcBride
I wanted to raise an issue that the mobile team has recently
discovered during development of the Wiki Loves Monuments mobile app
[1] on github.
Wikimedia has a github account with currently 18 members [2]. Every
single one of these can merge to master on any of the projects.
The mobile team early on decided on a rule that no one can merge their
own code to ensure that we maintain code quality by ensuring that all
commits have been reviewed by at least once person.
This breaks down when people outside the mobile team who don't know
this rule need to commit code to our repository. We've had two
instances recently. One was a bad commit which reverted a change made
by an earlier commit and another could have been improved as it
cleaned up a file that wasn't actually being used and could have just
been removed all together. These things could have been
prevented/improved by our review system on github. Even I have been
caught out by merging my own code in a situation where I thought
someone was a simple change but turned out not to be.
Is this something we need to enforce ourselves (i.e. is there a way to
reject merges where the author is the same) or could we simply agree
and document somewhere that anyone with wikimedia account access on
github should not merge any changes to a project they have made
themselves?
[1] https://github.com/wikimedia/WLMMobile
[2] https://github.com/wikimedia
Hi everyone,
I'm pleased to announce Dan Andreescu will join the Analytics team
today as our new Javascript/UI engineer. In this role, he will be
taking on development of Limn[1], our data visualization and dashboard
building toolkit. He is also going to be responsible for the
front-end for Kraken[2], the self-servicing data platform that is
being developed by the Analytics team.
Dan studied Computer Science at Cornell University and he is a builder
at heart. He is passionate about designing and building almost
anything: furniture, software, tools and houses. An example of this
is his work with Earthship[3]: radically sustainable buildings made
with recycled materials. Clearly, Dan loves working on big problems
and that's why we are so excited to have him join the Foundation (and
the Analytics Team in particular)!
Dan is based out of Philadelphia, and is on IRC as "milimetric".
Please join me in welcoming Dan!
Rob
[1] https://github.com/wikimedia/limn
[2] http://www.mediawiki.org/wiki/Analytics/Kraken
[3] http://earthship.com/
Hello!
Should it work for languages other than English? I tried
http://ru.wikipedia.org/wiki/%D0%93%D0%BE in the demo and nothing
happended. GoogleChrome, Windows 7
-----
Yury Katkov
On Mon, Sep 10, 2012 at 10:13 PM, Dario Taraborelli
<dtaraborelli(a)wikimedia.org> wrote:
> OKFN Labs just released a lightweight JS library to pull machine-readable data on Wikipedia articles from DBPedia
>
> http://okfnlabs.org/wikipediajs/
>
> Dario
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Heads-up: The Wikimedia Foundation is having its yearly all-staff
meeting this week, and the engineering department has added its own set
of meetings to that. So lots of us will be way less responsive and
available Tuesday through Friday, and when we're on IRC we'll be on San
Francisco time.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hello
We have had a pretty productive week with the Wikidata team. The most pressing
issues concerning the Foundation team are however still the same:
The Sites table is pending finalization. It coming along nicely, and I think we
will have a new version early next week. Development is happening on a separate
development branch called "sites", any feedback is appreciated.
The Wikidata branch with the ContentHandler and related changes has seen some
improvements over the week, and I have once more merged the latest master into
the branch. However, I'm wondering how to best proceed now.
Until a few weeks ago, I let development on that branch rest, awaiting feedback
so I could be sure to be moving into the right direction. This didn't work out,
since the code was still too incomplete for a full review. I have now tied down
most loose ends, but I'm still getting no feedback. Would it be best to halt
development again? It's never going to be *finished*, there's always *something*
to improve...
Cheers
Daniel
CodeConnexx is November 8-9, 2012 in Indianapolis, Indiana, USA.
Elizabeth M. Smith, who worked on ArticleFeedback (and used to hack on
PHP), is giving a "Mentoring Developers" talk. The conference also
includes talks on MySQL query optimization, MicroPHP, deployment, HTTP,
managing geeks, and collaboration skills, with a focus on PHP.
http://codeconnexx.com/
Registration is $99 and includes free onsite childcare.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
https://meta.wikimedia.org/wiki/Participation:Support
If you want to speak or volunteer at a conference, and you need some
help with costs, check out our Participation Support program. It offers
participation support to Wikimedia community members, i.e. volunteers
contributing to Wikimedia projects such as MediaWiki, for non-Wikimedia
events.
Participation support is reimbursement covering travel, accommodation
and incidental expenses as necessary, in relation with participating in
(as distinct from merely attending) an event or activity.
So, for example, you could apply for Participation Support if you wanted to:
* help staff the open source booth[0] at the Grace Hopper conference,
October 3-6 [1]
* present a poster at Grace Hopper India in December (call closes
September 15th [2])
* speak at the Strata Conference in February (call for talks closes
Sept 30 [3])
If you need ideas for talks, check out the Presentations archive on
wikitech.wikimedia.org[4], and to see what conferences are coming up, I
like the LWN calendar[5].
[0] http://systers.org/systers-dev/doku.php/ghc12fossbooth
[1] http://gracehopper.org/2012/
[2]
http://gracehopper.org.in/2012/participate/call-for-participation-poster-se…
[3] http://strataconf.com/strata2013/
[4] https://wikitech.wikimedia.org/view/Presentations
[5] https://lwn.net/Calendar/
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hi all,
here's our weekly list with Wikidata review items. We have a few new
ones, some of them also rather small, next to the big gorillas.
I say it as Rob does: if you want to discuss on of the items here, it
would make sense to rename the thread in your answer. Based on
experience, I accept the futility of this recommendation, though :)
* ContentHandler. Tim stated he could do another review this week, in
the meanwhile we have tied up several loose ends. We are eagerly
awaiting the review and further input. Here's the bug:
<https://bugzilla.wikimedia.org/show_bug.cgi?id=38622> Some discussion
was here on the list, too.
* Sites. There has been quite some activity, input from the outside,
and the sites code has been reworked greatly. It landed in Gerrit
today and is awaiting reviews. Here's the link to the RFC:
<https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system>
and it is widely implemented.
* jQuery table sorting improvements. This improves the UI on initial
display of a sorted table. Here's the patchset in Gerrit:
<https://gerrit.wikimedia.org/r/#/c/22562/>
* userWasLastToEdit improvement. It is just moving the function to a
static place so it is available for an extension to call. That one
looks straightforward to me. Here's the patchset in Gerrit:
<https://gerrit.wikimedia.org/r/#/c/22049/>
* Towards nested transactions. There was quite some discussion on the
mailing list, and here are the currently open patchsets towards that.
Some other patchsets have been already merged. Currently still open
are: <https://gerrit.wikimedia.org/r/#/c/21582/> and
<https://gerrit.wikimedia.org/r/#/c/21584/> . Note that this patch
neither implements nested transactions, nor do we require them (we
worked around that), it just would make the code nice if they were
there and these are patches preparing for nested transactions.
* Reviewing the extension. We have a beautiful extension here, which
is quite ready for deployment on the repository, and we need to
organize the review for the extension as a whole. I assume we will
start talking about this next week.
We would be very happy to see activity and merges on all or any of
these items :)
Cheers,
Denny
--
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.