After the first filtering of FOSS Outreach Program for Women applications,
we have eight candidates moving onto the next level in the selection
process:
https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9
Right now there are six candidates in this table, and two more are coming
after having applied to opw.gnome.org, following correctly the program
process.
Community scrutiny and feedback is welcome. Please be kind and informative
in your replies. All of us were newbies one day (and still today in most
fields).
A total of fifteen candidates applied. We have declined seven because they
had incomplete proposals, and we have invited them to start preparing their
proposals for the next round.
You can check all the details and follow the progress here:
https://phabricator.wikimedia.org/T564
In fact, you can already subscribe to the task related to the next FOSS OPW
round and GSoC 2015: https://phabricator.wikimedia.org/T921
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Forwarding comments from Wikimedia-l that may be of interest to a number of
subscribers on other lists.
Pine
---------- Forwarded message ----------
From: "Erik Moeller" <erik(a)wikimedia.org>
Date: Oct 25, 2014 5:59 PM
Subject: Re: [Wikimedia-l] Chapters and GLAM tooling
To: "Wikimedia Mailing List" <wikimedia-l(a)lists.wikimedia.org>
Cc:
On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride <z(a)mzmcbride.com> wrote:
> Labs is a playground and Galleries, Libraries, Archives, and Museums are
> serious enough to warrant a proper investment of resources, in my view.
> Magnus and many others develop magnificent tools, but my sense is that
> they're largely proofs of concept, not final implementations.
Far from being treated as mere proofs of concept, Magnus' GLAM tools
[1] have been used to measure and report success in the context of
project grant and annual plan proposals and reports, ongoing project
performance measurements, blog posts and press releases, etc. Daniel
Mietchen has, to my knowledge, been the main person doing any
systematic auditing or verification of the reports generated by these
tools, and results can be found in his tool testing reports, the last
one of which is unfortunately more than a year old. [2]
Integration with MediaWiki should IMO not be viewed as a runway that
all useful developments must be pushed towards. Rather, we should seek
to establish clearer criteria by which to decide that functionality
benefits from this level of integration, to such an extent that it
justifies the cost. Functionality that is not integrated in this
manner should, then, not be dismissed as "proofs of concept" but
rather judged on its own merits.
GWToolset [3] is a good example. It was built as a MediaWiki extension
to manage GLAM batch uploads, but we should not regard this decision
as sacrosanct, or the only correct way to develop this kind of
functionality. The functionality it provides is of highly specialized
interest, and indeed, the number of potential users to-date is 47
according to [4], most of whom have not performed significant uploads
yet. Its user interface is highly specialized and special permissions
+ detailed instructions are required to use it. At the same time, it
has been used to upload 322,911 files overall, an amazing number even
without going into the quality and value of the individual
collections.
So, why does it need to be a MediaWiki extension at all? When
development began in 2012, OAuth support in MediaWiki did not exist,
so it was impossible for an external tool (then running on toolserver)
to manage an upload on the user's behalf without asking for the user's
password, which would have been in violation of policy. But today, we
have other options. It's possible that storage requirements or other
specific desired integration points would make it impossible to create
this as a Tool Labs tool -- but if we created the same tool today, we
should carefully consider that.
Indeed, highly specialized tools for the cultural and education sector
_are_ being developed and hosted inside Tool Labs or externally.
Looking at the current OAuth consumer requests [5], there are
submissions for a metadata editor developed by librarians at the
University of Miami Libraries in Coral Gables, Florida, and an
assignment creation wizard developed by the Wiki Education Foundation.
There's nothing "improper" about that, as Marc-André pointed out.
As noted before, for tools like the ones used for GLAM reporting to
get better, WMF has its role to play in providing more datasets and
improved infrastructure. But there's nothing inherent in the
development of those tools that forces them to live in production
land, or that requires large development teams to move them forward.
Auditing of numbers, improved scheduling/queuing of database requests,
optimization of API calls and DB queries; all of this can be done by
individual contributors, making this suitable work for even chapters
with limited experience managing technical projects to take on.
On the analytics side, we're well aware that many users have asked for
better access to the pageview data, either through MariaDB, or through
a dedicated API. We have now said for some time that our focus is on
modernizing the infrastructure for log analysis and collection,
because the numbers collected by the old webstatscollector code were
incomplete, and the infrastructure subject to frequent packet loss
issues. In addition, our ability to meet additional requirements on
the basis of simple pageview aggregation code was inherently
constrained.
To this end, we have put into production use infrastructure to collect
and analyze site traffic using Kafka/Hadoop/Hive. At our scale, this
has been a tremendously complex infrastructure project which has
included custom development such as varnishkafka [6]. While it's taken
longer than we've wanted, this new infrastructure is being used to
generate a public page count dataset as of this month, including
article-level mobile traffic for the first time [7]. Using
Hadoop/Hive, we'll be able to compile many more specialized reports,
and this is only just beginning.
Giving community developers better access to this data needs to be
prioritized relative to other ongoing analytics work, including but
not limited to:
- Continued development and maintenance of the above infrastructure
foundations;
- Development of "Vital Signs": public reports on editor activity,
content contribution, sign-ups and other metrics. This tool gives us
more timely access to key measures than WikiStats [9] (or the
reportcard [10], which to-date still consumes Wikistats data). Rather
than having to wait 4-6 weeks to know what's happening with regard to
editor numbers, we can see continuous updates on a day-to-day basis.
- Development of Wikimetrics, which analyzes the editing activity of a
group of editors, and which is essential for measuring all movement
work that targets increased activity by a targeted group (e.g.
editathon), and is a key tool used for grants evaluation (was a funded
program worth the $$?). A lot of thought has gone into the development
of standardized global metrics [12] for program work, much of it
using this technology and dependent on its continued development.
- Measurement (instrumentation) of site actions and
development/maintenance of associated infrastructure. As an example,
in-depth data collection for features like Media Viewer (see
dashboards at [13] ) is only possible because of the EventLogging
extension developed by Ori Livneh, and the increasing use of this
technology by WMF developers. EventLogging requires significant
management, maintenance and teaching effort from the analytics team.
Lila is requesting visibility into all primary funnels on Wikimedia
sites (e.g. sign-ups, edits/saves through wikitext, edits/saves
through VisualEditor, etc.), and this will require lots of sustained
effort from lots of people to get done. What it will give us is a
better sense of where people succeed and fail to complete an action --
by way of example, see the initial UploadWizard funnel analysis here:
https://www.mediawiki.org/wiki/UploadWizard/Funnel_analysis
- Improved software and infrastructure support for A/B testing,
possibly including adoption of existing open source tooling such as
Facebook's PlanOut library/interpreter [14].
- Improved readership metrics, possibly including a privacy-sensitive
approach to estimating Unique Visitors, and better geographic
breakdowns for readers/editors.
These are all complex problems, most of which are dependent on the
small analytics team, and feedback on projects and priorities is very
much welcome on the analytics mailing list:
https://lists.wikimedia.org/mailman/listinfo/analytics
With regard to better embedding of graphs in wikis specifically, Yuri
Astrakhan has led the development of a new extension, inspired by work
by Dan Andreescu, to visualize data directly in wikis. This extension
has been deployed already to Meta and MediaWiki.org and can be used
for dynamic graphs where it's appropriate to not have a fallback to a
static image, for example in grant reports. See:
https://www.mediawiki.org/wiki/Extension:Graphhttps://www.mediawiki.org/wiki/Extension:Graph/Demohttps://meta.wikimedia.org/wiki/Graph:User:Yurik_(WMF)/Obama
I agree this is the kind of functionality that should make its way
into Wikipedia. Again, we need to judge throwing a full team behind
that against the relative priority of other work. In the meantime,
Yuri and others will continue to push it along and may even be able to
get it all the way there in due time. The main blockers, from what I
can tell, are generation of static fallback images for users without
JavaScript, and a better way to manage the data sources.
In general, the point of my original message was this: All
organizations that seek to improve Wikipedia and the other Wikimedia
projects ultimately depend on technology to do so; to view WMF as the
sole "tech provider" does not scale. Larger, well-funded chapters can
take on big, hairy challenges like Wikidata; smaller, less-funded orgs
are better positioned to work on specialized technical support for
programmatic work.
I would caution against requesting WMF to work on highly specialized
solutions for highly specialized problems. If such solutions are
needed, I would caution against building them into MediaWiki unless
they can be generalized to benefit a larger number of users, at which
point it's appropriate to seek partnership with WMF, or to ask WMF for
the relative priority of such work. But often, it's perfectly fine
(and much faster) to build such tools and reports independently, and
to ask WMF for help in providing APIs/services/data/infrastructure to
get it done.
Cheers,
Erik
[1] http://tools.wmflabs.org/glamtools/
[2]
https://outreach.wikimedia.org/wiki/Category:This_Month_in_GLAM_Tool_testin…
[3] https://www.mediawiki.org/wiki/Extension:GWToolset
[4]
https://commons.wikimedia.org/w/index.php?title=Special%3AListUsers&usernam…
[5]
https://www.mediawiki.org/wiki/Special:OAuthListConsumers?name=&publisher=&…
[6] https://github.com/wikimedia/varnishkafka
[7] https://wikitech.wikimedia.org/wiki/Analytics/Pagecounts-all-sites
[8] https://metrics.wmflabs.org/static/public/dash/
[9] http://stats.wikimedia.org/
[10] http://reportcard.wmflabs.org/
[11] https://metrics.wmflabs.org/
[12]
https://meta.wikimedia.org/wiki/Grants:Learning_%26_Evaluation/Global_metri…
[13] http://multimedia-metrics.wmflabs.org/dashboards/mmv
[14] https://github.com/facebook/planout
--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
The Wikimedia Phabricator team needs help from someone familiar with PERL.
The Bugzilla API has a bug, which we tried to fix with a patch, but now
that patch creates another problem. Now we either break comments or binary
attachments. The details:
Upstream Bugzilla XML-RPC API issue creates invalid XML
https://phabricator.wikimedia.org/T815
Your help is welcome! It doesn't seem to be too complicated. The task
doesn't require any background on Phabricator or Bugzilla.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_October_27th>
A quick list of notable items...
== All week ==
* Nightly localization (translation) update will be temporarily
disabled starting from 2014-10-27 because of migration of plural rules
to CLDR 26
** see <https://bugzilla.wikimedia.org/show_bug.cgi?id=62861>
** WHY? We are disabling the updates to reduce the chance of
ungrammatical translations being displayed in the interface.
Translators are requested to start updating translations from Tuesday
28th October 2014 onwards.
== Monday ==
* HHVM (improved MediaWiki server performance) will restart their
deployment plan (one week delayed) after a fix for a blocking
performance issue is deployed and tested on Monday.
== Tuesday ==
* MediaWiki deploy
** group1 to 1.25wmf5: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf5>
* Switching SpecialCite out for CiteThisPage
** <https://bugzilla.wikimedia.org/show_bug.cgi?id=71112>
** <https://gerrit.wikimedia.org/r/158121>
== Wednesday ==
(NB: Note the change of day)
* MediaWiki deploy
** group2 to 1.25wmf5 (all Wikipedias)
** group0 to 1.25wmf6 (test/test2/testwikidata/mediawiki)
Thanks and as always, questions and comments welcome,
Greg
--
Greg Grossmeier
Release Team Manager
After discussion within the WMF Product and Engineering teams along
with the Wikimedia Deutschland developers (mainly for Wikidata) I have
decided to rearrange the MediaWiki "train" deployment schedule.
The changes are relatively minor (simply day of week and time of day)
but I want everyone to be aware of the changes. The changes will take
effect starting next week (the week of October 27th).
For a quick reference of what the new schedule is, please see:
<https://wikitech.wikimedia.org/wiki/Deployments/One_week>
The salient changes are:
* I've moved the Thursday deployment to Wednesday at the same time
** This is the day when a new version goes to testwikis and
mediawiki.org AND the previous branch goes to all Wikipedia projects.
** This will give developers and product managers more time to assess
and fix any issues found after their code hits production for the
first time.
* I've also moved the Tuesday deployment to 5am Pacific (from 11am Pacific)
** This is the day when we deploy the new version to non-Wikipedia
projects (ie: Commons, Wiktionary, etc).
** This will allow the Wikidata team to more easily (and with a better
work/life balance) respond to issues after their code hits their
primary wikis.
Let me know if you have any questions,
Greg
--
Greg Grossmeier
Release Team Manager
Hello,
Those of you that have deal with client side translation in javascript
might appreciate this library recently released from yahoo:
http://formatjs.io/github/
Just an FYI
Nuria
Hi!
I am Priyanka Jayaswal and I am willing to contribute towards Compat to core
migration for FOSS Outreach Program for Women - Round 9. I have selected a
mentorship project from Project list <
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects> named
Pywikibot to resolve it's issue on Compat to core Migration. I have been in
contact with mentor John Vandenberg and we have proposed a rough proposal
based on our discussions and thoughts.
Further information about the project has been provided on the Proposal
page:
https://upload.wikimedia.org/wikipedia/mediawiki/0/01/ProposalPywikibot-Com…
Link for wiki proposal page may be found in :
https://www.mediawiki.org/wiki/User:Prianka .
We need community's valuable suggestions to improve the proposal, add
possible features, and views on the project so that this project can be
success.
Thanks !
--
*Priyanka Jayaswal*
Third Year Undergraduate Student
Department of Mathematics
Indian Institute of Technology, Kharagpur