This gets my biased 1, I think it's an important long term strategic discussion of releasing analytics data and integrating it in our products:

T112956: Developer summit session: Pageview API overview

Interest in the following

https://phabricator.wikimedia.org/T114065 The future of MobileFrontend
https://phabricator.wikimedia.org/T111588 [RFC] API-driven web front-end
https://phabricator.wikimedia.org/T114251 [RFC] Magic Infobox implementation
https://phabricator.wikimedia.org/T113540 What can the Search API do for you?
https://phabricator.wikimedia.org/T113526 Discuss the future of Maps and Geo-related projects at WMDS2016
https://phabricator.wikimedia.org/T89907 Discuss and approve a MediaWiki developer community governance model
https://phabricator.wikimedia.org/T106099 RFC: Page composition using service workers and server-side JS fall-back

I'm interested in the following:
T114065: The future of MobileFrontend
T113526: Discuss the future of Maps and Geo-related projects at WMDS2016
T113490: 10 tips for communicating with communities when developing software

I'd like to see, especially the first two:

• T114419: Event on "Make code review not suck"
• T114320: Code-review migration to Differential status/discussion
• T114045: Scap3: updates, upgrades, and challenges
• T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
• T89907: Discuss and approve a MediaWiki developer community governance model

T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

T114542: Next Generation Content Loading and Routing, in Practice ( T111588: RFC: API-driven web front-end, T106099: RFC: Page composition using service workers and server-side JS fall-back)
T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

T114542: Next Generation Content Loading and Routing, in Practice
T111588: RFC: API-driven web front-end
T106099: RFC: Page composition using service workers and server-side JS fall-back
T114072: <section> tags for MediaWiki sections
T113540: What can the Search API do for you?
T114065: The future of MobileFrontend

T114542: Next Generation Content Loading and Routing, in Practice ( T111588: RFC: API-driven web front-end, T106099: RFC: Page composition using service workers and server-side JS fall-back)
T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

T114542: Next Generation Content Loading and Routing, in Practice ( T111588: RFC: API-driven web front-end, T106099: RFC: Page composition using service workers and server-side JS fall-back)
T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

How have 4 people ended up with identical votes? Sorry, but I don't buy this.

No worries, they are not votes.

In T119593#1850808, @Krenair wrote:

How have 4 people ended up with identical votes? Sorry, but I don't buy this.

I've been lobbying for these. Should this be done differently? I expect people will add as they see fit (which may include different items) or abstain. Sorry if any confusion? This was in response to https://lists.wikimedia.org/pipermail/wikitech-l/2015-November/084173.html. I actually have to distance myself from the first line, so will remove it from my own entry.

The comparison is with code review, where 1s don't add up mathematically. In code review not all 1s are equal, right? Also, giving a 1s implies that you have read the code (and here you would have read the proposal) and recommend to merge it (here as a pre-scheduled session).

I don't want to bring the comparison too far :) but suffice to say that lobbying and voting is not needed and, in fact, counterproductive if this type of game and its risk of distortion becomes popular. No worries! No harm done.

In T119593#1850939, @Qgil wrote:

The comparison is with code review, where 1s don't add up mathematically. In code review not all 1s are equal, right? Also, giving a 1s implies that you have read the code (and here you would have read the proposal) and recommend to merge it (here as a pre-scheduled session).

I don't want to bring the comparison too far :) but suffice to say that lobbying and voting is not needed and, in fact, counterproductive if this type of game and its risk of distortion becomes popular. No worries! No harm done.

Got it, and understood and agreed. To play it safe, I've sent a follow up with people I had lobbied to reinforce that my suggestions should be taken into consideration with the raft of other great proposals. Thanks!

T114542: Next Generation Content Loading and Routing, in Practice ( T111588: RFC: API-driven web front-end, T106099: RFC: Page composition using service workers and server-side JS fall-back)

T114072: <section> tags for MediaWiki sections

T113210: How should Wikimedia software support non-Wikimedia deployments of its software?

T113540: What can the Search API do for you?

