One possibility is to integrate T121672: Present results of Community Wishlist Survey at Dev Summit.

https://etherpad.wikimedia.org/p/WikiDev16-WrapUp

Snapshot of notes from Etherpad

Session name: Wrap-up
Meeting goal: Main outcomes of each area + Community Wishlist + Summit next steps
Meeting style: Problem-solving / retrospective
Facilitator: RobLa
Gatekeeper: Matt Flaschen
Scribe: Kunal
Timekeeper: Katie Filbert

Agenda

3:40 Rob introduces the session and the idea of the areas post-Summit (10 min)
3:45 Q&A with the areas through a Q&A with Rob and others (5x10 = 50 min)
~3:45 User interface (Volker & Krinkle)
~3:55 Content format (Tim & RobLa)
~4:05 Software engineering (Daniel)
~4:15 Content access and APIs (Gabriel)
~4:25 Collaboration (Quim)
4:35 Danny shares current status and thoughts about the Community Wishlist, and how to integrate it better with developer priorities and plans (10 min)
4:45 Rachel gives instructions for the evening and Wednesday, and reminds about next steps e.g survey, Jerusalem, Esino Lario.
Phabricator task link: https://phabricator.wikimedia.org/T121641

The area discussions:
Monday:
3:50 T119162: WikiDev 16 working area: User interface presentation - how do we make using Wikimedia software more usable, and make it look and feel joyful to use?
4:00 T119022: WikiDev 16 working area: Content format - how do we make manipulating our data easier and more useful" (both for humans and computers)

Tuesday:
T119032: WikiDev 16 working area: Software engineering - how do we build reliable, maintainable, and widely-understandable software that continues to make Wikimedia sites work well?
T119029: WikiDev 16 working area: Content access and APIs - how do we make accessing and distributing our data easier and more useful?
T119030: WikiDev 16 working area: Collaboration - how do we scale editing our code up to populations similar to editing our projects, proportionally increasing our positive impact and productivity?

Meeting summary

• How do we keep the working areas alive as areas?
  • RobLa asked each group this question
  • Phab projects?
  • Roadmap?

Detailed notes

[robla] Introduction
[robla] Divided everything into areas. We had a reasonably clear division of responsibilities. I would love for these areas to survive. I would take action myself to keep these alive, but there's a limit to what I can do myself. Let's go into the specific areas in chronological order.

=== User interface presentation area ===
[robla] How do we make our software more usable? We can keep this alive because we have a user experience group and a front-end standards group (FSG).
[robla] Front-end standards group (we have two??) are working in this area.
[Volker] There's a big overlap in topics raised in the summit, affect specific WMF groups/teams. Skinning system hackathon...
[Krinkle] Action items universally heard as wishes:

• Further usage of OOUI, maybe also in templates and lua modules. Re-use of components between different wikis. Fit different skins.
• Page components, expand afterwards, not during the parser. Don't have to fragment cache, more power to apps(?)
• Standardize infoboxes/navboxes/etc. A long time coming, becoming a blocker for future changes.

[robla] Do you feel like you have sufficient agency and authority to do that?
[Krinkle] Set goals with Trevor, what do we actually want to solve. Main goal is being able to treat apps/mobile/desktop and logged in/out users the same. Also performance perspective. FSG has people designing things as well as implementing things. Need some recognition to assign people to things/teams.
[robla] Do you feel like assignment is the right model, or maybe inspiration would be better?
[Krinkle] Do software changes that the team needs, which solves the assignment issue. Don't make changes only for the sake of the change if they have no end result.
[robla] working group model discussed in ArchCom. FSG is that model. Is it a peer to ArchCom? Is the model we have right now a workable one, and should other groups aspire to be like this?
[Krinkle] It works well for us, helps us to get consensus going forward. Still good to have authority from the architecture committee.
[robla] Architecture group can ask if we have consensus for changes.
[Krinkle] I'm in both groups, but it is our job as architects to reach out and gauge what the consensus is. Also include our own personal experience is.
[robla] This was an area where we didn't know how to run the meeting, so we learned as we went.

Content format

