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

2013-08-30 Thread Federico Leva (Nemo)

Sumana Harihareswara, 29/08/2013 23:42:

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.)

The main problems I can find are those I described (plus the legal 
bureaucracy of contracts/offers); I don't know in general what would 
actually help. An interesting approach is what chapters did with Europeana.

In the specific case, by spending a lot of effort on it I had managed to 
find a solution for all the biggest obstacles; in another period it 
could have just worked. As always, if you rely on a single volunteer for 
something and you don't have a replacement ready, a single moment of 
failure can bring the whole project down.
However, it would have been much easier, had we had internal (or 
internalisable) competence to assess with confidence whether an offer 
makes sense from a technical and financial point of view. It's very hard 
to find it together with understanding of the fitness to the chapter's 
goals and without any COI.



I hope this is helpful (though long!). [...]

Long enough that I almost missed the question to me, especially given 
the 4th subject change of the thread + thread theft via References. ;)

Wikimedia-l mailing list

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

2013-08-29 Thread Sumana Harihareswara
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, and
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? [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 :

 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 -- 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;