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
gather information about needed functionality to advise on products
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
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?  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
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
. 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
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;