Hi all,
Several technical projects that may be of interest to folks on this list
are currently proposed for Individual Engagement Grants (IEG). Input from
technical contributors is very welcome to help us decide which projects to
fund.
Please come share any comments, suggestions, endorsements or other feedback
you have, directly on the proposal discussion pages on meta-wiki, by April
20, 2014.
There are 7 tools proposals:
* https://meta.wikimedia.org/wiki/Grants:IEG/Finish_Pronunciation_Recording
* https://meta.wikimedia.org/wiki
/Grants:IEG/Tools_for_Armenian_Wikisource_and_beyond
* https://meta.wikimedia.org/wiki/Grants:IEG/WikiTrack
* https://meta.wikimedia.org/wiki/Grants:IEG/The_Wikiquiz
*https://meta.wikimedia.org/wiki
/Grants:IEG/Stepwise_Disclosure_Edition:_Wikipedia_for_shy_people
* https://meta.wikimedia.org/wiki/Grants:IEG/Open_Access_Reader
* https://meta.wikimedia.org/wiki/Grants:IEG/Global_Economic_Map
All IEG proposals can be found here:
https://meta.wikimedia.org/wiki/Grants:IEG#ieg-join
Some background about these grants:
IEGrants fund Wikimedians to work on projects that meet a community need
and aim to have online impact. We're happy to experiment with new ideas,
provided they attempt to solve a useful problem and we can learn something
valuable even from those that don't succeed.
For tools projects in particular, we consider things like:
* Can the project be accomplished independently by the grantee team? If it
needs code review, integration, or something else from WMF engineering
staff, it isn't eligible for funding. (This is to avoid accumulating large
review/integration debt.) So, new MediaWiki core features or extensions
aren't good fits for these grants, but gadgets and stand alone applications
are welcome.
* Does the project have a hosting dependency? If WMF is expected to provide
servers (i.e. hosting beyond what any volunteer has access to via Wikimedia
Labs), it isn't eligible for funding. We like to see hosting plans that can
last beyond a 6-month grant, so we try to avoid short-term funding for
servers via these grants as well.
* Does the project have a community engagement plan? We want to fund tools
that will be useful to real people, so we try to avoid funding projects
that take a "build it and they will come" approach to development.
Hope to see your input on proposals on meta!
Best wishes,
Siko
PS - apologies you're getting this so late, it took me a while to realize
my first message didn't go through.
--
Siko Bouterse
Head of Individual Grants
Wikimedia Foundation, Inc.
sbouterse(a)wikimedia.org
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. *
*Donate <https://donate.wikimedia.org> or click the "edit" button today,
and help us make it a reality!*
FYI to wikitech-l - reply to MZMcBride. See
http://lists.wikimedia.org/pipermail/wikimedia-l/2014-April/071131.html to
follow or contribute to the thread on wikimedia-l if you're not subscribed
there already.
-Adam
---------- Forwarded message ----------
From: Adam Baso <abaso(a)wikimedia.org>
Date: Wed, Apr 16, 2014 at 11:16 AM
Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Inline.
Thanks for starting this thread.
>
> Sorry if I've overlooked this, but who/what will have access to this data?
> Only members of the mobile team? Local project CheckUsers? Wikimedia
> Foundation-approved researchers? Wikimedia shell users? AbuseFilter
> filters?
>
It's a good question. The thought is to put it in the customary wfDebugLog
location (with, for example, filename "mccmnc.log") on fluorine.
It just occurred to me that the wiki name (e.g., "enwiki"), but not the
full URL, gets logged additionally as part of the wfDebugLog call; to make
the implicit explicit, wfDebugLog adds a datetime stamp as well, and that's
useful for purging old records. I'll forward this email to mobile-l and
wikitech-l to underscore this.
> And this may be a silly question, but is there a reasonable means of
> approximating how identifying these two data points alone are? That is,
> Using a mobile country code and exit IP address, is it possible to
> identify a particular editor or reader? Or perhaps rephrased, is this data
> considered anonymized?
>
Not a silly question. My approximation is these tuples (datetime, now that
it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not perfectly
anonymized, are low identifying (that is, indirect inferences on the data
in isolation are unlikely, but technically possible, through examination of
short tail outliers in a cluster analysis where such readers/editors exist
in the short tail outliers sets), in contrast to regular web access logs
(where direct inferences are easy).
Thanks. I'll forward this along now.
-Adam
Hello,
I have upgraded Zuul today (thanks Alexandros for the packaged
dependency). The code we run is in integration/zuul.git and the deploys
are tagged: wmf-deploy-20140122..wmf-deploy-20140416-3
It *might* fix an issue we encounter from time to time where jobs are
enqueued but never run ( https://bugzilla.wikimedia.org/63760 ).
Worth a notes are:
The processing of events is more efficient which speeds up some queue
related operations.
Zuul pass a ZUUL_URL parameter to the jobs. It is used to fetch the Zuul
generated patches.
A command line client to trigger jobs
http://ci.openstack.org/zuul/client.html
Configuration of projects can now be applied multiple templates
http://ci.openstack.org/zuul/zuul.html#project-templates
Zuul status page shows up the version and time of last reconfiguration
(browse to the bottom)
https://integration.wikimedia.org/zuul/
Pipelines can be rate limited. I haven't looked at it closely so I am
not sure whether we can use that feature:
http://ci.openstack.org/zuul/zuul.html#pipelines (window* settings)
We can now combine different type of informations to create an approval
(ie: code-review +2). Look at require-approval in the conf.
--
Antoine "hashar" Musso
http://opt-out.apc.org/
Opt Out: Take Back The Net! will be 4-5 June 2014 in Barcelona, Spain.
An organiser told me:
"Opt Out! Take Back The Net! ... where human rights advocates and
technology providers will meet to discuss solutions to today's climate
of internet-enabled human rights violations. In the spirit of the
free/libre and open source software movement, Opt Out! will have an
unconference-style format, where organisations, activists, service
providers and technologists can propose sessions ranging in scope from
roundtable discussions to hands-on workshops."
Wikimedia volunteers who will organise a session are eligible for travel
subsidy via our grants program:
https://meta.wikimedia.org/wiki/Grants:TPS
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
http://pairjam.com/
Someone I know from Hacker School made this. If you want to pair program
with someone and you're not in the same room, this might help. It has
syntax highlighting, and you can load up a GitHub repo to modify.
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Hi,
TL;DR: Gerrit would allow to keep Code-Review votes across
* rebases and
* commit message modifications
of patch sets.
Thereby dropping need to re-review “trivial” changes on patch sets.
Shall we turn that feature on?
--------------------------------------------
Longer version.
Currently, upon uploading a new patch set for a change in gerrit,
votes get scrubbed. Especially, all Code-Review votes except -2 are
gone.
However, for new patch sets that
* are a plain rebase, or
* only change non-code parts (commit message, ...)
gerrit would allow to reapply votes of the previous patch set to the
new patch set.
People asked me to turn this feature on gerrit-wide for the
Code-Review label.
But I would not want to turn it on without giving people a chance to
discuss it beforehand.
So ... example: Assume for a given change the current patch set's votes
are:
+-------------+-------------+----------+
| Reviewer | Code-Review | Verified |
+-------------+-------------+----------+
| Foo | +2 | |
| Bar | | +1 |
| Baz | +1 | -1 |
| Qux | -2 | |
| jenkins-bot | | +2 |
+-------------+-------------+----------+
Assuming we turn the feature on in gerrit, and I upload a plain rebase
of the current patch set, the votes for the plain rebase would be
+-------------+-------------+----------+
| Reviewer | Code-Review | Verified |
+-------------+-------------+----------+
| Foo | +2 | |
| Bar | | |
| Baz | +1 | |
| Qux | -2 | |
| jenkins-bot | | |
+-------------+-------------+----------+
right after uploading the rebase to gerrit (instead of the current
behaviour of an empty table with only Qux CR-2). Same if I only edit
the patch set's commit message.
But if I upload a patch set that is changing the patch set's diff, the
table of votes would of course still get scrubbed of all votes except
-2 on Code-Review (as it also the case right now):
+-------------+-------------+----------+
| Reviewer | Code-Review | Verified |
+-------------+-------------+----------+
| Foo | | |
| Bar | | |
| Baz | | |
| Qux | -2 | |
| jenkins-bot | | |
+-------------+-------------+----------+
Should we turn that feature on?
Best regards,
Christian
--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a Email: christian(a)quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------
Please help fill in https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Roles:)
It's hard to know what a role does precisely without more docs than are
provided via the 'vagrant list-roles' command. Maybe we could add a
description to the list there? First step would be getting content I guess.
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
As we all know, Gerrit doesn't have the best interface, but even more so,
it's not very mobile friendly. There is however mGerrit [1] for Android
which does a nice job.
Also, we're not in the list of default "supported" Gerrit instannces (yes, I
know WikiMedia is in CamelCase, this is already reported and fixed
upstream).
If you've any issues with the software emailing the developer directly is
quite good at yielding responses.
Sam
[1] https://play.google.com/store/apps/details?id=com.jbirdvegas.mgerrit
First, I like to aplologize to anyone who I may have come over too
passionate at some times. Frustration is known to get the better of me,
even though I should control that. (I also quit smoking.)
Not sure where a new font stack should be discussed, so I'm just
throwing it in here. Also, note I propose this for Latin wikis only.
Asuming we want the 'Helvetca' look for the body font:
font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica,
sans-serif;
Breakdown:
Nimbus Sans L - for Linux. This is the defacto helv font on Linux
systems which result in an look similair to Mac/Windows. Windows will
not match this font, as the Windows versions of the Nimbus font packages
have different font family names (ie. 'NimbusSanL' instead of 'Nimbus
Sans L').
Helvetica Neue - for Mac. Like Nimbus, this should not match fonts on
Windows (or Linux for that matter), as those copies for Windows have
differen font family names (like 'Helvetica Neue LT Com 55 Roman').
Arial - For Windows. Positioned after Nimbus Sans and Helvetica Neue, so
Mac and Linux do not match Arial, but positioned before Helvetica to
prevent matching an inferiour Helvetica font that may be installed on
some Windows machines.
Helvetica - Generic Helvetica fallback for any system not matching any
of the previous fonts.
I'd like to test this locally on the English Wikipedia, and I am quit
confident this makes everyone happy because 1) every OS should end up
using a native font, and 2) it "promotes" a free font at the beginning
of the stack (not a high priority in my book though).
Next up I may think about the headers font stack; While Georgia is a
good serif; I detest its use of text figures.
Regards,
--
Erwin Dokter
In relation to our discussion about code review metrics at
http://korma.wmflabs.org/browser/gerrit_review_queue.html
I just learned that OpenStack has a policy to abandon automatically reviews
sitting in -1 during more than one week:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63533#c1
Maybe one week is too tight for the reality of our project, but what about
2-4 weeks?
Brad and others said last week that they were not interested in code review
queue metrics mixing pending -1 reviews. Maybe the solution is not to tweak
the metrics, but to effectively abandon those changesets automatically?
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil