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