[Wikimedia-l] software projects for chapters, thematic orgs, and others

Thu Aug 29 21:42:06 UTC 2013

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_collaboration_in_Wikimedia_engineering
 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.pdf

According to Arjuna Rao Chavala,
https://wikimania2013.wikimedia.org/wiki/Submissions/Essentials_for_Nurturing_Small_Wikis
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.

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation