Talk:Wikimedia Developer Summit/2017

The Wikimedia Developer Summit 2017 is 13 weeks away!

PARTICIPANTS

• 68 people have requested an invitation.
• 19 of them have requested travel sponsorship as well.

Join us! The deadline to request travel sponsorship is Monday, October 24th.

PROPOSALS

• 8 proposals submitted
  • 1 in backlog
  • 2 in Unconference
  • 2 missing basic information
  • 3 to be pre-scheduled

Call for participation. The deadline for submitting new proposals is Monday, October 31.

MAIN TOPICS

Program

On track:

• A plan for the Community Wishlist 2016 top results
• Building on Wikimedia services: APIs and Developer Resources
• How to manage our technical debt

Missing basic information

• A unified vision for editorial collaboration
• Building a sustainable user experience together
• How to grow our technical community

Missing two facilitators

• A unified vision for editorial collaboration
• How to grow our technical community

Missing one facilitator

• Handling wiki content beyond plaintext
• Building a sustainable user experience together
• Artificial Intelligence to build and navigate content

ORGANIZATION

• Meet the Program committee.

(Yesterday and today I am in a full-day training. I plan to send the Weekly either tonight (Tuesday) or tomorrow morning. Sorry for the delay!)

2016-10-17

The Wikimedia Developer Summit 2017 is 12 weeks away!

PARTICIPANTS

• 50 participants confirmed.
• 42 more people have requested an invitation.
• 29 of them have requested travel sponsorship as well.

Join us! The deadline to request travel sponsorship is Monday, October 24th.

PROPOSALS

• 13 proposals submitted
  • 0 in backlog
  • 4 in Unconference
  • 3 missing basic information
  • 3 missing active discussion
  • 3 to be pre-scheduled

Call for participation. The deadline for submitting new proposals is Monday, October 31.

MAIN TOPICS

Program

On track:

• A plan for the Community Wishlist 2016 top results
• Building on Wikimedia services: APIs and Developer Resources (T147593)
• How to manage our technical debt (T147937)

Missing basic information

• A unified vision for editorial collaboration
• Building a sustainable user experience together
• How to grow our technical community (T147406)

Missing two facilitators

• A unified vision for editorial collaboration
• How to grow our technical community

Missing one facilitator

• Handling wiki content beyond plaintext (T147602)
• Building a sustainable user experience together
• Artificial Intelligence to build and navigate content (T147708)

ORGANIZATION

• Promote the Wikimedia Developer Summit beyond the usual circles.

2016-10-31

The Wikimedia Developer Summit 2017 is 10 weeks away!

PARTICIPANTS

• 60 participants confirmed.
• 111 more people have requested an invitation.
  • 81 of them have requested travel sponsorship as well.

Join us!

PROPOSALS

• 58 proposals submitted
  • 8 in backlog
  • 10 in Unconference
  • 6 missing basic information
  • 27 missing active discussion
  • 3 to be pre-scheduled
  • 4 invalid

Call for participation. The deadline for submitting new proposals is Monday, October 31.

MAIN TOPICS

Program

On track:

• A plan for the Community Wishlist 2016 top results
• Building on Wikimedia services: APIs and Developer Resources (T147593)

Missing basic information

• Building a sustainable user experience together

Missing one facilitator

• Handling wiki content beyond plaintext (T147602)
• Building a sustainable user experience together
• Artificial Intelligence to build and navigate content (T147708)
• How to grow our technical community  (T147406)
• How to manage our technical debt (T147937)

Cancelled

• A unified vision for editorial collaboration (related proposals are welcome)

ORGANIZATION

• Promote the Wikimedia Developer Summit beyond the usual circles
  • A successful promotion brought more scholarship requests than in the previous three Summit editions combined.
  • Pageviews peaked at 363 on one of the outreach days
  • Twitter saw 22,737 ‘impressions’ on this tweet, shared by WMF Comms and others and 12,601 for this one.
• Wikimedia Developer Summit Scholarships
  • A new committee is reviewing candidates as we speak.

2016-11-10

The Wikimedia Developer Summit 2017 is less than 9 weeks away!

PARTICIPANTS

• 111 participants confirmed.
  • 12 of them have been sponsored by the Wikimedia Foundation and Wikimedia Deutschland's Software Development department.

Registration is still open. Join us!

PROPOSALS

• 70 proposals open
  • 2 in backlog
  • 12 in Unconference
  • 19 missing basic information (deadline on Monday, November 14)
  • 33 missing active discussion
  • 1 on track
  • 3 to be pre-scheduled

Check the selection process timeline.

MAIN TOPICS

No significant news. We hope to have all the wiki pages up to date next week.

Check the Program.

ORGANIZATION

• The Travel Sponsorship committee reviewed 92 requests and decided on 12 based on budget available.
• The Program committee met officially for the first time (meeting logs and summary).

2016-11-17

The Wikimedia Developer Summit 2017 is less than 8 weeks away!

PARTICIPANTS

• 111 participants confirmed.
  • 12 of them have been sponsored by the Wikimedia Foundation and Wikimedia Deutschland's Software Development department.
• 8 more people have requested an invitation.

Registration is still open. Join us!

PROPOSALS