[robla] Tim and I were in charge(?) of this area
[robla] Very little clarity going into this. Do you (Tim) feel like there's a better idea now?
[TimStarling] I have a good idea of how it's scoped. Focus was very wide ranging, lots of speakers lining up.
[robla] What is an example of an RfC that's in scope for this area? And what's one that's not??
[TimStarling] There are RfCs that straddle areas. Content format includes storage, content representations. Things like maps and graphs which touch on user experience and storage format.
[robla] Significant overlap with different areas, and have expertise and should be consulted. Example: Which codecs should we allow to upload to Commons? Would you consider that in scope for content format?
[TimStarling] It's probably out of scope. Codecs are self-contained. Our infrastructure is independent of which codec we're using.
[robla] We have to store a video in a certain format. We're not going to store it uncompressed. The storage is in ContentFormat, but how we deliver it can be any number of other codecs. That's just my idea, but it shows the complexity of figuring out these areas.
[DanielK] I care about infrastructure, content representation. It's about how we represent it, how we code it, how we store it. When we focus on the representation, it becomes more clear what is in scope.
[TimStarling] if we were adding closed captions to videos, that would be in scope(?)
[robla] this is a large area, how do we keep it alive?
[TimStarling] A Phabricator backlog/project which is regularly checked and has tasks assigned by ArchCom.
[cscott] I think it's not just a backlog of things to review; having a roadmap is important. For example, infoboxes etc. came up in a lot of other sessions. Knowing that infoboxes are on this area's roadmap gives us the confidence that we can do (eg) semantic styles for images now, then generalize layout hints to infoboxes etc. later once the Content Format WG lays the groundwork.
[robla] A wiki page associated with each area.
[cscott] The Multi-content Revisions RFC is an example; it came up in other sessions but we knew we didn't need to solve that part of the problem ourselves. Pace yourselves and let this working group get to it.
[cscott etherpad comment] in a broader sense, some ongoing dialog about priorities is important, so that other working groups aren't stuck waiting for a particular task which this WG is not aware is a blocker.

Software engineering

[robla] Is the scope reasonably clear?
[DanielK] By now it is. I see best practices as an aspect of everything we do. There are very few RfCs that are particularly about this.
[robla] It was a while before we got on the same page on what the scope of this is. Do you think we have a reasonable trajectory about what we can learn in this area?
[DanielK] difficult to distinguish between ArchCom. This is how we build software, which is what ArchCom covers already. Make things like docs more accessible. Name is not clear, it is clear to people who were in the session, which covered Service-Oriented Architecture and Dependency Injection. Get needs for those. Can't speak for everyone, *I* have clarity
[robla] Software engineering is an aspect of what ArchCom should be responsible, but they should be responsible for all five of these areas to some degree. What are the best practices wrt computer science? Also has to do with the release frequency, the amount of testing, what we should test.
[DanielK] Testing infra and CI is quite important - didn't talk about it in session today. (There was a breakout session about CI though) CI plays a big role, dependencies and components and high quality code.
[robla] How do you see the best way of keeping this area alive and moving forward. Maybe having a roadmap?
[DanielK] Roadmaps are nice. But...not sure how useful they are if nothing is there to back them up. Could make a roadmap for things that *I* am going to do. Could have a tag for things that we are going to do for ArchCom. In terms of process, would be nice to identify key points for quarterly planning. Things that should be addressed sooner rather than later. Software engineering is about things that are important but not urgent, which is a fundamental problem of scheduling.

Content access and APIs

[robla] Same question, is this area scoped and defined?
[gwicke] We have to think about content, and about the API. They both shape each other. I'm unsure about the granularity that we should shoot for. There's a lot of overlap. Going from ArchCom to ArchCom with five working groups. We should revisit this with the goal(?) of turning this into working groups.
[robla] What is the right way of changing the working groups, or should we do away with them?
[gwicke] ... other discussion forum?
[robla] IETF (Internet Engineering Task Force) model, working groups formed to solve specific problems, groups split into areas. Area directors...? There are pieces of that model that we can borrow. Most of the work happens in the working groups, and the people higher up in the ranks make sure that the rules are being followed. They aren't necessarily making the decisions.
[gwicke] I like the Rust process, their RfC thing is nice https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md. Seems to work well and I find it interesting. Would give working groups teeth, and rules about champions! Discussion should be had separately.
[robla] How do we keep this area alive?
[gwicke] The discussions will stay alive by themselves, they have been going on for a while already.
[robla] People have to have the right audience to appeal to. E.g. with code review it might be better to be a jerk and respond than to not respond at all and to silently let something die. The Linux community, with all its faults, does this. Is there somebody who can own up(?) to giving a timely response?
[gwicke] I'm not sure what the separation of the groups achieves.
[TheDJ] What if we just start with three areas, then see if we need any more? We shouldn't forget that there isn't an endless pool of people that we can pull this from.
[cscott] I'm wary about canonicalizing these groups from just the people who showed up to this particular meeting at this particular time. I'm open to the idea that these are useful seeds of groups which could attract a larger (and more representative) number of interested people over time. One of the most useful things that happened was just getting a bunch of interested people together to hash out ideas. I like Rob's idea of using these groups to get a timely answer from people who are knowledgeable about the area. But at the moment I'd be more comfortable with them as advisory groups rather than decision-making bodies. Over time, as they provide opportunities for new voices to join and the groups prove themselves useful and representative, their decisions could be treated as more binding.
[superm401] What do we do in various situations, not respond, respond and be a jerk?

Collaboration

