Engineering Community Team/2014-15 planning

In person at Zurich Hackathon

• ECT goals / purpose currently: https://www.mediawiki.org/wiki/Engineering_Community_Team#Purpose
• Sumana sees four contributor pipelines: devs, testers, sysadmin, PMish (triage, docs, PM)
• proposes to concentrate on the first two pipelines
• make steps for developers discoverable from gadget on local wiki to code/extension in global
  • discoverability both technical and social
• Can people find answers to their questions? (e.g. getting answers on IRC, discoverable FAQ)
• define 'success' as high-level, define areas where nothing is done (focus on), make hard traces for stuff we will not do
• partnerships with other organizations; when should ECT be driving stuff and when the specific teams?
  • Good and frequent communication and giving back to FLOSS world; piggyback on good upstream infrastructure (Google SoC, GNOME OPW, WMDE Wikidata); expertise that we don't have to create (FB: Hiphop, Phab); keep an eye out on opportunities like that
• (See photos) Three major bubbles: Community Health (Outreach -> Onboard -> Retention, Switchboard (information brokerage), Partnerships with outer orgs) || Bureaucracy/Platform (Processes (tech & social; like conflict management), tools (tech metrics), documentation) || Events (online & offline)
  • (TechNews more in a future "community engagement" area, which should also run communcation support)
  • Currently everybody's doing a little bit of everything in above three main areas
  • We compared https://www.mediawiki.org/wiki/Engineering_Community_Team#Purpose against the three bubbles above and on the photo
• Current topics as our work
  • GSoC, OPW, GCI, FOA
  • RFC architecture, Data dev hub
  • Phabricator - tools migration
  • Finish Community metrics v1.0
  • Active partnerships (upstream, adjacent)
    • Integrate "usual stuff"/gruntwork here to make it more visible, as it can take up to 50% of day time?
    • To reduce gruntwork involvement, teach more other teams how to work in a way that they need less help from us / more "trusted" (e.g. in Bugzilla)
  • Events: Arch Summit, Hackathon, Wikimania
    • We organize, we help, we send participants
    • Events to focus on? (our own ones listed above, vs others like FOSDEM, OSB, PyCon)
  • Diversity as a common denominator in topics above
• The way we work and if we are content with it, individually and as a team
  • Buddy system / Paired work: Two people involved instead of one (e.g. different paradigms: Pair programming and teaching each other vs one supervising the other, PM Tools Evaluation as a team with skills summing up)
    • Different motivations/methoids; Big/small projects; optional/overhead risk
  • Data-driven goals: Check when makes sense
  • Explain how we work individually
  • Remote work
  • Use as a team to be more structuredly working (than wikipages) via Phabricator, e.g. create dependencies, mark tasks as "can be done by volunteer"?

Whiteboard drawing (1) of the Wikimedia Engineering Community Team meeting at the Zurich Hackathon 2014

Whiteboard drawing (2) of the Wikimedia Engineering Community Team meeting at the Zurich Hackathon 2014

Whiteboard drawing (3) of the Wikimedia Engineering Community Team meeting at the Zurich Hackathon 2014

Etherpad notes

https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Engineering_Community

Last year's goals for reference: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals#Engineering_Community

Discussion about broader goals and strategy is also welcome.

https://www.mediawiki.org/wiki/Engineering_Community_Team#Purpose

Input from Rob

"blank slate" for 2014-15

Rob: Many goals are cyclic e.g. GSoC, OPW, etc. Incremental improvements are expected, but not big changes there.

Rob: Expects more of an emphasis on organizational collaboration and large groups of developers rather than the focus on individual developers; examples: Wikia, WikiHow, upstream

Sumana:

• partnerships with large organizations
• emphasis on diversity - what do we want our contributor base to look like?
• what would success look like?
• choosing upstreams: https://www.mediawiki.org/wiki/Upstream_projects -- https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components conversation is instructive

About NIH: ECT can contribute to help this problem, but we don't need to be the ones solving it. Talking to other organizations, contacts in events, inviting guest speakers in our tech talks... Establish the condition in the best way we can to mix our community, discussions, and plans with the wider community out there.

(Thinking of diversity) Areas to look at:

• frontend people/coding skills
• languages - collaborate better with Language Engineering group to ensure people who speak underrepresented languages get into relevant conversations
• gender
• accessibility - there is already https://www.mediawiki.org/wiki/Accessibility and there are external organizations to partner with, re a11y in tech and a11y in open source
• ethnicity
• economic class

Quim: Can we get more contributors from the Wikimedia (editor) community?

• Andre: More collaboration with community engagement / liaisons?
• Guillaume: with some internal teams, we talk frequently about collaborating but for some reasons we end up working apart. Maybe because we think the cost isn't worth the benefits.
• Sumana: linguistic diversity yes, JavaScript/CSS skills (coding skill diversity) yes, more skeptical about diversity in other areas.
• Rob: many entry vectors: gadgets, templates, bots. This has value in itself. Do we want to set goals in these areas?

New Community Engagement team. Is there anything we should consider now, or do we wait and fine-tune plans accordingly?

• Rob: let's wait.

Rob: Google Code-in was a surprising success. Planning sooner and better will pay off.

GCI, GSoC, OPW... programs to frame the reach out to individual enthusiasts.

Collaboration with partners, universities, SocialCoding4Good ( note from Sumana afterwards: there are hundreds of PHP user groups - http://www.phpusergroups.org/groups.phtml?menu=groups , http://www.zend.com/en/company/community/local-php-groups are two lists. That's an example of a community that we could be reaching out to and partnering with better, perhaps by preparing a canned presentation for them to use)

Walk through community metrics

• would be great to have an understanding of approx. how many distinct people have suggested CSS/JS improvements to MW core or any extensions in, for instance, the last year
• will be good to understand how to read the existing dashboards

Purpose

Revisit https://www.mediawiki.org/wiki/Engineering_Community_Team#Purpose

• Individual developers and organizations.
• Contributions and API.
• Wikimedia and MediaWiki.
• Outreach, onboard, events, processes, tools.

A platform where every activity sums up.

DiY and social

For reference: https://commons.wikimedia.org/wiki/File:Wikimedia_dev-tech_community_funnels_March_2012.jpg