@dr0ptp4kt, I think a more helpful way to influence the outcome is to do the following (with the help of the team you've lobbied):

1. Figure out which area you believe each proposal is a "must have" for (see T119018: Working groups/areas for macro-organization of RfCs for the summit for what I mean by "area") and which area is the best fit for the proposal
2. For each proposal, put a thoughtful comment on the area subtask (i.e. the appropriate T119018 subtask) explaining why this particular proposal is a "must have"

For example, T114072: <section> tags for MediaWiki sections is very clearly in T119022: WikiDev 16 working area: Content format. So, you should be making your case as to why T114072 is very important. Tim has clearly put a lot of thought into the list at T119022 (see his recent comment), so your job is to convince Tim that T114072 should be at the top of the list of proposals he's considering in that area.

@RobLa-WMF, cool - makes sense. Thanks!

T114542: Next Generation Content Loading and Routing, in Practice
T111588: RFC: API-driven web front-end
T106099: RFC: Page composition using service workers and server-side JS fall-back
T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

T114542: Next Generation Content Loading and Routing, in Practice ( T111588: RFC: API-driven web front-end, T106099: RFC: Page composition using service workers and server-side JS fall-back)
T114072: <section> tags for MediaWiki sections
T113210: How should Wikimedia software support non-Wikimedia deployments of its software?
T113540: What can the Search API do for you?

Quim and I discussed the priorities that we see emerging based on the conversations we've seen in this task and elsewhere.

Tentative must haves

• T384: RfC: Dependency Injection for MediaWiki core
• T106099: RFC: Page composition using service workers and server-side JS fall-back
• T111588 [RFC] API-driven web front-end
• T114320: Code-review migration to Differential status/discussion
• T113210: How should the WMF support non-technical mediawiki installs?
• T114072: <section> tags for MediaWiki sections
• T114071: Let's discuss the skin creation process
• T112991: Semantic image styles / beautiful layout

Tentative must-have after merge/combination

• T114251: [RFC] Magic Infobox implementation with T112987: Separating infoboxes and navboxes from article content
• T113002: Let's discuss LanguageConverter together with T114662: RFC: per-language URLs for pages of multilingual wikis. and T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis
• T114542: Next Generation Content Loading and Routing, in Practice possibly merged with T111588 API-driven web front-end and T106099 Page composition using service workers and server-side JS fall-back

Needs more investigation

• T107595: [RFC] Multi-Content Revisions
• T114419: Make code review not suck, especially for volunteers
• T99088: [RFC] Evolving our content platform: Content adaptability, structured data and caching, covering also T105845: Page components / content widgets and T114065: The future of MobileFrontend
• T114065: The future of MobileFrontend
• T113540: What can the Search API do for you?
• T113526: Discuss the future of Maps and Geo-related projects at WMDS2016
• T106099: RFC: Page composition using service workers and server-side JS fall-back

Unconference

• T89907 Discuss and approve a MediaWiki developer community governance model

We made this list by looking at the comments here, the comments at T119018: Working groups/areas for macro-organization of RfCs for the summit, and by an informal triage of the session proposals that are in the system.

If there is a session you are hoping for that isn't on the list, the bar may have gotten just a tiny bit higher for getting it in the schedule. Quim and I are going to be using this list as the version we use for 0.1 of the schedule. If you're going to argue for a session that isn't on this list, you'll need to not only say why what you want is important, but you may need make an argument for displacing one of these options to be persuasive.

Here is our old must have list. I'm planning to copy the new version into the task description.

TechCom has been discussing this for a little while, and here's the list I believe represents the rough first guess of a list from that group:

• T384: RfC: Dependency Injection for MediaWiki core
• T106099: RFC: Page composition using service workers and server-side JS fall-back
• T111588: RFC: API-driven web front-end

Note, this is "rough" guess, not scientifically derived. This list is actually derived from one of the committee members who was pretty stingy (but not stingiest) with giving 2s, plus noting that many others also gave the same proposals 2s. Thus, they seem to me to be proposals worth our time to discuss at Wikimedia-Developer-Summit-2016
I'm hoping that each of the individuals on TechCom post a comment here with their list of 2s (plus rationale)

T384: RfC: Dependency Injection for MediaWiki core is super important to discuss, and i noted some of the content-related topics that are important to me in T119029#1861455

T114045: Scap3: updates, upgrades, and challenges
T115340: Continuous integration hacking
T114419: Event on "Make code review not suck"
T114320: Code-review migration to Differential status/discussion

I'm interested in:
T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces
T114320: Code-review migration to Differential status/discussion
T114045: Scap3: updates, upgrades, and challenges
T112996: A vision for templates / wikitext 2.0

I'm a little behind on all of the process related to this, and maybe it's just me, but the general impression I'm getting is that people are !voting for sessions they want to discuss, without considering the impact making it an in-person session versus a general IRC meeting (but then again no one justified *why* they want certain sessions as robla asked, so I have no idea). Personally, there's a lot of value in being able to talk to developers face to face, and some of the sessions proposed here don't seem very valuable, and could easily happen in other mediums.

Also there are things that are tightly interrelated (IMO) and need to be discussed together and will inevitably come up anyways.

So I'd like to see:

• T384: RfC: Dependency Injection for MediaWiki core - because this keeps coming up in code review, blocking people and causing unnecessary grief
• T114071: Let's discuss the skin creation process - a lot of issues are related to the presentation/output of content, and the skin is the basic building block that everyone seems to hate
• T113210: How should Wikimedia software support non-Wikimedia deployments of its software?/T89907: Discuss and approve a MediaWiki developer community governance model/T114419: Event on "Make code review not suck" - I see all of these as related, because the WMF destroyed the developer community around MediaWiki, the future of MW is in the hands of the WMF. If there was an actual community, it really wouldn't be up to the WMF
• T113002: Let's discuss LanguageConverter (and related) - AIUI very few people understand the language converter, and even less want to touch it. Also needs some more thought on how ContentTranslation fits in to the multilingual picture.
• T114019: Dumps 2.0 for realz (planning/architecture session) - like LanguageConverter, dumps are also constantly neglected and need more attention, I think they're a lot more important and widely used than most developers think

I think could be handled in an online RfC meeting/shouldn't be at the summit:

• T114065: The future of MobileFrontend - EVERYONE agrees that MobileFrontend needs to die. What's left is figuring out which parts to kill, and where to put the remaining stuff. But as we've seen with UserProfile, someone just needs to do the work, and progress will be made. Individual things need to be discussed, but not a overall grand plan.
• T113540: What can the Search API do for you? - Sounds like "please tell us your feature requests" which doesn't need to be in person
• T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap - should be an IRC meeting, and we already had one of those which went well.
• T114045: Scap3: updates, upgrades, and challenges - this really seems like at least part of it would make a great tech talk
• T112956: Developer summit session: Pageview API from the Event Bus perspective - should be a tech talk

@Qgil and I discussed the following additions earlier today:

• T114019: Dumps 2.0 for realz (planning/architecture session)
• T112996: A vision for templates / wikitext 2.0

We also discussed the possibility of promoting T114065: The future of MobileFrontend to "must have" status. However, I think I’m swayed by rereading what @Legoktm said about this: “EVERYONE agrees that MobileFrontend needs to die. What's left is figuring out which parts to kill, and where to put the remaining stuff. But as we've seen with UserProfile, someone just needs to do the work, and progress will be made. Individual things need to be discussed, but not a overall grand plan.”

Everything in "must have" is stuff Quim and I going to try to slot in somewhere. However, since we have the big room (Robertson 1) fully booked (Monday, Tuesday), it means that the remaining stuff is either going to have to go opposite one of the already scheduled items, or it will need to be discussed in one of the working area conversations.

• T112956: Developer summit session: Pageview API from the Event Bus perspective - should be a tech talk

I tried pretty hard to make the point that this doesn't work as a tech talk, that a discussion is necessary and that what needs to be decided is pretty fundamental to our data strategy. But I guess I failed. Any tips are appreciated, or at least hints about why this comes across as a tech talk subject.

@Milimetric DevSummit sessions are intended to for discussion and decision making, not for mere presentations. To me, things that need discussion are good session topics, while plain heads-up presentations would be better candidates for lightning talks.

In T119593#1881102, @daniel wrote:

@Milimetric DevSummit sessions are intended to for discussion and decision making, not for mere presentations. To me, things that need discussion are good session topics, while plain heads-up presentations would be better candidates for lightning talks.

I love you, @daniel, but I'm gonna scream :) I am trying to say that this session *IS A DISCUSSION*. I don't understand what about it is leading people to think otherwise, and I'd really appreciate some help. Thank you and sorry for the screaming.

In T119593#1881051, @Milimetric wrote:

• T112956: Developer summit session: Pageview API from the Event Bus perspective - should be a tech talk

I tried pretty hard to make the point that this doesn't work as a tech talk, that a discussion is necessary and that what needs to be decided is pretty fundamental to our data strategy. But I guess I failed. Any tips are appreciated, or at least hints about why this comes across as a tech talk subject.

There are 50 tasks I tried to read, so I skimmed a good number of them, apologies if I missed anything. The main things I saw explaining what the session was about were T112956#1725965 and T112956#1761944, which I read as "presentation and Q&A", which is what tech talks are great for. Furthermore, it looks like a lot of people have already started to engage on the Phabricator task (which is great!), so I'm left wondering, what's left to discuss in person? How valuable will an in person session be compared to what's already going on right now?

@Milimetric I suppose I mis-interpreted your comment, sorry to add to your frustration!

@Milimetric - I think the best the problem area this is most closely fits as part of the solution for is T119029 (Content access and APIs). The central question for people focusing on that area is "how do we make accessing and distributing our data easier and more useful?" The reason why I bring this up is because I think that's going to be the best place to drum up support for further evaluating this proposal. I may make further comments in T119593, but feel free to ping me on IRC/whatever to discuss this more.

@daniel: no problem :)

