Volunteer coordination and outreach/ECT Feb 2013 quarterly review

From MediaWiki.org
Jump to navigation Jump to search

(Notes are on the talk page.)

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[edit]

Benefits we offer to WMF:

  • The contributions of more people.
    • More contributors are fixing urgent bugs (hoo, Krenair, PleaseStand).
    • More maintainers are reviewing staffers' and volunteers' code (especially Krenair and IAlex). March 2012: 1 non-WMF core maintainer. Now: 11.
    • 155 MediaWiki coders active in December 2012, 90% increase, year-over-year.
    • Documentation and discussion: 864 active users on mediawiki.org (performed an action in last 30 days). Bug reporting and triage: about 400 active users in December in Bugzilla.
    • Recruiting: of the 27 new WMF engineering contractors or staffers hired in the last year, 8 came from the Wikimedia tech community, and at least three enjoyed direct ECT nurturing or outreach.
  • The infrastructure of innovation.
    • Bugzilla is a cleaner place to operate; unprioritized bugs in Bugzilla down, and you don't worry there's a random urgent bug that we haven't seen.
    • Clear, transparent broadcasting of WMF engineering activity.
    • Gain and maintenance of social and political capital that benefits the whole engineering department & the Foundation.
    • Constant fresh outsiders' view.
  • Improved onramping.
    • ECT maintains the materials that help new staff get started.
    • The start of a formal volunteer product management practice, benefiting admin tools, Lua, & data dumps.
    • The new beginning of volunteering in Ops (see Dereckson's puppetization commits and the 69 active users on labsconsole wiki in the last month.

And of course we offer participation, learning, & influence benefits to the larger community, supporting movement goals as outlined in the Product Whitepaper and Movement Priorities:

  • Participation: More contributors! (Although we've struggled to improve diversity.)
  • Innovation: Prototypes (SignupAPI), training (Git), best practices (LevelUp, testing)

Lessons learned[edit]

  • We are better at helping willing volunteers contribute usefully as developers and testers than as designers, product managers, or systems administrators.
    • Lack of Ops time is a blocker, as is the RT usage.
    • Volunteers need to be trained in what product management is & how to do it
    • 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 WMF-led engineering projects.
  • We are more effective at nurturing the existing community of self-starters than at drawing in new members.
    • 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.
    • User groups are harder to get off the ground than we'd thought?
    • Moving the needle on volunteer QA takes sustained effort.
    • Toolserver community is underutilized.
    • In communications, better tools and processes beat nagging for activity statuses.
  • Growing more maintainers (LevelUp) is more sustainable than 20% time.
    • We have 23 willing mentorships (or similar) this quarter comprising 45 people; this is far more than were eager to do 20% time.
    • It's hard to balance Sumana-as-matchmaker with managers-as-drivers.

Timeline[edit]

What will we achieve?

Now (late Feb) through July 2013:

  • Technical communications
    • Continued communications (blog posts & monthly report & activity statuses)
    • Experiment with volunteer-led curation of tech news (e.g. with Signpost contributors)
  • Volunteer coordination and outreach
    • CRM/tracing volunteers
    • More volunteers doing directed manual testing
    • Formalize and build a contribution pipeline for volunteer product management
    • Tools Labs product advice
    • Amsterdam hackathon & prep for Wikimania talks/devdays for community benefit (skillshare & sprinting)
    • Open Source Bridge for professional enrichment & ecology-building
  • Mentorship programs
    • Continued shepherding
    • Code review trainings, with Chris Steipp?
  • Bug management
    • Continued bug triage & QA assistance
    • Process improvement, including dealing with RT tickets

Input we're seeking[edit]

  • 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?
    • When should we nudge volunteers to work on movement priorities, and when should we use WMF time (frugally) to do capacity-building work to support volunteer interests? ECT tries to work with existing affordances; if a project isn't a good entry point for volunteer developers, perhaps testing, bug triage, and product management could help.
  • What does WMF need to do to improve the volunteer sysadmin & product management/design pipeline?
    • Can the Ops, Product and Design teams structure any of their work to allow for more volunteer engagement?
    • Volunteer product management: should we do it? Who/how? What projects should engage in it?
      • Alignment would be easier to build and maintain if volunteers were directly involved in the annual & monthly roadmap process. Is this conceivable?
      • 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?
  • 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?
  • Community's tone. It seems like right now there's a better attitude on wikitech-l & #mediawiki 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.