MediaWiki

Engineering Community Team/November 2013 Quarterly Review

< Engineering Community Team
Slides complementary to this wiki page

Summary

edit

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

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.

Last quarter review

edit

This content complements the presentation slides.

Bug management

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

Technical communications

edit

Focus on VisualEditor community change in July−August:

Perennial activities:

 
Presentation (PDF)

Mentorship programs

edit

Volunteer coordination and outreach

edit

Planning

edit

See Engineering Community Team#Planning.

Meeting minutes

edit
Extracted from etherpad
Present: Howie Fung, Quim Gil, Terry Chay, Erik Moeller, Rob Lanphier, Andre Klapper, Philippe Beaudette, 
Guillaume Paumier.

2013-11-15

## Summary (Achievements)

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

Some GSoC students now Code-in mentors

### 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

### 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/

### Bugzilla

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

## 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/commitment 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.

## Planning

### Focus Areas

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


### 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.
    
### 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.

### 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.

### 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).


### Promoted Goals

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

### 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.

### 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]. 

## 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 developer 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.
Retrieved from "https://www.mediawiki.org/w/index.php?title=Engineering_Community_Team/November_2013_Quarterly_Review&oldid=4899840"