Volunteer coordination and outreach/ECT Feb 2013 quarterly review

ECT Q1 quarterly review agenda


 * 1) What BENEFITS have we already offered the organization? (where ECT has moved the needle)
 * 2) What LESSONS have we learned?
 * 3) What TIMELINE are we planning for the next 3 months?
 * 4) What INPUT are we seeking? (list)
 * 5) Q&A/discussion.

Benefits
Benefits we offer to WMF:
 * More contributors fixing urgent bugs (hoo, Krenair, PleaseStand).
 * More maintainers reviewing staffers' and volunteers' code (especially Krenair and iAlex).
 * Bugzilla is a cleaner place to operate.
 * Recruiting: of new contractors or staffers came through direct ECT nurturing or outreach.
 * The new beginning of volunteering in Ops (see Dereckson's puppetization commits).
 * Clear, transparent broadcasting of WMF engineering activity.
 * Gain and maintenance of social and political capital that benefits the whole engineering department & the Foundation.
 * The start of a formal volunteer product management practice, benefiting admin tools, Lua, & data dumps.

And of course we offer participation, learning, & influence benefits to the larger community, supporting: As outlined in:
 * Movement goal of participation
 * Movement goal of innovation
 * https://strategy.wikimedia.org/wiki/Product_Whitepaper
 * https://strategy.wikimedia.org/wiki/Strategic_Plan/Movement_Priorities#Goals

Lessons learned

 * Events: big ones should be rare, small ones should be easy.
 * Followup, followup, followup
 * For some activities, lots of little points of contact work better for us than outreach on mailing lists.
 * Lack of Ops time is a blocker, as is the RT usage.
 * Toolserver community is underutilized.
 * Better tools and processes beat nagging for activity statuses.
 * User groups are harder to get off the ground than we'd thought?
 * Moving the needle on volunteer QA takes sustained effort.
 * Volunteers need to be trained in what product management is & how to do it
 * Growing more maintainers is more sustainable than 20% time.
 * WMF engineering doesn't have a consistent understanding and approach to open source development.
 * It's still very difficult for volunteers to get involved in Wikimedia-led engineering projects.

Timeline
March through June 2013:
 * Code review trainings, with Chris Steipp?
 * More volunteers doing directed manual testing
 * Continued shepherding of mentorship processes
 * Amsterdam hackathon for community benefit (skillshare & sprinting)
 * Open Source Bridge for professional enrichment & ecology-building
 * CRM/tracing volunteers

Input we're seeking
We're trying to align the volunteer community with movement goals & WMF goals, but alignment has to be 2-way.


 * Do WMF colleagues understand the community better because of ECT?


 * Are we altering course in a good way to account for the community?


 * Are we achieving our goals better & faster because of community collaboration? Key question!


 * Volunteer product management: should we do it? Who/how? What projects should engage in it?
 * Ideas for activities: where is there no paid PM? What is James working on that's not VE? What about important gadgets, bots, and tools?
 * Where do our community members seem to want influence? Who specifically wants influence? Perhaps we could/should reach out to them?
 * Alignment would be easier to build and maintain if volunteers were directly involved in the annual & monthly roadmap process. Is this conceivable?


 * How can we structure and specify volunteer development opportunities to avoid cookie-licking? (see Happy-Melon's January mail to wikitech-l "[Wikitech-l] LiquidThreads status" http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057401.html )


 * Community's tone. It seems like right now there's a better attitude on wikitech-l than there was 6 months ago; does that seem so to you? Why is this happening? We have some hypotheses.


 * How urgent is it that we spell out the code of conduct? We don't know if the next blowup is around the corner.


 * Engineering communications: how is this working for everyone? What are the big holes in engineering project documentation? Would you prefer the status quo, or an alternative vision? Alternative ideas include:
 * more aggressive outreach to multilingual community
 * get volunteers to write blog posts about their work & to be journalists for WMF
 * open up wikitech.wikimedia.org
 * check what's actually being read via spot checks, "if you're reading this email me" notes
 * offloading more work to Signpost or Kurier?