[Wikimedia-l] About the concentration of resources in SF (itwas: "Communication plans for community engagement"

[Federico Leva (Nemo)]

Thanks for replying here.

Quim Gil, 23/08/2013 23:55:
> Not exactly what you are asking for, but
>
> http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
>
> are thought to be projects that an intern could develop in about three
> months. We use this list for Google Summer of Code and Outreach Program
> for Women. It *might* be also a source of inspiration for Individual
> Engagement Grants.
>
> I don't see why the chapters couldn't consider this list as a source of
> inspiration for software projects they could sponsor.

Well, I see several possible reasons.
1) Some of them are definitely WMF-specific, like the bugzilla 
improvements. No reason for a chapter to even touch those.
2) Others rely heavily on WMF to be put in use, or interact/overlap 
heavily with current work by WMF. The list is very good because it 
provides a) proof of interest by WMF, b) a mentor who serves as contact 
with WMF to keep things on track and avoid clashes. However, several of 
those projects, if completed, could still sit on a dead end like many 
GSoC projects in the past. The WMF can afford that because some degree 
of failure in GSoC is part of the game and even a "failed" project is 
supposed to grow the developers community, but when you pick just a 
single project or two then as a chapter you just feel like wasting money.
3) In general, it's not obvious how to fit one such project in the 
plans/goals/strategy of a chapter. Projects benefiting the whole of 
Wikimedia projects (like e.g. VisualEditor or i18n do) have been 
declared to be in the WMF's scope rather than in the chapters'; that's 
been mentioned as a reason to kill the Toolserver, for instance. 
Typically, a chapter would be interested either because "its" language 
communities have a particular interest in something, or as a part of 
some other project of the chapter (Commons improvements are probably the 
easiest to fit in here).

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

This is indeed helpful, however a chapter will still need some degree of 
technical competency to assess the project and its fitness to the 
chapter's goals, see (3).

>
> Chapters "graduated" at this level could consider embarking in bigger
> software projects. Pulling out a Wikidata team (or even a Kiwix project)
> isn't trivial at all and I'm personally impressed by these success tech
> stories lead by chapters. We should have more! (or at least try) There
> is no lack of work to do.
>

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