• 67 proposals open
  • 0 in backlog
  • 18 in Unconference
  • 45 missing proven interest (deadline on Monday, November 28)
  • 1 on track
  • 3 to be pre-scheduled

Check the selection process timeline.

WE NEED YOU

Time to prove your interest in Summit proposals.

Check the Program.

ORGANIZATION

• Backstage work visiting the venue and discussing logistics (WiFi, catering, rooms).
• Program committee heading towards the pre-selection of active discussions with proven interest.
• Also working on a couple of sessions with invited guests.

2016-11-24

The Wikimedia Developer Summit 2017 is less than 7 weeks away!

PARTICIPANTS

• 111 participants confirmed.
  • 12 of them have been sponsored by the Wikimedia Foundation and Wikimedia Deutschland's Software Development department.
• 25 more people have requested an invitation.

Registration is still open. Join us!

PROPOSALS

• 69 proposals open
  • 0 in backlog
  • 18 in Unconference
  • 45 missing proven interest (deadline on Monday, November 28)
  • 1 on track
  • 5 to be pre-scheduled

Check the selection process timeline.

WE NEED YOU

Time to prove your interest in Summit proposals.

Check the Program.

ORGANIZATION

• Program committee heading towards the pre-selection of active discussions with proven interest.
• Also working on a couple of sessions with invited guests.
• We sent an email to all registered participants asking them to show their support to proposals.
• Improve remote participation.
• Create a schedule table for sessions in a grid format. (UX review / help welcome!)

2016-12-02

The Wikimedia Developer Summit 2017 is less than 6 weeks away!

PARTICIPANTS

• 107 participants confirmed.
  • 12 of them have been sponsored by the Wikimedia Foundation and Wikimedia Deutschland's Software Development department.
• 57 more people have requested an invitation.

Registration is still open. Join us!

PROPOSALS

• 72 proposals open
  • 0 in backlog
  • 33 in Unconference
  • 34 on track (active discussion is especially welcomed here!)
  • 5 to be pre-scheduled

Check the selection process timeline.

WE NEED YOU

Time to prove your interest in Summit proposals.

Check the Program.

ORGANIZATION

• The Program committee is working on a draft schedule to be published on Monday, December 12.
• Also working on a couple of sessions with invited guests.
• We are planning an online session before the Summit.

In the last weeks we are sending an email to all registered participants, which serves as weekly update too. See Wikimedia Developer Summit/2017/Email1.

More updates sent:

Wikimedia Developer Summit/2017/Email2

Wikimedia Developer Summit/2017/Email3

This is a call to everyone interested in the Wikimedia Developer Summit 2017 -- including remote participants. We need you to help us decide which sessions should be pre-scheduled in advance, getting bigger rooms, video recording, and higher quality requirements.

Today we have 46 sessions competing for 15 slots. We need to propose a schedule by December 12. How can you help?

The best way is to check the proposals submitted and join those that interest you in a visible way:

• participating in the discussion (the best way to prove your interest and support the proposal)
• subscribing to the Phabricator task (click "Subscribe")
• awarding a token to the Phabricator task (click "Award Token")

The sooner, the better. We will start checking participation by November 28 (see the timeline).

To be clear, this is not a popularity contest. Proposals with more participation will be more likely to be pre-scheduled and vice versa. However, the scheduling will be handled by the Program committee. They will take into account participation numbers, but they will also consider other factors.

Proposals not scheduled will be directed to the Unconference that will run in parallel to the pre-scheduled sessions.

Sent to wikitech-l and wmfall. Forwarding to other lists & destination is very welcomed. We will distribute this to all participants registered so far.

Sent to all registered participants November 17th

This is now Wikimedia Developer Summit/2017/About.

@Rfarrand (WMF) (Summit organizer) and @Qgil-WMF (budget owner) are bootstrapping a WikiDev 2017 organization team as we speak. We are keeping track of all the work at #wikimedia-developer-summit and the main task phab:T141926.

In previous years we have got plenty of help from other people, sometimes formally, frequently informally. This time we want to improve the organization of the event by having a formal Organization team with some members appointed to specific roles and tasks. We also want to invite people to volunteer before, during, and after the event on specific organization tasks.

One idea is to formalize a Program committee. @RobLa-WMF and @Qgil-WMF have assumed this role in various ways in the previous year, with the participation of other people and different approaches to a basically crowdsourced program. Last year the idea of discussion areas was introduced, as a way to assure that different stakeholders were represented in the organization of the Summit program. The Program committee would basically crystallize these practices and adopt whatever improvements they decide to try.

Another idea is to formalize a team focusing on making the most of the Summit discussions: facilitation of the sessions, recording, remote participation, documentation of the outcomes, and the organization of the Unconference part. Here we also have many people who have helped in the past, and many practices that we tried with different degrees of success in previous editions. This team would own these planning and execution of these practices during the event.

And another idea is to have a team focusing on the Summit website, with a special focus on making it informative and attractive to those who don't know about the Summit and those who haven't decided whether they should attend. In previous editions we have focused on information for attendees, and this team will still make sure that participants do get the information they need (there is room for improvement here as well). However, using the Summit "minisite" for outreach and communication with non-attendees hasn't been a focus, and this is something that we think should change.

The organization team is being documented at Wikimedia Developer Summit/2017/About.

