Erik Moeller wrote: >On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride <z...@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]
It's funny that you mention "This Month in GLAM" as my now-defunct bot delivered its monthly newsletter for quite some time. The MassMessage MediaWiki extension is a pretty great case study of exactly what I'm discussing here: turning a proof-of-concept script into a supported and maintained tool that's integrated with MediaWiki. :-) While it's tedious to get an extension deployed, the (ideal) result is that it has documentation, it's gone through series of review (performance, security, architecture, and design) and we know where the source code is and how to build it. That's not nothing! >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. Sure, I agree with this in principle. When I consider Labs (or Tool Labs), I think of the Toolserver: <https://toolserver.org/~magnus/>. My point was that GLAMs should be taken seriously. The Wikimedia Foundation's historical track record with regard to GLAM support isn't great. And from the perspective of these institutions, I continue to believe that it makes sense to invest in long-term solutions, even if they're more costly in terms of time and money. Wikimedia DC has been hosting meet-ups at the National Archives lately. The National Archives has been in the free content business a lot longer than the Wikimedia Foundation, eh. ;-) They know that hacking together a few scripts on Labs isn't going to integrate their enormous collection of accumulated holdings that we want in our projects and that they want to share with the world. Labs _is_ a playground, just as the Toolserver was. Volunteers created some incredible scripts and tools, but how many are still around today? I maintained many scripts and bots for years, but eventually you lose interest, you have other priorities, life moves on, and yet the need for such tools has only grown. >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. If these tools want to be around in five or ten years from now, then I disagree. I've spent far too long watching far too many people walk away, abandoning their previous pet projects. That's certainly their prerogative as volunteers and I don't blame the Wikimedia Foundation or anyone else for their departure, but that doesn't mean there's not a real issue here in terms of creating lasting, sustainable software. This isn't to say that every MediaWiki extension is some garden of Eden where there's no code rot. But at least the current extension process creates a much higher likelihood of long-term success than the alternatives. I wouldn't be so quick to discount it. MediaWiki _is_ the platform, in my view. I wonder: if we relabeled MediaWiki extensions and started calling them apps, would it be easier to sell everyone on the idea of the need for more of them? > - 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]. I'll split this out into a separate thread. >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. Sure, I agree with this as well. And thank you for laying out some of the work and progress that has been made in the analytics area. It was a very interesting read, as was the information about (among other things) improved graphs support. >I would caution against requesting WMF to work on highly specialized >solutions for highly specialized problems. Nobody is suggesting this. I'm all for both strictly evaluating the need for new tools and for developing generalized solutions for maximum impact. MZMcBride _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