@Legoktm:

There are 50 tasks I tried to read, so I skimmed a good number of them, apologies if I missed anything. The main things I saw explaining what the session was about were T112956#1725965 and T112956#1761944, which I read as "presentation and Q&A", which is what tech talks are great for.

I see, these comments are definitely outdated and represented a misunderstanding by the team early on. I corrected this in the description of the task hopefully.

Furthermore, it looks like a lot of people have already started to engage on the Phabricator task (which is great!), so I'm left wondering, what's left to discuss in person? How valuable will an in person session be compared to what's already going on right now?

This is a valid question and I don't want to push too strongly here, it's up to the organizers what gets included. But my case is as follows:

We (Analytics) explored different ways of serving huge amounts of data to the public and we think our experience here is going to help as our APIs get richer. We want to answer two main questions with this session. First, are we duplicating infrastructure and investigative work? Second, what kind of data does everyone want to expose via APIs and how do we want to integrate this data into our products? IRC / Phabricator are great, but I feel like a focused discussion with a broader audience would be more likely to address these questions efficiently. Right now the discussions are restricted to people who have been following the Pageview API specifically, and I'd love to hear from a much broader audience. I have the distinct feeling that I'm trapped in a bubble and I want this session to burst that bubble.

While the five areas facilitated by a handful of owners are useful to organize close to 60 proposals, we need to be aware that this system doesn't necessarily promote diversity of topics in the schedule. Sessions like T112956: Developer summit session: Pageview API from the Event Bus perspective, T113540: What can the Search API do for you? or T114019: Dumps 2.0 for realz (planning/architecture session) come from different angles, are pushed by distinct groups of contributors, and satisfy different audiences. I see them as good additions to our pre-schedule.