I am interested in representing UX engineering & design, as well as working on the website.

The Wikimedia Developer Summit 2017 aims to focus the call for participation around these main topics:

• A plan for the Community Wishlist 2016 top results
• Handling wiki content beyond plaintext
• A unified vision for editorial collaboration
• Building a sustainable user experience together
• Building on Wikimedia services: APIs and Developer Resources
• How to manage our technical debt
• How to grow our technical community

You can find more information about these topics and how we selected them here.

The next steps are:

• Each main topic needs at least one facilitator, who will assure that the topic is well promoted in the right places, the right activities are proposed, and the right people participate in them with common goals. These facilitators will join the Program committee https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/About

• Each main topic needs good quality and quantity of proposals submitted, so a good selection can be made for the pre-scheduled Summit program.

• Each main topic needs its own wiki page for information, coordination, discussion, and documentation.

If by the end of October a main topic is still missing a facilitator, a critical mass of proposals and/or a decent wiki page, then the chances are that such main topic will be dissolved. If that happens, the activities proposed can be still pushed by their promoters in the context of the Unconference. Just like the rest of proposals not fitting under the main topics.

Now each main topic has its own page and a skeleton that the contributors of each page are totally free to edit away. See Wikimedia Developer Summit/2017/Program.

I have changed the term "owner" for "facilitator", which reflects better what this role is supposed to do.

The model for mentors in developer outreach programs has worked quite well, and I think we can apply it here as well:

