Engineering Community Team/November 2013 Quarterly Review

Summary
The Engineering Community team presented a change of plans, demoting goals related to QA volunteers and promoting goals related to Project management tools.

ACTION (Quim/RobLa): resourcing plan for implementation after the assessment.

The activity of the team now concentrates in four focus areas:


 * Technical collaboration tools
 * Technical communications
 * Upstream collaboration
 * Outreach programs

An open question was asked, about better collaboration between ECT, Product Management and Community Liaisons. We agreed to increase dialog and collaboration through simple steps, without changing current responsibilities and activities.

Bug management

 * New guided Bugzilla bug report entry form for Bugzilla newcomers (36762)
 * "Inline History" displays bug report field changes (priority etc.) in-between comments (47256)
 * Small enhancements: "Show other bug reports in component" link (46413), longer product names in buglists (40244), ...
 * BZ tricks & best practices blog series (see Bug management)

Technical communications
Focus on VisualEditor community change in July−August:
 * Creation of translatable documentation and how-tos, like Help:VisualEditor/User guide, Help:TemplateData, Help:Screenshots
 * Coordination of communications (e.g. announcements)
 * Direct liaising with the French Wikipedia: responding to feedback, reporting bugs, etc.

Perennial activities:
 * 9 technical blog posts reviewed and published;
 * 3 monthly engineering reports assembled and published;
 * 7 editions of the tech newsletter published, translated into about 12 languages every week and globally delivered across wikis



Mentorship programs

 * 18 out of the 20 Google Summer of Code projects passed the program evaluation, as well as the one Outreach Program for Women project (announcement - OPW blog post)
 * 36 mentors involved from beginning to end.
 * Status of each GSoC project can be found at Summer of Code Past Projects.

Volunteer coordination and outreach

 * Introducing a dashboard (alpha) for tech community metrics: Git/Gerrit, Bugzilla, MediaWiki, Mailman, and IRC.
 * Five key performance indicators agreed: Who contributes code, Gerrit review queue, Code contributors new / gone, Bugzilla response time, and Top overall contributors.
 * Key Wikimedia software projects defined as baseline for metrics.
 * Events:
 * Facilitated Browser Testing Automation workshop with Cucumber and Epic fail: figuring out Selenium test results
 * Team presentation at Wikimania: Transparency and collaboration in Wikimedia engineering
 * Wiki devroom proposal for FOSDEM 2014 accepted, prepared in collaboration with XWiki and Tiki.
 * Support in the organization of the MediaWiki Architecture Summit 2014.

Planning
Engineering Community team goals have been updated after the quarterly review.

See Engineering Community Team/Meetings.

Meeting minutes
Present: Howie Fung, Quim Gil, Terry Chay, Erik Moeller, Rob Lanphier, Andre Klapper, Philippe Beaudette, Guillaume Paumier.

2013-11-15


 * 1) Summary (Achievements)

but a trend]
 * 1) about 3x GSoC+OPW from previous: about 18 out of 20 "passed" [future: make sure it's not an exception,

Some GSoC students now Code-in mentors


 * 1) Support for VE launch, notably Frwiki

Guillaume: For the last quarter on community change team 2 out of 3 months, created and translated documents, supported communications + reviewing blog posts, etc. In Sept resumed official duties.

Philippe: He was an amazing help


 * 1) Community metrics dashboard

Quim: 2 pieces that were needed were made. 1) KPI (who is contributing + affiliations and location) 2) a list of key wikimedia software projects http://korma.wmflabs.org/


 * 1) Bugzilla

Andre: reports automatically synced to Gerrit via PATCH_TO_REVIEW status (before it was keyword and not linked to Gerrit, done manually)


 * 1) Lessons learned

1. QA volunteers was a top priority for ECT: * We've had good results (there is a QA mailing list with active participation, got a hire from the list), but at this point, it is not worth investing so much time in this task; diverts focus).   * A year ago manual testing was the focus and it was an easy one for newcomers, but now with automated testing it is not the case anymore.    * more professionalization in the audience Erik agrees: focus of ECT should be less on QA and more on bug tracking etc. (e.g. PATCH_TO_REVIEW)

(example of recent activity that ECT will continue working on: helping PyWikiBot moving from SourceForge to our infrastructure.)

Erik: Is that in the updated goals page? Quim: Yes, we are proposing that today.

2. Disparity between goals and actual work

We really need to put time/committment to new features and tasks (perennial work diverts from that). Another element is that even though we are a team, because individuals have separate focus there is not team focus areas, and we could get more out of collaborating more.


 * 1) Planning


 * 1) Focus Areas

1. Technical collaboration tools: e.g. Bugzilla currently (bug reporting, project management) 2. Technical communications 3. Upstream collaboration 4. Outreach programs


 * 1) Tech collaboration Tools

Andre: vs. tech collaboration tools. We have bugzilla, Mingle, Trello, RT, toolserver, etc. + interest in Redmine, PivotalTracker etc. Last evaluation was in 2009/2010. Have some agreement among stakeholders a la Gerrit discussion. Plan: Steps, schedule, defining stakeholders for input, analysis of current problems, scope → preselect limited # of tools (a la labs instances) [Jan 2014?] Basically process similar to how we collectively selected Gerrit as code review tool

Erik: I don't think anyone will agree on one tool. 1) Are you considering consolidation of Bugzilla and RT to be within the scope?

Andre: They are. Been in a little contact with Ken Snider on this. Some discussion on ops-l in December 2012?

Erik: Any significant change here isn't a one person project (importing, testing, etc.) It's a huge churn to even try out a tool. Could be a platform engineering or joint project at some point. What is the thought on resourcing?

