Page MenuHomePhabricator

Define main themes of the Wikimedia Developer Summit 2016
Closed, ResolvedPublic


We need to define main the main themes of the Wikimedia Developer Summit 2016 in order to help people deciding whether they should submit proposals, arrange travel plans, allow us starting the volunteer sponsoring process, etc.

We are talking literally about main themes. Once this is decided, we will have more time to get into details about the program.

IMPORTANT: this is a draft. Topics and dates may change.


  • Technology (Architecture)...
  • Discovery: Gathering requirements for Search API improvements and showcasing recent improvements to CirrusSearch
  • Reading...
  • Editing...
  • Community Tech... (track?)
  • Wikimedia Web APIs (track targeting 3rd party developers)

Event Timeline

Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil set Security to None.

@RobLa-WMF volunteered to drive this in representation of WMF Engineering and Technology. @Rfarrand is meeting him today to brief him about the basics of the event, and I'm available for whatever work is needed to agree the main themes and start creating the schedule.

@Rfarrand and @RobLa-WMF had a first briefing last week and I'm going to meet RobLa next week. Our goal is to come up with a proposal containing clear directions in sync with the WMF Engineering and Technology plans.

I think our starting point for structure and deadlines should be to model this using Architecture Summit 2014. The mood and venue at the 2015 Dev Summit was better in many ways, but I also think we erred when we backed down from using this once-a-year opportunity to drive our architectural planning in the way that it needs to be driven.

I've long advocated using the IETF as a model for how we should be thinking about consensus-based technical decision making, so I'll be pushing that with a lot more force. The 2014 summit was loosely modeled on some IETF ideas, and I think we need to study those. See T111306: Recruit event scout for November IETF meeting in preparation for #WikiDev16 for further thoughts on that subject.

About deadlines and process to come up with an agenda, I have replied at T104346#1601209. Let's continue here with the main themes.

In previous years we had some kind of vicious circle where event organizers were waiting for participants to present strong proposals, and participants were waiting for organizers to define which kind of topics were expected. Attempts to get those main themes out of the Architecture Committee and top executives basically failed. So I like @RobLa-WMF's proposal to go back to a RFC/proposal driven process.

However, I still think that having some main themes beforehand will help potential participants to decide whether they should step in with session and/or travel plans. One way to break the vicious circle is to empower the big four WMF teams to define their own themes: Technology (Architecture), Discovery, Reading, and Editing. They know what topics are worth bringing, and they know the implications in terms of preparation of proposals, travel, etc. Discovery, reading, and Editing might have a tendency to look for themes within their borders, while Technology probably will go for cross-project theme(s). Looks like a good balance.

In addition to this, we could define in advance the existence of two tracks for Community Tech and for Web APIs, targeted mainly to community and 3rd party developers not that involved with architecture and development of MediaWiki core and extensions. Basically, a different audience and mostly external to the Wikimedia Foundation that requires specific outreach and travel sponsorship.

@Rabla-wmf, what do you think about this approach to define the main themes by next Friday?

With a bank holiday next Monday in the US, there is not much time left. CCing @Wwes, @Tnegrin, @TrevorParscal and @kaldari, since the proposal counts with their buy in and their action.

After several conversations between RobLa and me in the past days, we have decided to stick with one single theme

Updating our architecture, infrastructure and services to better support users and developers

The wording can be fine tuned. I have extracted it from the Call to Action 2015: T98352: Update legacy architectures and deliver mobile-ready infrastructure and services to support structured data, user security, and a simplified user experience

As you can see, it is a wide theme, and in the Call for participation draft we are also assuring that "Other topics interesting to Wikimedia developers are welcomed as well."

Contrary to the previous Summit, we as organizers of the event are not focusing in pre-defining promoted areas. Instead, we are betting on a call for participation and a selection process (see link above) that focus on bringing complex discussions to the Summit and resolving them there, for the benefit of our platform and for the users and developers relying on it. This process gives full control to the teams and any contributors motivated to push the topics that are more relevant for them.

Feedback welcome. We will run this proposal today at the WMF Engineering Management weekly meeting, and we will report back.

empower the big four WMF teams to define their own themes: Technology (Architecture), ...

FYI prior to Lyon hackathon, the Architecture Committee set out T96903: Identify and prioritize architectural challenges. It's a big list but I think @GWicke and others still seek consensus that it's the right prioritization. Its first theme, that turned into a more concrete working group, is T99088: [RFC] Evolving our content platform: Content adaptability, structured data and caching; seems to me there is a complex discussion in there that could be resolved at the Summit.

@Wwes, is your addition to Discovery a proposal for two specific sessions or for a theme to inspire others to present their own sessions related with Discovery topics (what we have called "sign posts" and "lighthouses" to help other navigate)?

Also note that we are discouraging demos and other types of presentations at the Summit. We can organize Tech Talks / Lightning Talks or SF meetups before the Summit for that. See

Hi Quim -- I'd like to second @Spage's proposal that we form a working group around Gabriel's proposals. The audience teams have been working to create some product requirements to accompany these proposals and it would be very constructive to report on these discussions at the summit.


@Tnegrin, @GWicke, by all means, the floor is yours. The first step is to submit session proposals or recycle existing open tasks. Then, when it comes the time to organize the schedule, we can group sessions in rooms to assure that i.e. on Tuesday morning room C is all about <your theme here>.

Here's a list of focus areas which is intended to make areas a little more clear. This first iteration is based on the "RFC cluster" concept we defined back in 2014, and may still have big gaps, so don't read too much into the accidental exclusion of anything.

Thank you @RobLa-WMF, this is a solid list of focus areas. Please link it from (or transclude it, if you prefer).

Today we will explain focus areas, stakeholders, and milestones at the WMF Engineering management weekly meeting, and we will proceed according to their feedback.

Any update or feedback from the WMF engineering management meeting?