• two facilitators are required for each main topic, a primary and a secondary (to clarify responsibilities and assure some redundancy and diversity of perspectives).
• ideally one person takes one facilitator role only, or two at most if there is no alternative, either as primary-secondary or secondary-secondary (to propitiate quantity and diversity of facilitators, and reduce the risk of excessive workload and single points of failure.

Do you agree?

We need to start aligning Program committee members with main topic facilitators. I think all primary facilitators should be Program committee members. However, this could be optional for secondary facilitators. On the other hand, maybe the committee would benefit from the participation of some members providing a perspective not fully covered by the main topics. We'll see as we go.

You can find more information about these topics and how we selected them here.

I wanted to know what "Useful, consistent, and well documented APIs" was about, for example, but I'm not seeing anything there. The only mentions of it seem to be when you proposed it and when you declared it a chosen topic.

I have collected the various ideas in the wiki page as a first step. Yesterday in the ArchCom meeting Daniel Kinzler was also puzzled by these titles. Note that they are meant to be an orientation for the kind of proposals desired, not titles of sessions themselves.

The point is, do you have a proposal in mind that would contribute to Useful, consistent, and well documented APIs? If so, you are especially encouraged to submit it.

It's October, and before the end of the month we need to have the people we want registered and the topic we want submitted. @MKramer (WMF) is driving the promotion of the Summit beyond the usual suspects and she needs the help of facilitators and anyone else interested. I have listed the current status of facilitators at Phab:T146615#2687934.

Problems:

• A unified vision for editorial collaboration and How to grow our technical community are missing facilitators. @Trizek (WMF) and @Qgil-WMF are trying to find them.
• Useful, consistent, and well documented APIs and Artificial Intelligence to build and navigate content have two facilitators each in theiry (my assumption) but it would be good to have a confirmation.
• Handling wiki content beyond plaintext, Building a sustainable user experience together, and How to manage our technical debt are missing a second facilitator. @RobLa-WMF is volunteering to be facilitator of Technical debt in addition to Wiki content, but as explained above I'd rather have roles as spread among different people as possible. We can get involved in the topics we want anyway, but when it comes to duties it is better to have them distributed whenever feasible.

Regarding my dual volunteering for tech debt and wikitext, here's what was said in Phab:E285:

• 21:49:55 * robla volunteers for "Handling wiki content beyond plaintext" and "How to manage our technical debt"
• 21:50:27 <DanielK_WMDE__> robla: these are my favorite of the lot. let me know if i can help.
• 21:50:28 <greg-g> ah, I was going to volunteer for the tech debt one

I've earmarked Wikitext as a goal for Architecture next quarter, but that's not as central to Architecture as tech debt. I'm willing to step away as facilitator from one or the other, but based on the IRC comments, DanielK (@Duesentrieb) is also willing to be a facilitator for one or both. Your thoughts, Daniel?

I'm certainly interested in content models and tech debt. I see that as a facilitator, I "will assure that the topic is well promoted in the right places, the right activities are proposed, and the right people participate in them with common goals". I'd need some help with that, since my technical expertise in these topics is not going to help much with the job at hand - namely, managing communication.

That is one of the reasons why we request at least two facilitators per topic. While you could focus on the topics at hand and that will surely attract the usual suspects, the other facilitator(s) could help better with the promotion tasks.

We organizers of the Summit can also help, if you tell us what you need.

Since facilitating a main topic is real work, I have created phab:T147406 to track my work bootstrapping "How to grow our technical community". Feel free to copy/improve the model.

I have created Wikimedia Developer Summit/2017/Program committee in order to have all the information and discussions about Program committee members and facilitators in one place.

On wikitech-l, @Brion VIBBER wrote "Opening up MediaWiki dev summit in January?" :

The last couple years we've done a big MediaWiki Dev Summit in January,
around the time of the Wikimedia Foundation all-hands meeting. Invitations
have been fairly broad to known developers, but there's a very strong
feeling that newbies, non-technical people, and in general *the people
MediaWiki is created and maintained for* are not welcome.

I think we should change this.

I would really like a broader MediaWiki Dev Summit that asks our users to
participate, and asks "developers" to interact with them to prioritize and
work on things that really matter to them.

I want template authors, Lua module authors, template users, power editors,
folks working on the lines of defense for vandalism patrol and copyvio
checking. I want people with opinions on discussion systems. I want people
who have been editing for years and have experience with what works and
what doesn't. I want people who wish they could edit but have a bad
experience when they try, and want to share that with us so we can help
make it better.

Thoughts?

-- brion

Much more conversation on the thread. I'd like to move that conversation to this wiki.

Thanks to RobLa for posting this, I would not have been aware of it. Thanks to Brion for bringing the subject up.

I've been made aware of this summit by a post on the MediaWiki-Distributors mailling list. I'm interested in participating but uncertain as my involvement in MediaWiki related things are low. A few years ago, I did dip my toe into some dev efforts surrunding MSSQL, LDAP and SemanticMediawiki. I got access to gerrit as well as the WMFlabs infrastructure and was able to propose a few patch and work in bugzilla. It just a little before the big switch to Phabricator. That change to Phabricator and all the changes surrounding it got the better of me and I gave up at that time. Today still, I'm struggling with new development efforts introduced after that switch (Composer, Lua and others) and keep myself on the LTS.

In any case, here is some suggestion of topics you could discuss (keep in mind, it's only suggestion and I've been out of the loop since a while).

• Difficulties of integration of MediaWiki Core, Semantic MediaWiki and WikiData. WMF is not using Semantic MediaWiki and focus mostly on WikiData. Although a lot of effort is made by peoples behind Semantic MediaWiki, I find still find it hard today to figures the where and what when you try to mix it all together. All by themself the blocks are well documented and easy to find, it's mixing it up that it. Why has Semantic not been adopted more broadly? What is the main difference between SemanticMediaWiki and WikiData? Was there too much effort duplicated?
• Recently there has been some developpment around Microsoft SQL support. Microsoft and others has shown a lot of interest and put a lot of effort into pushing the MSSQL Database implementation. I do have some interest into and I believes peoples are forgeting an very viable and forgotten alternative that is FreeTDS and Extension:MSSQLBackCompat. How can MSSQL support be brough into the mix while keeping the later able to run? And why is effor on MSSQL on Windows take so much place while MSSQL on Linux (thought FreeTDS) is pushed away? The main Databases classes are for heavy use and have a lot of code, is there a way to have a faster, easier and dummer Database class that would bring content into the wikitext and not have to worry with the whole compatibility with the main one?
• Speaking of Database, my feeling is peoples seem unaware of using two Databases drivers at the same time, yet that is a fantastic feature and I use in my own private instance to fetch data from outside the wiki tables. For example, my main Database driver is MySQL like almost everyone yet my MediaWiki instance does run query into some MSSQL Database through the previously mentionned extension.
• Speaking of content brought in from external source, I know there is a lot of talk this year about something else than text/plain or text/wikitext. What about pulling data from entreprise dashboard, external event, bus system, other database and what not? What could be done in the back end to bring more datasource to the rendering and parsing engine? What about pushing it back? What about readonly backend while the wikitext remain readwrite?
• Regarding developpement tools and WMF processes. Lately the foundation have got a lot of new toys and improvement around the developpement process. Those involved in those processes on a daily or weekly process can follows it with some easy but, in 2012, I felt the bar to contribute was quite high. Today, as a casual hacker, I don't see the bar anymore and I'm overwhelm with resuming any work within the source code.
• As a Debian user, the packaged version of MediaWiki is 1.19 and therefore it is still part of my work to work against the 1.19 code base. As you can imagine this is very hard to approch the new concept while still being dragged by use way of working from 1.19 era. What could be done to help package or be packge friendly? Why caused such a lag behind? There is bring new on this issue though, the lastest and newest is starting to appear on Debian due to some amazing work from many developers that tackle that issue and I'm looking forward to Debian 'Stretch' with MediaWiki 1.27!
• My use case of MediaWiki is behind a private firewall and therefore face some different challenge than WikiMedia. I believes most devs are familiars with those use cases as there was many presentation in years piors about use of the MediaWiki software elsewhere. But what is the future for them? Is there a middle ground between the CIA super isolated MediaWiki and the public non-WikiMedia MediaWiki server that use and consume contents from Commons and WikiData? What about two private users sharing between each others insteads? A 'Common' outside Commons and the public web but still sharable between two instances? What about sharing Template? Pulling the amazeball templates from Wikipedia and pulling it it? What about a better starting wikitext database with those fancy things peoples think for granted in Wikipedia but is not so easy to build from scratch? Available so close, right at your finger tips but it's breaking like choas so easily in your private instead?

Thanks you to all the devs for this amazing software even though my tone might have not appear cheerful in the previous comments, rest assured that MediaWiki's code base still amaze me everything I look at it. It's a fantastic endeavour and I'm very grateful for everyone's contribution to it. I'm cheering for your success! (sorry for my bad English, it's not my native language)

