I will add this to my ever-growing list of possible projects for Cascadia. There are a few other projects under consideration that have received little WMF support but I feel are movement-aligned and would interest the public or the contributor base. In order for Cascadia to work on these projects there will be several steps such as getting AffCom approval for Cascadia, consensus of the Cascadians of what we want to do as a group, and finding people with the necessary technical expertise. I'm speculating that we might hire on a contract basis for short-term software projects if GAC or the FDC support that approach, or we might put out an RFP. In general I would say this sounds like a project we might want to support. A number of our members have technical, research, or GLAM interests. Of course, if WMCH wants to do this work and can do it faster than Cascadia, or someone makes a good proposal to work on this project through IEG or GSOC/OPW, that is ok. We in Cascadia are still very early in our development and we can find other work to do if we decide that we want to support movement-wide projects. Pine* * Speaking only in a personal capacity On Wed, Jun 25, 2014 at 8:54 PM, Erik Moeller <erik(a)wikimedia.org> wrote:

Just as a quick update from WMCH - we are currently discussing our strategy/priorities for the 2015-20 cycle and yes, we plan to decide over the Summer whether we want to ramp up our development activities or not. We will, of course, keep you guys posted. 2014-06-26 10:29 GMT+02:00 Jon Davies <jon.davies(a)wikimedia.org.uk>uk>:

Erik (and others), is there any coordination page where groups could place, take, or discuss "requests for development" or "requests for maintenance"? I saw often that sometimes the hard-to-achieve consensus is found, but there is no way to evaluate the idea further. What now happens is: - several development proposals materialize through different channels (community, user groups, idea lab, RFCs, etc) - there is a general consensus about "project A" - limbo.... or an IEG, but as Ilario says, that doesn't guarantee its future viability or integration with current or planned workflows, or availability of resources for maintenance It would be more rational to have a further step in the pipeline where development ideas could be commented, "shot down", or "approved for further commitment" by the ones who actually can understand how they fit in the broader product management/life-cycle context (engineering? PMs? chapters?). There are often community ideas that on first sight look great, but when you think about the potential problems, implications, costs, or stepping on the toes of other developments, that it is more rational not to start them or delay them until certain conditions are met. But no voice is heard, and that causes frustration and a sense of disconnection in the community, when just a single statement "this shouldn't be done because X", would make everyone more aware of the limits. And the opposite too, when some idea gather community support and is green-lighted for further commitment, that would make chapters or other organizations more confident about what is wanted and how. Micru On Thu, Jun 26, 2014 at 5:54 AM, Erik Moeller <erik(a)wikimedia.org> wrote: -- Etiamsi omnes, ego non

Just pinging this thread -- looking through all the proposals for annual plan grants: https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikim… I'm not seeing any developer contract time allocated to GLAM tooling work yet. At the same time I'm seeing reports of breakage and missing functionality in important tools running in Labs. To the extent that this breakage is due to Labs infrastructure or access to data, it's our job (WMF) to fix it and you should (continue to) poke us to do so -- but to the extent that it can be addressed in the tools themselves, I'd love to see chapters take this on directly. It's possible that I'm missing something. Are there more concrete plans at this point in time to help support the tools developed by Magnus and others, and create new reports on an as-needed basis? Having a dedicated staff person in chapters or an affilicate like Europeana who WMF analytics can partner with would be really helpful for keeping this moving, in my view. Thanks, Erik -- Erik Möller VP of Product & Strategy, Wikimedia Foundation

Hoi, There are several issues and imho the one Erik mentions is crucial. When no money is intended for GLAM tool related work, nothing will happen. The situation will remain one where everybody is eying each other... are you going to make a move ... are you? If you are all for a comprehensive technical infra structure blabla, all well and good. Nothing is going to happen without an initiative and, any initiative that does not have funding support will end up on Labs. Fiddling with small scale improvements are nice, it will provide some solace but what we need is a next generation of tools and of particular importance is reporting. An environment is being developed for statistics and reporting but as far as I can see it is either really hard or developments are not being communicated or there is not much to report anyway. Erik challenges the chapters. I hope the chapters rise to the occasion and define a plan. From what I observed the most important part of the products that are of use to GLAMS, stability is the main thing. We need continuous reporting. We need the continuous availability of tools. That is very much more than only a question of Labs or not Labs. If anything it is a challenge to Erik how he envisions to provide a platform for statistics that will be continuously available and how he will ensure that tools are stable and are available. Thanks, GerardM PS The statistics for Wikidata are still broken and who is going to tackle that and the break in reporting ??? On 25 October 2014 16:16, MZMcBride <z(a)mzmcbride.com> wrote:

