Hi Erik, I would remember that in IEG or PEG there are several proposals of software development but every time these proposals don't offer a well defined approach to the maintenance.
We know that maintenance is an important phase of the software development and it would be good to know if the software will be developed and will remain frozen at the last step or if there will be an idea to create at least a community around it in order to keep it updated and aligned with any future features that can come from the GLAM community, for instance.
To maintain a software is not mandatory and the open license can assure that at least another one can take it in charge.
Anyway a GLAM adopting a software can be really worried if this software becomes outdated, and this risk is higher if the change of this software can have a big impact, and probably the same reputation of the GLAM community can receive a worst reputation.
I think that it should be important if some statements can come from the WMF about the consideration to take care about the *lifecycle* of the software considering also that this is a cost (and sometimes a higher cost in comparison with the other phases).
I think that this may help also the IEG and/or the PEG committee to better evaluate a proposal.
Regards
On Thu, Jun 26, 2014 at 5:54 AM, Erik Moeller erik@wikimedia.org wrote:
Hi folks,
At the Zurich Hackathon, I met with a couple of folks from WM-CH who were interested in talking about ways that chapters can get involved in engineering/product development, similar to WM-DE's work on Wikidata.
My recommendation to them was to consider working on GLAM-related tooling. This includes helping improve some of the reporting tools currently running in Labs (primarily developed by the illustrious and wonderful Magnus Manske in his spare time), but also meeting other requirements identified by the GLAM community [1] and potentially helping with the development of more complex MediaWiki-integrated tools like the GLAMWiki-Toolset.
There's work that only WMF is well positioned to do (like feeding all media view data into Hadoop and providing generalized reports and APIs), but a lot of work in the aforementioned categories could be done by any chapter and could easily be scaled up from 1 to 2 to 3 FTEs and beyond as warranted. That's because a lot of the tools are separate from MediaWiki, so code review and integration requirements are lower, and it's easier for technically proficient folks to help.
In short, I think this could provide a nice on-ramp for a chapter or chapters to support the work of volunteers in the cultural sector with appropriate technology. This availability of appropriate technology is clearly increasingly a distinguishing factor for Wikimedia relative to more commercial offerings in its appeal to the cultural sector.
At the same time, WMF itself doesn't currently prioritize work with the cultural sector very highly, which I think is appropriate given all the other problems we have to solve. So if this kind of work has to compete for attention with much more basic improvements to say the uploading pipeline or the editing tools, it's going to lose. Therefore I think having a "cultural tooling" team or teams in the larger movement would be appropriate.
I've not heard back from WM-CH yet on this, but I also don't think it's an exclusive suggestion, so wanted to put the idea in people's heads in case other organizations in the movement want to help with it. I do want WMF to solve the larger infrastructure problems, but the more specialized tooling is likely _not_ going to be high on our agenda anytime soon.
Thanks, Erik
[1] https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_f...
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
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-request@lists.wikimedia.org?subject=unsubscribe