Given that there's already an active discussion on the mailing list, I don't see why we'd want to move it over to the wiki. I think moving it would just be disruptive to the productive (IMO) conversation that's already happening.

The reason for having the conversation here is because we can document and keep track of our conversation much better here than on the mailing list. It's a lot easier to link newcomers to a portion of the conversation, and broaden the conversation beyond just the mailing list.

It seems that it has been decided that attendance at this invitation-only event is restricted to "Wikimedia technical contributors and third party developers using the Wikimedia APIs or MediaWiki". That seems like a missed opportunity. It would have been preferable to consider how best to obtain input directly from users (readers and constributors) rather than through the necessarily restrictive lens of surveys, and to engage directly with their needs, expectations, concerns and wishes. It would also have been preferable to engage with community leaders who can engage on the subject of mismatch between community policies and developer initiatives (such as we saw with respect to the failed Gather initiative). I do not propose a specific mechanism here, and time may not be sufficient to resolve the issue in time for the 2017 meeting, but propose that this issue should be explicitly discussed at the Summit itself with the aim of developing proposals that would make for a more effective meeting in 2018.

On the contrary, there was a lengthy discussion in wikitech-l about opening the Summit to other profiles beyond developers, including users. Anyone involved in technical collaboration is a technical contributor, not just developers. Facilitators of the different main topics are being encouraged to reach out to the different stakeholders in their areas, beyond the usual suspects.

If you or someone you have in mind should be at the Summit, please (tell them to) request an invitation.

"On the contrary" to what? I quoted directly from the main page for this event for which this is the discussion page. Is that page wrong?

On the contrary to "It seems that it has been decided that attendance at this invitation-only event is restricted to". The event is a Developer Summit and the target participants are all Wikimedia technical contributors and third party developers using the Wikimedia APIs or MediaWiki. Users participating in the planning, development, testing, documentation, deployment, etc, of technical projects are technical contributors. We haven't declined the participation of any user requesting it.

At the same time, we don't want to mislead users potentially interested in this event. This is not Wikimania, and it is not intended to be.

The only sentence describing the invited attendance at this invitation-only meeting is "We welcome all Wikimedia technical contributors and third party developers using the Wikimedia APIs or MediaWiki." If it is intended to welcome some other groups, then perhaps a description of those other groups could and should be added to the main page. It is far from clear to me that "technical contributor" refers, for example, to a reader or content contributor with a request or requirement for new or improved forms of content presentation. Such a person would not regard themselves as a Developer, and is not likely to regard themselves as a natural fit for an event billed as a "Developer Summit" which is described as "invitation-only". If you mean that users interested in engaing with developers in the "planning, development, testing, documentation, deployment, etc, of technical projects" are intended and welcome invitees, then you need to say so. It is not really satisfactory to argue that people who are not obviously included in your invitation should somehow guess that they are in fact welcome to apply if they are not included in the "welcome" category.

OK, you are right. Is this better now?

Thanks.

In 2013, WMF was still holding it's traditional All-Hands meetings in September (rather than January). Just prior to the All-Hands, we had "Tech Days", which was a two day invite-only event.

ArchCom was new back then. That was where we were starting to plan the first Architecture Summit in January 2014.

This 2013 email (from me) about the event was only published publicly (by me) in early 2016:

• Architecture meetings/WMF Engineering All-Hands 2013/Intro.

We're just about at the same point (chronologically) in the planning process for WikiDev17 as we were in planning for Architecture Summit 2014. I believe I'm going to find myself repeating many of the things I said back then.

Please feel encouraged to repeat many of the things you said back then that you still consider important and/or not sufficiently resolved or unresolved, so they can be discussed (preferably in dedicated threads).

One important part:

The goal of all of the above is to have the architectural conversations that are just too hard to have over email and IRC, which are manifold. This will be the place where we can chart a multi-year course for MediaWiki development. This is somewhat similar to what (I think) the Linux kernel developers do at the Linux Kernel Developers Summit (I haven’t attended, so I’m mainly relying on third-party accounts).

Having Valerie Aurora's help in the final weeks leading up to WikiDev16 was extremely valuable, since she had first-hand experience participating as a kernel developer, and was able to provide a more informed perspective on the good and the bad of that approach.

Hello,

I'm interested in the UX topic. However, I wonder what the focus of the suggested session is. "Building a sustainable user experience together" can suggest different topics depending on what we want to focus on: Is sustainable meant to be "timeless" or "technically easy to maintain"? Does "together" mean that we want to find ways to collaborate closer with volunteers or is it meant to focus on collaborating between different disciplines like Visual, Interaction design, front-end-dev?

I find all these valid and important, but I suppose we are only able to focus on a few of these possible points. Also, there might be some expectation what the most pressing problems are.

Hi Jan, this is a question better suited for Talk:Wikimedia Developer Summit/2017/Building a sustainable user experience together. @Sherah (WMF) is the facilitator of that main topic (which yes, needs to have its focus and plans reflected in that wiki page -- sorry, we are all quite busy these days).

Bulleted list of ideas moved to WikiDev17/Topic ideas.

Summary of the discussion as of 2016-09-19:

• @Qgil-WMF proposes we collect (say) five main Summit topics. He hopes for input from WMF Product & Tech
• @KSmith (WMF) agrees making dev community more inclusive and productive is a worthwhile goal
• @Trizek (WMF) and @Florianschmidtwelzow had a number of ideas, which are captured at WikiDev17/Topic ideas

Remember that at least 50% of time and space will be dedicated to an Unconference setup that will allow the discussion to any other topic not making it to this short list.

Main topics agreed:

• A plan for the Community Wishlist 2016 top results
• Handling wiki content beyond plaintext
• A unified vision for editorial collaboration
• Building a sustainable user experience together
• Useful, consistent, and well documented APIs
• How to manage our technical debt
• How to grow our technical community

Let's collect here the proposals for (say) five main Summit topics to be defined beforehand, ideally complex topics with a high user impact (direct or indirect) and ramifications in multiple technical areas.

• Functioning code review process, because it affects our ability to ship better software faster, and our ability to recruit volunteer contributors to these efforts.

Background: https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/086476.html

Are we supposed to "vote" here?

I like the ideas of making the dev community more inclusive and productive, and improving the quality of the software. Neither aligns with the "product" focus that has been floated, but I think both are excellent long-term investments, and both put us at great risk if we don't accomplish them somehow. I just don't know if this event is the best place and time to take them on. (Maybe it is, and maybe it isn't--I literally don't know.)

There is no vote, although feedback is welcome (as you just did). The Foundation's Technology and Product departments are meeting this week and I hope to get those main topics defined with their input.

I really like the topics about Manipulating and distributing the content in MediaWiki (a very interesting RFC for this could be Multi-Content_Revisions. Also the real time collaboration topic would be a feature that a lot of people (including me) would really really love. Probably the dev summit could be used to initiate or probably create a high-level plan or at least a vision of this from the dev community and probably the editing team at WMF. Just an idea, but we can only do this, if we talk about the topic, so a session would be great :P

And the most important thing: the code review process. I'm not sure, if I'm the only one with this feeling, but since the reorganize of the technical department of the WMF sometime in the last year (or was it 2014?), It's a lot more difficult to get a review for a patch in here it, if no dedicated team supports the project (most importantly MediaWiki core, where several features aren't maintained by dedicated people or a team, like the old "core" team). We had the topic 2 years ago in the dev summit 2014 already, but probably we should discuss this again :)

This is a list of the ideas that various people put or collected in the summary of this discussion:

• Broad technical plan agreed for the hardest wishes among the Community Wishlist 2016 results.
• Functioning code review process, because it affects our ability to ship better software faster, and our ability to recruit volunteer contributors to these efforts.
• A plan for discussion pages in MediaWiki, because it is a key aspect of user collaboration and we are far from meeting all user expectations.
• How do we make manipulating the information on our websites easier and more useful? (both for humans and computers)
• How can we better distribute the information on our websites?
• How can we help our software development community be more inclusive and productive (and attract many more people)?
• How can we improve the quality of our software, and pay down the technical debt we've accumulated over the years?
• How can we make our websites better learning environments?
• How can we make our websites better support languages other than English (and character sets other than Latin)?
• Easier login to Wikimedia wikis allowing users to control their on-wiki identity (e.g. login using e-mail address, case-insensitive login, "display name").
• Merge the different feeds for the tracking changes pages (history, usercontribs, recentchanges, watchlist, logs, etc) to allow for easier maintenance and improvements. This would make it easier to add simple "re-designs" (layout tweaks, that can be toggled on/off) to all pages at once. This would make it easier for newcomer editors/readers to understand the contents of the various pages.
• Real-time collaborative editing. Often discussed, rarely planned at a long-term level.
• Consolidate work on MediaWiki core

I'm removing them from summary of this discussion thread because that list buries the discussion here, and don't represent an NPOV summary of the discussion. Some of the ideas I agree with wholeheartedly, and some of these belong as separate discussion threads.

Here's the list I posted to wikitech-l on 2016-09-07 , but formatted in a way that gives it more of an appearance of a taxonomy (rather than a random list of verbose ideas)

• Formats - how do we make manipulating the information on our websites easier and more useful? (both for humans and computers)
• Distribution - how can we better distribute the information on our websites?
• Inclusiveness - how can we help our software development community be more inclusive and productive (and attract many more people)?

• Quality - how can we improve the quality of our software, and pay down the technical debt we've accumulated over the years?

• Usability - how can we make our websites better learning environments?
• Multilingualism - how can we make our websites better support languages other than English (and character sets other than Latin)?

One way to slice things up: identify the communities of interest, and have representatives from each. For example:

• Formats - wikitech-l, wikitext-l, and Wikidata readers and participants
• Distribution - xmldumps, mediawiki-api, analytics-l, and research-l readers and participants
• Inclusiveness - Code of Conduct draft, meta:Grants:IdeaLab, GSoC, Outreachy participants
• Quality - qa and wikitech-l readers and participants
• Usability - usability mailing list readers and participants
• Multilingual support - translators-l, translatewiki.net

Not being heavily involved in many communities beyond wikitech-l, I can't speak to which ones are the most logical as focal points for activity, so the list above is really sketchy. The goal (I would hope) is that we use the Dev Summit as an opportunity to stir up conversations that we hope would make progress all year long and wouldn't require a face-to-face meeting to revive or help everyone get to know each other better.