Federico Leva (Nemo) wrote: I think it's a limited view to suggest that the Wikimedia Foundation should only provide raw dumps and/or queryable data and have volunteers try to cobble together scripts and tools to interact with the data. That certainly can and should be a piece of this, but there's no good reason not to, for example, integrate page view graphs into MediaWiki's info action, allowing regular users to see quickly and easily see an article's page views over time. We already have queryable revision information, but we rely on external tools and services to try to graph edits over time, rather than having visual functionality integrated into MediaWiki. The same is true of visualizing a particular user's edits or other logged actions. We're relying on external tools when we should be trying to create tools that live within the technical platform that we've created. A generalized, scaleable graphing/visualization tool would be an excellent use of resources. Making such a tool could easily have a definable goal with clear requirements, and implementing and deploying such a tool would have a very clear benefit to all of our projects. We have a real problem turning proofs of concept into stable infrastructure. GLAMs and Chapters can invest in creating stable infrastructure, but that probably doesn't mean investing in Labs, exactly. Not if you want to have a long-term, substantive impact, in my opinion. Regarding page views data specifically, the Wikimedia Foundation has done a good deal of cookie-licking in this area and that really should be addressed. The linked bug report demonstrates what I'm talking about. It's been _years_ of waiting as various analytics team have come and gone (does anyone remember when Open Web Analytics was going to save the day?). And yet it's 2014 and we still can't answer the most basic analytics questions such as "how many views did X article get this month?" There has been some deep dysfunction in this area of the Wikimedia Foundation, but I don't know what any GLAM institution or Wikimedia Chapter can do about the analytics situation, so it may be best to focus on other areas in which making an impact is feasible. MZMcBride

On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride <z(a)mzmcbride.com> wrote: 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:Graph https://www.mediawiki.org/wiki/Extension:Graph/Demo https://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&use… [5] https://www.mediawiki.org/wiki/Special:OAuthListConsumers?name=&publish… [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

On Sat, Oct 25, 2014 at 5:58 PM, Erik Moeller <erik(a)wikimedia.org> wrote: The Wiki Education Foundation just introduced its Assignment Wizard, which is being developed with the help of an outside agency. As this tool develops, there may be opportunities for sharing experiences with other Wikimedia organizations: http://wikiedu.org/blog/2014/11/07/user-testing-assignment-design-wizard/ Erik -- Erik Möller VP of Product & Strategy, Wikimedia Foundation

When I start from this page: http://wikiedu.org/blog/2014/11/07/user-testing-assignment-design-wizard/ and I click the wizard.wikiedu.org <http://wikiedu.org/blog/2014/11/07/user-testing-assignment-design-wizard/wizard.wikiedu.org> link I arrive in a page which says: This is somewhat embarrassing, isn’t it?Is this the aim? Regards <http://wikiedu.org/blog/2014/11/07/user-testing-assignment-design-wizard/wizard.wikiedu.org> On Tue, Nov 11, 2014 at 6:35 AM, Erik Moeller &lt;erik(a)wikimedia.org&gt; wrote: -- Ilario Valdelli Wikimedia CH Verein zur Förderung Freien Wissens Association pour l’avancement des connaissances libre Associazione per il sostegno alla conoscenza libera Switzerland - 8008 Zürich Wikipedia: Ilario <https://meta.wikimedia.org/wiki/User:Ilario> Skype: valdelli Facebook: Ilario Valdelli <https://www.facebook.com/ivaldelli> Twitter: Ilario Valdelli <https://twitter.com/ilariovaldelli> Linkedin: Ilario Valdelli <http://www.linkedin.com/profile/view?id=6724469> Tel: +41764821371 http://www.wikimedia.ch