[Quim] I have a clear idea of this area. Collaboration is a fuzzy concept, and we have a good idea of the central thing, the code review. If code review is great, but we don't understand the community, then we are solving the wrong problem. This summit is a good opportunity to start looking into other areas in which we can improve.
[robla] This is close to the SE area in many ways. It's about how we collaborate, how we behave. How important is that to the collaboration area for you?
[Quim] This event is biased to the people who are attending. We shouldn't forget the other people in the community. Find ways to get them involved. People wonder why I am stubborn about the shadow namespaces thing. We have all these gadget, template, module developers spread over 100s of wikis. There is a benefit of bringing all of these people closer.
(etherpad) <3
[robla] We should also think of the organizations that are not here. Lots of people from WMF here. How can we make this not such a WMF-centric event?
[Quim] Are we serious about being an open source project? If that is the case, then we need to change some things. Then there is Wikimedia as a source of free content, which devs can play with through an API. We can have developers working on things with this, and for us it's almost a side-effect. We need to think about two qs: how serious are we about an open-source project, and how serious are we as a provider of content.
[Quim] Discussed 3rd party MediaWiki users and the idea of a MediaWiki Foundation. We have a situation where we say that this important, but we act like it's not important.
[cscott] The content side is very underrepresented. The foundation itself could have a working group whose job is: content migration. LoC has folks transferring floppies to CDs, then turning around and putting the CDs on hard disks, etc. As a foundation we've held content at arms length in a way that might hurt us. Not just other 3rd party code hackers, but also template devs, folks who build infoboxes, folks who try to fix things we break, etc. We have done this work, for example semantic annotation of commons metadata. But we haven't always treated this task (or those developers) as a first-class concern.
[robla] How do we keep this area alive?
[Quim] It is the job of my team to keep it alive, so one way or another we'll keep it alive... Even if that doesn't happen, we'll continue doing our work. Our team are going to use a framework to solve, well not solve, find answers to many of these questions in the next six months. We need to participate in the WMF annual plan/strategy for the next fiscal year. Is MediaWiki reuse important, yes or no? Is code review important? yes or no. Etc. At least find answers in terms of resourcing. What are top priorities Not just spontaneously.
[robla] Danny: One of the things we want to do is talk about the community wishlist hat we ouched on in the opening session. I won't take any more of your time.

Community Wishlist (Danny Horn)

[danny] I'm not going to take too much of your time. One of the things I wanted to talk about is all of the stuff under the top 10 on the wishlist survey.
People came and wrote proposals and endorsed proposals. There was a two-week voting period and people could discuss and offer supports or opposes. We just counted support votes to see what inspired and excited people. The top 10 is what the CT team has responsibility to investigate and address. There are 106 proposals, with lots of really good ideas. There are some our team won't have time to address. On the Dev Summit schedule under the Unconference session are few links. 1 is the whole results list, all 106 (https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results ). It has all the votes and a link to the phabricator ticket. There's also a wishlist survey phabricator board, everything in numerical order. And, we're really encouraging folks and we're working with DevRel to see what we can offer at hackathon and what we can do in GSOC. There are a lot of good ideas and I'd like to encourage you guys to take a look. We've talked to a lot of great people over the last couple days, look forward to more!

[robla] Thank you, and thank you for everybody sitting patiently through this session and just in general. I've learned a ton from you all and I"m honored and privileged to work with you all and I hope you feel the same way. And BTW, a big round of applause to Quim and Rachel.

[Quim] And for Rob, who had lots of patience with all of us.
[robla] We should talk about what's next in the day.
[Rachel] Just a couple things, I know a lot fo you are probably jetlagged so we'll wrap this up. I'd like to than Sarah and Megan who are currently setting up the vent. You should say Happy birthday, to her, because she's working the event on her birthday. There'll be good food and drinks and non-alchoholic drinks and whatever you want. I sent an email about tomorrow with a whole bunch of info. So do me a favor and read it. And if you're one of those sneaky people who snuck in without registering, ask someone to forward it. Since I've heard misunderstandings, there aren't any scheduled events tomorrow. We have all the conference rooms tomorrow and all doors will be open. Yeah, it'll be really fun. And all announcements... this is the last time you'll be addressed on a microphone. All announcements will be in #wmhack on IRC. This will be projected on 5th floor event space. I'll send out the survey tomorrow so you all can tell us how the event was and what w should do next year.

If this was not enough for you, we have some upcoming events that are going to be great too. We're going tobe focusing on the community wishlist at the Hackathon event in Jerusalem. Besides community wishlist, another focus of the event will be mentoring newcomers and each other.

The WM hackathon in Esino Lario will be similarly focused, but we haven't worked that one as much out yet. And with that, unless anyone has anything else to say, the event is closed. And the buses will be here shortly to take us back to the office.

Action items

Robla: Help keep alive the areas of discussion

Misc

DON’T FORGET: When the meeting is over, copy any relevant notes (especially areas of agreement or disagreement, useful proposals, and action items) into the Phabricator task.
See https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Session_checklist for more details.