Your "communities of interest" only seem to revolve around mailing lists and some very specific projects. How about identifying potential participants by canvassing relevant bugs from phabricator? For instance, multilingual support is not just about translators, but also about specific quirks of different languages (multi-spelling wikis like sr and zh come to mind, as well as the various tools described in Phab:T106996)

Thank you, Rob. Let's keep iterating until we have a short list of main topics that can be considwered a starting point.

So far the main topic that I see more clearly is

• Broad technical plan agreed for the hardest wishes among the Community Wishlist 2016 results. Probably with a better wording, but this is the idea.

There is one topic that hasn't been mentioned but it is the one that imho I hear more often when talking to actual Wikimedia users:

• Updating the MediaWiki user experience. The MediaWiki UX for readers hasn't changed much in a decade and it is showing an age. Meanwhile, in the internet... What needs to be done in our platform to enable a UX update?

In developer discussions this is a recurrent topic as well, from the perspective of how difficult is to change anything from a technical point of view (from a social point of view too, but our platform + desktop + mobile web + mobile apps is a challenge in itself). What do you think? CC @Sherah (WMF)

Then a proposed iteration on the community/collaboration ideas above:

• Improving technical collaboration. There are many angles to look at, all of them needing improvements: between developers (professional-professional, professional-volunteer developers, Wikimedia - MediaWiki 3rd parties), and between developers and users (developers-Wikimedia communities, developers-readers). The code review discussion, the Technical Collaboration Guideline, and the efforts to learn from existing and new readers would fit here.
• Improving developer outreach. Our developer community is quite stable, and getting old. We are struggling attracting new developers. How do we grow our developer community to the size and diversity that a popular project like Wikimedia would deserve? The "Inclusiveness" topic above is included here, but the main problem is outreach in general.

If we could settle on these topics and 1-2 more from the list above, I think we would have a good starting point for the call for participation, registration, and scholarships.

I very much like all the themes proposed in this topic. IMO, the second one should rather read "Revamping the MediaWiki user experience". It's not only about having a new experience, but also having a unified experience throughout the platforms (web, mobile, apps).

Thanks @RobLa-WMF and @Qgil-WMF for the summary in-topic and the first iteration to find good main topics! :)

I'm almost fine with the topics, they look as they would cover a lot of subtopics and keep enough space for discussions into different directions (which is, as I understand it, one goal, to find new/other solutions and think about ways how to fix/implement them, or to get a high-level plan). However, one suggestion for this point: > Updating the MediaWiki user experience. The MediaWiki UX for readers hasn't changed much in a decade and it is showing an age

Even if we've VisualEditor, a lot of editors still want and like to use the source/wikitext editor (and I understand why, it's a good and powerful editor, if you know the wikitext syntax. Having this in mind, the MediaWiki UX hasn't changed a lot for both, readers and editors. So probably we should open the discussion for both parties. For the editing side I've task T104479 in mind, which tries to solve this, so the question could be: How can we attract editors to use it, or better test it in an early state and give feedback, so it will be a success from the beginning (not like the first start of the VE itself)? This is just an idea, but, to come to the point, I wouldn't limit the topic to readers only (even if they're really important, too).

Best, Florian

I've got three topic suggestions, with an illustrative (but not exhaustive) list of sessions that would fit under each:

• (A unified vision for) Collaboration
  • Real-time collaboration (not just editing, but chatting, curation, patrolling)
  • WikiProject enhancements: User groups, finding people to work with, making these first class DB concepts
  • Civility/diversity/inclusiveness, mechanisms to handle/prevent harassment, vandalism, trolling while working together
  • Real-time reading -- watching edits occur in real time
  • Integration with WikiEdu
  • Broadening notion of "an edit" in DB -- multiple contributors, possibly multiple levels of granularity
  • Tip-toeing toward "draft"/"merge" models of editing
  • Better diff tools: refreshed non-wikitext UX, timelines, authorship maps, etc.
• Improving Modular Wikitext Maintenance
  • Infoboxes from wikidata, categories from wikidata, wikidata in commons, oh my!
  • Visual editing of templates, alternative template mechanisms, etc
  • Wikitext 2.0 -- how to shave off the rough edges but still provide a text-based power-user editing interface
  • Global pages, Global templates, etc
  • Improving composition of text and media content on the page
  • Moving to a Glossary model for LanguageConverter rules
  • Splitting metadata (categories, page flags, etc) from content in the DB
• Doubling down on Machine Translation
  • Annotation service to record fine-grained translation correspondences between wikis over time (not just at the time of first translation)
  • Suggestion service to suggest new edits to wiki A when translated text wiki B is modified (or vice-versa)
  • Refactoring existing language converter pairs as (sometimes trivial) translation engines, eg cyrillic-to-latin
  • Building a translation engine in house, training it with translated wiki pages, improving it over time, etc
  • Tightly integrating the translation UX for everyone. More: one community wearing babel fishes / Less: scattered villagers after the Tower of Babel fell.
  • Improving harassment/vandalism/civility/inclusiveness/diversity mechanisms to handle these larger cross-cultural communities.
  • i18n of global pages, global templates, etc. May need mechanisms to allow translation of comments, for example.

