Wikimedia monthly activities meetings/Quarterly reviews/MediaWiki Release/October 2014

The following are notes from the Quarterly Review meeting with the MediaWiki Release Management team, October 15, 2014, 9:00AM - 10:30 AM PDT.

Attending

Present (in the office): Lila Tretikov, Damon Sicore, Toby Negrin (until 9:45), Tilman Bayer; participating remotely: Greg Grossmeier, Quim Gil, Mark Hershberger, Erik Moeller, Alexis Hershberger, Chris McMahon, Markus Glaser, Rob Lanphier

Greg: introduction (what the team does) ...
this year we start quarterly reviews, just like we do for internal teams at WMF
Quim: looking at user group for 3rd party user, extension developers
Markus:
welcome

[slide 2]

Agenda

[slide 3]

team members
Mark and I focus on tech stuff
Alexis is keeping track of things...

[slide 4]

annual goals
distribution: this will become more and more important with architecture changes

[slide 5]

Alexis: 3 month overview: snapshot of milestones and what the release team did
flags at top indicate milestones
starting with the beginning of SOW2 (Statement of Work 2), then SOW1, to Wikimania 2015...
at bottom: our four annual goals, +Phabricator ( https://phabricator.wikimedia.org/project/board/26/ )

[slide 6]

Alexis: 13 Month Overview: snapshot of future milestones and what the release team wants to accomplish in the mid-term

[slide 7]

Markus: annual goals

[slide 8]

[slide 9]

tarball release management, support and advocacy

[slide 10]

what we did in Q1
(August: nothing to patch for 1.19)
right version of extension: there was an issue because of simultaneous updates, no damage though
Greg[?]: what's easy/difficult in that dialog?
Markus: conferences are easy, online is harder
interesting issue: a volunteer did work that falls under our responsibility, welcome this but also need to ensure responsibility
Mark: deal with social capital of MW
some people thought our team's role was to impose things upon them
Greg: how to coordinate with volunteers that care a ton about the process and tarball?
Quim: clarify roles and responsibilites to the outside. There are 2 different release teams...
Quim: better documentation of process in findable places
Markus: agree, we actually have better documentation as a planned item for this q (see slide)

[slide 11]

prepare communications for 1.24 release
integrate new process for testing extentions (by Antoine)
certify extensions by some criteria (e.g. having unit tests)

[slide 12]

mid-term goals
RobLa[?]: what is left to do for Antoine (on my team) to make this work?
Markus: we're set for now. But going forward, need: 1. pre-set configuration for extension tests[?] 2. automated installation of extensions for unit tests

need automated extension installation for complex extensions

need to gain some experience, then formulate documentation/tutorial needs[?]
Mark: there's some ongoing work on extension registration which might take care of some of this

[slide 13]

Markus: Release question: Should we take on more responsibility for features included in release?
Robla: caveat - whatever team commits to, it should be high quality, if overstretched say "no". That said, curation of extensions [selection] in installer, and polishing of installer itself, is absolutely in scope. WMF won't (for the most part) be able to do this.

[slide 14]

Mark: new formats of distribution, we shift MW around service oriented architecture
still expect tarball to be important

[slide 15]

new format
Erik: Vagrant is not inherently container-driven or not (uses Puppet + VirtualBox by default, can use Docker/containers using Docker provider). Instead of doing something completely new, how about doing a "stable" release version of MW Vagrant. Have you looked at Labs Vagrant ( https://wikitech.wikimedia.org/wiki/Labs-vagrant ) ? Deploys MW to remote VMs (in our case, OpenStack).
Greg: underlying format can be swapped out pretty easily in Vagrant, reuse puppet manifests
Mark: concern: puppet harder to pick up for new developers, compared to e.g. Salt
Greg: yes, but advantage of Puppet (right now): momentum
Erik: (on chat) https://docs.vagrantup.com/v2/provisioning/salt.html Vagrant supports provisioning via Salt
(?): Who are the customers of release management group?

[slide 16]

[slide 17]

(Mark:)
New format questions

[slide 18]

Markus:
MW cooperation

[slide 19]

good news: there are already some existing people..,
group won't implement MW features itself, but will facilitate it

[slide 20]

[slide 21]

user group in Q1
AffCom is positive about overall concept
name might change

[slide 22]

membership numbers continue to go up
(as measured by signups on the mw.org page)

[slide 23]

categorization of current members:
top 3: ext developers, consultants, corporate users
these are exactly who we target

[slide 24]

user group Q2
at SMWCon, people understood our role fairly well
at WikiCon, people found it hard to understand we're not responsible for e.g. Wikisource

[slide 25]

user group: mid-term
stretch goal: 3rd party users track at 2015 hackathon

[slide 26]

Community building

[slide 27]

Question: WMF view on user group?
decided to start small (not "MW foundation"), but one idea could be an entity that takes over control over MW
Damon: (question about group form)
Markus: there are two kind of user groups: editors (content contributors), and MW (software) centered
Damon: who are the customers of the rel man group?
Markus: everyone who uses MW as software
essentially it's about the process to get changes out - WMF's internal deployment process vs. external releases
Damon: does team have a mission statement
RobLa: in some (bad) sense, it's the contract ;)
Damon: improving MW in some sense seems to be a vague goal...
but why are release improvements going to facilitate improvements in MW itself? [need to spell that out]
I'm familiar with MW tarball installation
it's very limiting. It takes a particular kind of person to install MW
good reasons for that, but...
Whose life is this going to make better? ;)
Markus: third-party use of MW is byproduct, WMF essentially develops for itself
Still understanding needs, I see it as community process
Damon: I imagine there are large user bases out there
do we see demands from them? Why aren't they banging on MWF's door?
Mark: some estimates that 10% of companies use MW
but there is no channel for them to communicate back to (core) MW devs
I have a client who basically forked 1.13 and integrated ContentHandler with it, now they are stuck with that
they're not banging on WMF's door for whatever reason
"here's the tarball, now you're on your own"
Greg: people usually have either inhouse expersts or consultatns
so I'm wondering if we need to target these consultants, instead of their clients
Lila: do we have an understanding of the existing reuses?
Markus: There is https://wikiapiary.com/wiki/Statistics
also, plan to do an environmental scan
Lila: when people download or install MW, do we ask for email address?
Markus: no
Mark put up an RfC about optional registration
Erik: Wikiapiary does a lot of that data collection work on opt-in basis, should work with them
Lila: agree that that would make sense, we want an idea of what versions deployed, where deployed
also, who are the vendors?
And, how to best collaborate?
overall goal: want community to grow
reusers should have a way to talk to us, clear communication channel
Markus: plans for the environmental scan?
Alexis: had a lead on working with Berkeley School of Business which did not work out, the school is currently working on another project and may not be available during our timeline.
Back in August the team had developed a simple plan (Plan A) but we pushed it aside to pursue the Berkeley lead.
The simple would focus on STEEPLE, pretty much PESTEL but put focus Social and Technology on top
We cannot do a full environmental scan, the unknowns are too big
Quim: this team does not have resources to ..
Damon: I don't have much context, but: user group seems a bit like a hammer looking for a nail
clarify mission
other release groups I've seen have been driving specific patches, triaging them
Greg: setup might be confusing . There is still the WMF release team
This team is focused on tarball. Not like any other organizations I'm aware of
It was a byproduct of our existing process
goal now is making it more than that
Erik: historically, there have been several recurring pain points:
installer poorly support
keeping an existing MW installation up to date is a pain
also: for e.g. VE, we increasingly ask users to install additional dependencies, say node.js
Looking at what other projects like Drupal do - they haven't solved the problem yet either (although Drush is neat: https://github.com/drush-ops/drush )
need to prepare for that future reality
Damon: agree
my first question was "how do you improve a tarball?!" ;) but then I saw team is looking at other tools/formats too
wondering about update process, also for security reasons
is there a dashboard [of upcoming releases/features/patches]?
would expect security patches being called out
team should be "train conductors", guide things on time every time, also push updates on users
Markus: agree on several points, but hard to implement in current situation [?]
would like to continue this conversation after the meeting
[some slides not covered in the meeting]