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