Subject: was Re: About the concentration of resources in SF (it was: "Communication plans for community engagement")
Let me start off by saying: Different chapters, thematic orgs, etc. have different levels of tech expertise, and there is enough work for everyone to have some if they want. :-)
People who are experts in reading, editing, proofreading, uploading, teaching, etc. with Wikimedia sites can help by pairing with developers to mentor interns, and can test proposed changes to see if they work. People who are interested in dabbling a little and learning some of the technical side can sponsor audits, do community liaison work via https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors, and gather information about needed functionality to advise on products https://blog.wikimedia.org/2012/11/21/lead-development-process-product-adviser-manager/. People who can code a little bit can improve, translate, and port gadgets and bots and Lua templates, or even fix bugs in MediaWiki, and then move on to one of the "mentored projects" ideas as a next step. And groups with a lot of technical expertise can follow Wikimedia Germany's example with a big project like Wikidata.
All of these are ways to make a difference.
On 07/28/2013 03:31 AM, Erik Moeller wrote http://lists.wikimedia.org/pipermail/wikimedia-l/2013-July/127237.html : ...
So, how could this work for a Wikimedia chapter? Perhaps as a new diversity outreach program run by the chapter, inspired by OPW? Or perhaps integrated with OPW, if GNOME Foundation is open to it? Or a completely different approach, e.g. learning from Etsy's efforts to increase diversity by partnering with Hacker School? [1] I don't know
- but I think it's worth experimenting with.
I do think it's something a small org could pull off, because a lot of it is about communication/coordination more than about managing a complex cross-disciplinary engineering effort. And it's perhaps a good way for a chapter, too, to get familiar with some of the intricacies and complexity of doing engineering work in our context without committing yet to building out a full-on tech department.
The important part is that we connect people new to our ecosystem with capable mentors/reviewers -- whether those are experienced volunteers, employed by WMF, or employed by a chapter that's already doing engineering work like WMDE. Without that mentorship support, it doesn't work.
Quim and others have continued talking about the specifics of using mentored projects as a place for Wikimedia organizations (chapters, thematic organizations, etc.) to start. Quim, on the mentorship project ideas http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects :
I don't see why the chapters couldn't consider this list as a source of inspiration for software projects they could sponsor. They don't even need to have the technical capacity in house: we can help finding the right mentors for each project and we can also help selecting the right developer(s) - like we do for GSoC / OPW.
I agree! And I'd love to see this happen. But that's not the only way. I want to go back to Erik's idea and think about diversifying the whole software development process. I'd love to see chapters, thematic orgs, and other Wikimedia organizations helping get diverse voices and talents involved in information-gathering, in improving our plans about what to build, in testing prototypes to make sure the delivered software suits the needs of the movement, and so on.
For instance, check out https://www.mediawiki.org/wiki/Accessibility#People_and_organizations_working_on_MediaWiki_accessibility . It's helpful that WMDE is currently contracting with Marius Hoch, who is fixing accessibility-related bugs. But it has also been useful (in my opinion) for all the other people in that list -- from WMIT, WMDC, WMDE, WMFR, and others -- to hold workshops, fund and manage audits, write guides, and so on! All of these have helped make our sites more accessible.
Similarly, what WMUK plans to do with Wikimania next year https://wikimania2014.wikimedia.org/wiki/Outreach -- reaching out to larger tech communities and bringing them to Wikimania, cross-pollinating us all together -- will help the movement's tech progress. It'll be great to have more opendata/bigdata and design experts reusing our work, suggesting improvements, and perhaps joining us longterm.
Phoebe wrote:
On this topic, one thing that was brought up in the Board elections questions & answers was the (ongoing) need to triage feature requests by the community, including especially requests for features from experienced & admin users, and feature requests from the sister projects.
One of the ideas in the candidate answers was to focus more on building a central place where feature requests (and cool existing tools) can be shared between language editions and projects, and where feature ideas could get refined outside of bugzilla & the lists; another idea was to build a kind of technical committee to help collect and refine these ideas. Then of course there is the actual technical work of addressing these requests.
I don't know if working on this would fit in with what any of the chapters are doing, but it does seem like a social/technical/community area that could use some energy.
Check out the notes from the Engineering Community Team's Wikimania session https://wikimania2013.wikimedia.org/wiki/Talk:Submissions/Transparency_and_c... to see some ideas of where this is already happening -- Quim also talked about that in this thread -- and how we're encouraging people to participate. Our team's happy to help guide people who want to learn how to do this kind of liaising, triaging, and sharing.
Daniel Mietchen discussed porting and maintaining tools like Citation bot:
I could imagine that certain types of bots, tools and gadgets would benefit if handled and developed with support from a chapter.
...
due to ongoing developments in other areas (e.g. citation templates), adaptations are necessary on an ongoing basis. Who should do that? And what about feature requests?
Some bot owners manage to handle all this on their own, but having support from a chapter for such things (on an opt-in basis) or for feature requests from the wider community would probably be widely appreciated.
to which John Vandenberg replied:
Is there a list of such tools that have been identified as needing paid support?
I believe Silke Meyer of WMDE is the best person to speak definitively about this so I'll defer to her. But yes, I would love for more Wikimedia organizations to customize, maintain, port, translate, and otherwise improve bots, tools, and gadgets.
Here are some instructions regarding documenting, localising and porting templates and gadgets -- written by one of our past OPW interns:
https://www.mediawiki.org/wiki/File:Extension_cite.pdf
https://www.mediawiki.org/wiki/File:Documenting_noteworthy_local_templates.p...
According to Arjuna Rao Chavala, https://wikimania2013.wikimedia.org/wiki/Submissions/Essentials_for_Nurturin... it's really helpful to smaller Wikipedias to help them adopt tools like HotCat and Twinkle and bots.
Nemo wrote on Aug 24:
I offer myself as example of bad responsible for a small technical project by a chapter (WMIT) some years ago. We managed to help Kiwix a bit but we miserably failed with (Wikisource/Wikibooks) books management improvements: at some point I no longer had the time and mental strength to discuss and make decisions about the money the board had trusted me with; when I finally got the board to replace me, we failed to get the new responsible begin and restart/complete the job, till the board/assembly removed it from the annual budget.
Nemo, I'm glad you mentioned this problem. What do you think would be necessary in order to make future WMIT tech initiatives successful? Mentorship from more experienced IT project managers? Frequent check-ins to find dropped tasks faster? Paid contractors for engineering or administration? I'm just giving ideas - maybe you have an idea of what you would do, if you could do this over again. (And thank you for trying, and for talking about failure openly.)
I hope this is helpful (though long!). And thanks to Markus Glaser and others who spoke with me at Wikimania to think through a lot of this.