Given the complexity of getting Robertson 1 scheduling right (the 200 person theater), I think that we should consider shifting our focus to choreographing the scheduling in Robertson 1, and allowing the other rooms more unconference-style latitude. That's just a thought; I'm not sure I want to run away from our scheduling duties yet, but @Qgil, you aren't making a very good case for T112956, T113540 or T114019 with the diversity argument. Having spent a lot of time discussing session goals with the main proponents of T114019 (Dumps 2.0) and T112956 (Pageview API), I believe those sessions have potential, but the discussions need a lot more preconference work before I can recommend that we bless them with whatever stamp of "officialness" we might have. I'm certainly not going to recommend we route around the task owners of T119018: Working groups/areas for macro-organization of RfCs for the summit, which represents a de facto program committee.

I came up with the 5 questions core to the T119018 groups in trying to define "what problems are we going to try to solve at the summit?" If there are other questions that I missed, please tell me what they are so that we can spin up new areas (if necessary) rather than throwing out the whole idea. We should insist that each session owner be able to clearly articulate why and how their session is going to represent incremental progress toward improvement in at least one of the core areas.

In T119593#1883179, @Milimetric wrote:

[snip]

Discussion about the pageview API summit is now taking place at T112956: Developer summit session: Pageview API from the Event Bus perspective.

Quim, on Monday I suggested that perhaps we could have events for everything we plan to schedule. I'm going to walk that one back now; it looks pretty messy getting all of those separate events filed, and the payoff doesn't look worth it.

A possibly better approach; let's just use this task as a planning task. When we post new proposed schedules, then use the description as "plan of record. If someone wants to make a counterproposal, they can post it as a comment.

Below is a simplified Phab version of what is on the mw.org full schedule. I may yet attempt to fill in our must haves into this tonight. I think working with the simplified version here in Phab is going to be easier than futzing with the more detailed version in MW (no?)

Monday