Andre: Have discussion on teampractices list supported by a wiki page. And have team of stakeholders to help define the MoSCoW.

Erik: After?

RobLa: I don't have a good answer for that.

Erik: Be careful because it will fall in on Platform's plate.

Quim: The goal is to have shared assessment and agreement.

Erik: It makes sense for ECT to be the group to do the assessment (scope, requirements). Not just community but tools also. But, we can't skip the "what are we going to do with that?"

RobLa: There is a tooling contractor budget.

Erik: Look at exploring people in the job candidate pipeline and get them started on this now (get them on labs, etc.). [idea: assessment can only go so far without technical resources]

ACTION (Quim/RobLa): resourcing plan for implementation after the assessment.
 * 1) Technical communications

Guilaume: Continuing to support the engineering team (blog posts, monthly reports) + technical newsletter (translation, compiling) + increase bus factor on this [had 1 volunteer in the past]. Main goal is to find several people to run the newsletter with or without me. Have infrastructure: manual, sources of information list, etc.


 * 1) Upstream collaboration

Quim: We have goals but we want a permanent area to work on. We are an island in the map of the free software community. The connections are done by single people instead of a strategy as an organization. 2 sides: 1) OS projects we are using 2) projects we are developing that we want others to use.

RobLa: ex. web performance meetup/WG. Have a joint meetup with them (with Ori's help). Discovered because Derby/HR system happened to be the hosts of that at some point.

Erik: Meetups are always the way to do that. I miss the regular tech brownbags: that sharing. We should get back in the habit of getting back into that.


 * 1) Outreach programs

Quim: Slight change of wording. We've been calling them "mentorship programs". We get involved not to mentor but to reach out to volunteers and contributors. Also related to upstream collaboration. All the tasks that these candidates/interns are trying to complete are the same as any newcoming (focuses us on fixing documentation, etc. for onboarding/inviting newcommers).


 * 1) Promoted Goals

1 Plan for project managent tools 2. Consolidate Tech News 3. Index of key upstream projects. 4. Code-in


 * 1) Demoted Focus

Erik: What was taken off the table?

Quim: Will show a diff.

1. QA volunteers 2. QA analysis of gadgets and bots 3. Weekly deployments (part of this is Greg's virtual team, Andre still participates on virtual team) 4.Toolserver migration (something Sumana started, + Silke from wmde, today we're not following that and wmde is progressing forward)

(mention of Maps infrastructure)

Howie: More discussion of gadgets and bots?

Quim: The idea was to analyize gadgets and bots to start activities for test automation to avoid bugs produced with combinations with new deployments.


 * 1) Diff

(this quarter)

- Dozens of toolserver tools have moved to Labs - QA analysis of gadgets and bots + project management requirements and potential tools + google code-in + grow tech news […]

(next quarter)

- volunteers write tests for gadgets and bots + project management tooling plan started + architecture process and RFC queue clean FOSS OPW reach out to FLOSS projects we rely on tech community metrics to find focus areas

Erik: what is the specific outcome expected from the technical writer to be hired? RobLa: The main deliverables would be the architecture document itself, the RFC process explanation, pipleine to turn RFCs into technical documentation].


 * 1) Questions

1. Should the EC team coordinate with Product Management and Community Liaisons in their interaction with Wikimedia communities? 2. Should these teams share goals related with deployments of new features in Wikimedia projects?

Erik: (discussion of promoted goals). Scrum of Scrums give good visibility into stuff (upstreaming? esp. with licensing issues). Given the promoted goals there isn't as much need synergy with PMs.

Howie: In areas where there is a deeper connection, we can do that. Ex. when/if Flow works on Workflows that is a good place.

Quim: More tactical than strategic.

Erik: Strategy can come into play for big upstream pieces (ex. VE in WordPress? Most of cE based libraries are kind of crummy even vis-a-vis VE. To partner with projects is a big deal. ex. PLoS revamping editing environment). We could raise visibility on pieces that are out there (ex. jQuery IMe libraries: PLOME, etc.)

Quim: One approach is to lend someone for a period of time. But this at the end of the process. The question is the projects started as OS projects, maybe we can help throughout the process.

Quim: e.g Flow. Strategy of presenting Flow to future users. How is the strategy being defined? Where (mediawiki, or wikipedia pages)?

Erik: Traditionally that's been done with community liaisons. ECT has been more developer focused.

Howie: That's been the dividing line. CL and community manage with the community for the rollout, while others is a relationship with the develioper community?

RobLa: The transition from 0-100% responsibility. A feature goes out there, now Andre is on board for collaboration going on board. He has insights that might help the process…

Quim: We aren't responsible but are we a stakeholder? This is a software project so it becomes ECT's work.

Erik: Situation like VE where we asked Guillaume to help, should not happen with better planning. There is a CL/CA summit.

Howie: We've had the CLs working on VE and Flow but they never met each other. Want to meet for midpoint retrospective (what worked, didn't work, etc). And develop standardized process and meet the dev teams.

Erik: Observed with VE was binary (out the door). Move toward any complex project has a CA/CL on it from the start to reflect a more thoughtful approach (ex. Fabrice on Multimedia doing village pumps) → consistent parallel communication with the community. There is a subset of that. Where this connect with the ECT team is the bugs. Right now CA/CL adds bugs to bugzilla. Want to flag (ex. template that shows bug on wiki page could show the status of the bug). (actually, that template does show the status, but it requires a gadget to be enabled; it was once enabled for everyone and it crashed bugzilla, or something)

Andre: There is no structured outreach with the CL/CA. Explained to a couple the guided bug entry form.