I made a big series of edits to WikiDev17/Topic ideas to make it easier to:

1. Cover the breadth of what we hope to cover
2. Have deeper discussions in particular areas
3. Consolidate ideas and refine the prose of the proposal

In making it, I consolidated a lot of the ideas of this thread into a similar series of topics to what @Cscott, @Qgil-WMF, and I proposed above. Additionally, each proposed topic has a talk page topic on Talk:WikiDev17/Topic ideas. @Florianschmidtwelzow and @Strainu I wasn't ignoring you; there were a couple of tweaks that I made based on your comments, too, but please review and feel free to repeat yourself if I missed something (sorry for making you repeat yourself).

I am leaving feedback in those topics. Rob, I think a common problem is that you seem to be working on "areas" while I am trying to define "main topics". These a re different concepts, even when main topics may be mapped to areas. The difference is that a main topic has a narrower scope and an intention, which (in theory) helps decide which volunteers and other stakeholders should be invited, which proposals should be pre-scheduled, which problems do we as a community focus on in this event.

Let me put together the titles for main topics that I have been suggesting in the different discussions at Talk:Wikimedia Developer Summit/2017/Topic ideas, only to see how they look like when put together:

• A plan for the Community Wishlist 2016 top results
• Handling wiki content beyond plaintext
• A unified vision for editorial collaboration
• Building a sustainable user experience together
• Useful, consistent, and well documented APIs
• How to manage our technical debt
• How to grow our technical community

I think this looks "good enough". Do you agree? We can fine tune the wording and we will have to create subpages for each with their updated descriptions (which can also evolve through the regular wiki way).

These are eight main topics that potentially cover a lot of possible discussions. I think they provide enough drive to the Summit, help participants to consider joining and proposing activities, and help organizers sponsoring travel and organizing the pre-scheduled sessions.

Proposals unrelated to these main topics can find their way through the Unconference. If any of these proposed main topics doesn't reach a critical mass in practice, we could also channel it through the Unconference. Also, there is a chance that unrelated sessions end up being pre-scheduled, if there is a good reason for that.

+1. It's a big list :)

Yup, I think this is good enough. One way we can arrive at areas is to ask ourselves "which fora would be interested in discussing this topic?", "which set of people are the key stakeholders in addressing this main topic?", etc. The answers to those questions will likely tell us what our areas should be.

For example, some of these topics are well suited to an ArchCom-RFC. Others probably involve different discussion/decision tools.

(p.s. let's talk about this topic at the next ArchCom Office Hour, if y'all are available. Details will be posted here shortly: Phab:E285)

The main topics are now agreed. I have edited the summary. Thank you to all participants! This is just the beginning, of course.

A few comments:

• There's a div overlap problem with the current design.
• Hiding the default H1 header:
  • This is confusing for people (like me) who expect to find it in a consistent location.
  • This creates a problem with the "Gadget-edittop.js" gadget (per my screenshot)
• I personally prefer a plain or default aesthetic for wikipages, for a few reasons.
  • It makes it easier to edit the contents in both wikitext and visual editor.
  • Aesthetics are subjective, which is part of the reason why the wiki communities have generally used a very simplistic styling. Aka "content is king". Any embellishments purely for aesthetic reason can hence be problematic - either distracting to a subset of users, or subjectively 'ugly' to a subset of users. Plain wikipages might be 'boring' (in some opinions), but they're not actively offputting.
• Photo:
  • I don't think the current header photo (the building&landscape) is a good, because attendees will be inside most of the day, talking to people. People (and the projects they create) are the focus of the event, and not the location.
  • It's also extra bandwidth to download on mobile, and attendees will likely be checking the page regularly in order to see the schedule, throughout the event.

Ping @Qgil-WMF for feedback. Hope that helps.

I have played a bit with the divs. Does it look better now?

The tagline is lost in mobile, but I don't know how to solve it. "Mobile view" in desktop looks fine, but not on an actual mobile device.

Still, I think this is good enough to unblock the opening of registration.

The div overlap is fixed, at least in my browser. Thanks.

I still object to over-riding the page-title in particular. I suggest putting that back to normal, but leaving the sentence "The annual meeting to [...]" with the fancy overlay styling.

More importantly, the registration cannot open and point to the page until the blue buttons are fixed! (They currently have strikeout styling and lead to irrelevant targets)

Those divs need to work well, that is for sure.

The primary target of this page are the people who don't know about the Summit and might have an interest in being there. The intention is to make this page informative and attractive for that people. Having an event landing page that looks as much as possible like an event landing page and not like a Wikipedia article is not a bad thing imho. Most conferences and events sport big images and fonts, yet they seem to be doing quite well. A plain wikitext page can be off-putting indeed, when the impression it gives is that it is some documentation about an insiders' meeting.

Confirmed participants in the event (like you in a few days) will look at this page once or twice, and then rely on Wikimedia Developer Summit/2017/Program for their frequent checks. The landing page will keep being a rather static page to capture new participants.

Extra bandwidth on mobile... These days anybody checking Facebook etc on mobile are downloading a lot more bandwidth every minute, and they don't even notice or care.

@Rfarrand (WMF) @MKramer (WMF) more perspectives are welcome!

I really like to image and the new look of the page. It makes it seem more professional and inviting - but thats just my perspective.