Tuesday

This is a very rough first attempt at getting the "must have" items in there.

Monday

Tuesday

@RobLa-WMF, I agree that Phabricator events at this point might bring more trouble than benefits.

To be honest, at this point (with 3-4 working days before the Summit) I think you should move this drafting directly to the wiki schedule.

In T119593#1900896, @Qgil wrote:

@RobLa-WMF, I agree that Phabricator events at this point might bring more trouble than benefits.

To be honest, at this point (with 3-4 working days before the Summit) I think you should move this drafting directly to the wiki schedule.

This short before the meeting, I'm kinda done with fighting MediaWiki markup. The wiki schedule as it exists isn't designed well for collaborative editing; it's very display focused.

I find it a lot easier to think about the schedule in simplified form on Phab. The iteration of the schedule I developed at T119593#1900298 was very easy to do markup-wise, and I can imagine other people replying in a comment with their own schedule proposals in a similarly easy way.

I'm not planning on doing any more collaboration attempts on the mw.org version. Not only is on-wiki editing hard in its current form, but understanding what other people are proposing/changing is also time-consuming. Feel free to take the proposals I make here and translate them into MediaWiki markup that displays well.

Why fighting with wikitext markup when VisualEditor offers such good support for editing content in tables. Easier than here in Phabricator, and in the official location for the schedule.

About other people proposing, I still think that at this point the best option is to fill the on-wiki schedule as you think it's best, and let people ask for changes or apply them themselves.

@Qgil: your edit activity on the mw.org schedule is not making a very convincing case.

Some more work on the draft:

Monday

Tuesday

@RobLa-WMF, this looks very sensible, thank you. So far Robertson 3 is not being claimed by any session. Should this room be added to the Unconference rooms or do you have a different plan for it?

Can I ask why so many people (@bmansurov, @dr0ptp4kt, @Tnegrin, @JMinor, @KLans_WMF, @JKatzWMF, @MBinder_WMF, @Niedzielski, @jhobs) listed T114072: <section> tags for MediaWiki sections as a must-have? As the author of that proposal, I'm somewhat flattered, but I don't think any of you folks have participated in the discussion of T114072 to date (except for @bmansurov). Is this something you really want to *discuss*, or just something you want to *happen*.

The parsing team has been working on this (and related) topics, and have it on our roadmap. I'm just trying to assess the attendance at the Wikidev session and figure out how to schedule it. Do you have concerns? Input to add? Or is this just a vote of confidence that <section> tags are a good idea and we should get 'er done?

(Personally, I wish that, say T112984: Real Time Collaborative Editing, T113004: Make it easy to fork, branch, and merge pages (or more), or T115762: Shadow namespaces at the 2016 Wikimedia Developer Summit had such support, since I suspect these would have a much more profound impact on our project. With all due respect, <section> tags seem somewhat trivial to dedicate 80 minutes of the dev summit to.)

For some context, I'm the proposer of a task in all but two of the sessions currently in R2.

My specific proposal is to move T112987: Separating infoboxes and navboxes from article content to the 3:40PM Monday R2 slot and drop T114072: <section> tags for MediaWiki sections, so I can participate in 11:30am Monday R1 instead. T114072: <section> tags for MediaWiki sections seems to progressing acceptably through "normal channels", so I don't think that's much of a loss. But -- as I wrote above -- I'm actually quite surprised to see so much interest in T114072 here, from folks outside of the "normal channels" (ie, parsing team, restbase, mobile). Have I misjudged the interest?

From my perspective, I want T114072 to happen because it helps with
presentation issues but I don't have the context to part of a discussion.
Real time editing seems more suited for the summit.

Since the dev summit is nigh upon us, I've gone ahead and implemented the schedule change above (descheduling the T114072 session, and moving T112987 in its spot), on the assumption that @Tnegrin's reasoning was broadly shared. I am persuadable, however! If folks would like badly to weigh in on T114072: <section> tags for MediaWiki sections with face-to-face discussion, let me know and we can reschedule it or give it an unconference slot or a tech talk or something...

Per @cscott's change, here's the schedule we should have now:

Monday

Tuesday

More comments

This schedule isn't reflected in the Next Generation Content Loading and Routing deck, but I think I'm willing to roll with @cscott's changes.

@Quiddity pinged me earlier to ask about discrepancies between this schedule and the schedule as published on mediawiki.org. My next step is to check this myself, and possibly follow up with quiddity on IRC.