Wikimedia monthly activities meetings/Quarterly reviews/Engineering Community/September 2014

Executive summary

edit
  • ECT needs one new member to cover Sumana's departure. Guillaume is changing teams, but he carries his current responsibilities with him.
  • Metrics: our Gerrit review queue keeps growing. What should we do?
    • ACTION: Quim to discuss the data with Team Practices and other stakeholders to propose next steps.
  • 2014-15 main goals haven't changed: I) A sane developer experience, II) One developer platform, and III) Engage established communities.
  • Phabricator migration is progressing well. We agreed to relax the deadlines a little, in exchange for higher quality and better communication. We expect WMF teams to migrate from Trello and Mingle by the end of 2015.
  • The Data & Developer Hub project had too-scattered resources even before Sumana announced her resignation (Moiz's 20%, Juliusz left, Stephen LaPorte volunteers). The current plan is not feasible with the current resources. The priority of this project needs to be reassessed.
    • ACTION: Moiz to continue leading the work on the prototype, finding a short-term solution to improve https://doc.wikimedia.org with best practices applied to selected APIs.
    • ACTION: Quim to propose a mid-term plan with consistent priorities, goals, and resources.
  • MediaWiki Developer Summit 2015 ready to open registration. Focusing on architecture decisions and WMF Engineering 2014-15 goals.
  • GSoC and FOSS OPW brought good results regarding project completion, but we are still struggling to retain interns as volunteers. Let's treat them explicitly as hiring recruitment pipelines.
    • ACTION: Quim to drive discussion volunteering vs hiring.
  • Engaging established communities work delayed, since we had to put our attention on Developer Hub and the new relationship between ECT & Wiki Release Team. Inviting them to Tech Talks as an easy way to start.
    • ACTION: Rob to help Rachel finding speakers from established communitites for our tech meetings and events.
  • Architecture RfC process management transferred from ECT to the Architecure Committee.
  • Wiki Release Team relationship own by ECT, not planned in the last quarter. ECT can handle

the project and social aspects, but we cannot be responsible for the QA of MediaWiki releases.

    • ACTION: Quim to clarify who assesses QA for MediaWiki releases.


Meeting notes

edit

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Engineering Community team, September 15, 2014, 11AM - 12:30PM PDT.

Present:

  • Lila
  • Jared
  • RobLa
  • Rachel d
  • Rachel F
  • Erik M
  • Moiz
  • Katherine M
  • Greg g.

Participating remotely:

  • Sumana
  • Tomasz
  • Quim
  • Brad
  • Guillaume
  • Andre

Please keep in mind that these minutes are mostly a rough transcript of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material

Agenda

edit
  • Team Introductions (QG) - Slide: *Purpose,* Slide: "Team"
  • Team member self Introductions: Rachel F, Andre, Sumana, Guillaume
  • Team ready for new member
  • Short review of last quartlerly review (QG)
  • Slides: *Metrics* - Overview - (Every month approx 180 Git contributors about half WMF Employees)
  • (LT) Measured in number of people not contributions?
  • (QG) Number of people.
  • Slide: *Code review queue"
  • (LT) ?s Do request close and get opened again? Or, do they wait
  • (QG) Blue line is total amount of changesets; Green line is the subset waiting for review (no -1, no work-in-progress).
  • (LT) What is the average time?
  • (RL) It can be long.
  • (Sumana) There can be variation, wide distribution; some reviews (especially within WMF) happen in minutes, some take weeks or months.
  • (LT) How do people decide how contributions will be worked on or how or they separated (submitting)
  • (RL) (submitting) Can be contributed anytime
  • Further discussion of volunteer contribution planning
  • Slide (QG) - code review queue
  • (LT) From April to Now there is a 4-5x increase in open contributions. Can you explain?
  • (QG) Current backlog of open reviews and when they were submitted
  • (LT) We should have a mechanism to close them
  • (EM) What are the next steps for changes and prioritiization?
  • (QG) Once the data is collected then there should be discussions (will return to the topic on wikitech-l with more precise #s as time goes on)
  • (EM) ECT and Arthur's group may want to partner on team level health measures
  • (QG) We are participating in their survey to assure that this factor is taken into account.
  • (LT) Ongoing requests and what they would like to change?
  • (Sumana) Offers more conversation and discussion over the next couple of weeks - especially to discuss

https://www.mediawiki.org/wiki/User:Sumanah/Launchpad-dev-process , 20%, LevelUp, and other past discussions & initiatives, and lessons learned

Mid term plan

edit
  • Slide: *Midterm Plan* (QG)
  • Slide: *Development Platform*
  • Slide: *Engage established communities*

Short term plan

edit

Phabricator

edit
  • Slide: *Short Term Plan* (Andre)
  • Software discussion: Bugzilla, Trello, Mingle, Phabricator (tech and nontech uses), product managment will move to Phabricator in next quarter
  • (QG) Help is needed. Teams are working on Trello and Mingle, and they may continue if no one is telling them to move over to Phabricator.
  • (EM) Many teams are ready to make the switch.
  • (RL) It will be a good problem if Phabricator is ready for more usage

Data & Developer Hub

edit
  • Slide: *A Sane Developer Experience" (Sumana)
  • (Sumana) Hunger for Improved documentation around the MediaWiki core API (data, data visualization, service oriented architecture aspect); this past quarter we had not-quite-resolved discussion about what the platform would be, whether we'd focus on internal WMF needs or researchers/3rd-party needs, and how we would manage updates/content contribution (mediawiki.org edits or some other method?)
  • (QG) Those expectations and vision did not match available resources. We need to revisit either vision, priority or resource with consistency. (Are we a platform or a destination?) What are the next steps? Feedback?
  • (MS) Screen Share: Began as 20% project, building prototype (not on mediawiki), cleaner design, shared mock-ups
  • (LT) Where do you want to go with this?
  • (MS) Build mediawiki.org - not as concerned with internal members but with the bigger community, which is why it is more visually friendly...
  • (LT) How does it look now?
  • (RL) Documentation available on API.php, Mediawiki.org - basically wiki pages, (Some work has been done on styling and embedding)
  • (LT) What is the formatting based on?
  • (MS) Sumana, Stephen LaPorte, Dario T. and Moiz
  • Further discussion of source this is developed against (From monolith to dedicated services, getting documentation right, etc) Making accessible, high qualility API documentation for certain parts of the system.
  • (EM) The question Quim is asking is what can the ECT team do to make this successful?
  • (MS) Focusing on two APIs
  • (LT) Do you want to engage community members
  • (MS)
  • (QG) Discussion of prototype - This is based mostly on volunteers. Deliverables, missing a technical writer and developer
  • (LT) Someone needs to scope the project
  • (EM) If we want to support the minimum we need is QA on the first release and it meets the needs of the initial APIs. Is the concern that this should not happen or that it should just remain a prototype?
  • (QG) The concern is putting too much on the prototype
  • (LT) Is the concern that this needs to be a project with a project management?
  • (QM) We need to work on development.
  • (LT) Before that we need to work on the plan / scope
  • (RL) We need a development strategy. Recommends Brad. When we have a new site - what technology are we going to build that on?
  • (LT) We need to take the conversation out of this room and figure out the parameters and priorities
  • (EM) Takeaway: We should be able to deliver something that should be easily transferred; there should be a compromise.
  • (JZ) Instead of a larger organized API hub, build out the individual page for new APIs?
  • (LT) Basically, all new APIs would use this moving forward starting with the two being supported right now?
  • (EM) Maybe, maybe not, explains
  • (LT) We need to be really clear what that means in practice. Do we actually have a real plan moving forward for whether this will survive?
  • (EM) Though we do not have the resources for the bigger hub, we should support better documentation for when we do
  • (JZ) Setting up best practices for a particular format

MediaWiki Developer Summit

edit
  • Slide: RF MediaWiki Developer Summit 2015 (RF)
  • New this year, a combination of the Architecture Summit, Tech Days, and the SF Wikimedia Hackathon.
  • Do we agree on goals? What are they? How do we message to community and internal staff?
  • (EM) Order of importance: Architecture summit, hackathon, tech days -
  • (RL) Hackathon that we had was geared toward new people, while this event focuses on current developers.
  • (EM) Focus on engaging people we still have in the dev community
  • (LT) Must leave for another meeting
  • ACTION ITEM: Quim/Rob to send out exec summary for everyone (esp. Lila)
  • Discussion of the purpose of the hackathon
  • (RL) We want to have a discussion when people are already ready
  • (RF) Anyone who wants to attend has to register (WMF employees included); they need to justify why and how they can contribute
  • (JZ) Had we ever had less technical days that precede the hackathon
  • Logistical discussion of the events and content

Outreach programs

edit
  • Slide: *Outreach Programs* (QG)
  • We have a problem retaining volunteers after the internship ends.
  • (Sumana) ? about focus on retention: are we focusing on retaining interns
  • (RL) What are the commonalities between the ones who stay? Are there cases of people staying that we did not hire?
  • (Sumana) has intuitions but would like to gather thoughts
  • (EM) If we see OPW as most successful for recruiting we should partner that more strongly with recruiting. The reality is money is part of the equation.
  • (QG) mixed thoughts about internships being a preamble to hiring
  • (Sumana) we kind of do a shitty job of handoff. Most mentors are not having clear wrapup conversations and setting up plans regarding continuing contributions w/interns
  • (QG) How to close the loops, and how to sync best with HR.
  • (EM) We need more discussion about hiring vs volunteering
  • Discussion of hiring vs volunteering and agreement to discuss in the future
    • ACTION ITEM: Quim to drive discussion volunteering vs hiring.

Engage established communities

edit
  • Slide: *Engage established communities* (QG)
  • (RL) Thinking about different tech talks (not just internal), one of the easier opportunities
  • (EM) Agrees
  • (RF) Who is the best person to go to?
  • (RL) Offers to help
  • ACTION ITEM: Rob to reply to Rachel's email soliciting internal talk ideas to also point out external guests

Current quarter

edit
  • Slide: "Current Quarter" (QG)

Other highlights

edit
  • Slide: "Other Highlights" (QG)
  • (RF) Hackathon information, working on focus on making it easier for new attendees, as well as logistics
  • GSoC and FOSS OPW (QG)
  • Sumana: case study of a good OPW internship: http://www.harihareswara.net/sumana/2014/08/13/1
  • Slide: *Achievements* (QG)

Final Topics

edit
  • (Sumana) Offers time for braindumps before 30 September