Bulleted list of ideas moved to WikiDev17/Topic ideas.
Summary of the discussion as of 2016-09-19:
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:
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.
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:
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)
One way to slice things up: identify the communities of interest, and have representatives from each. For example:
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
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:
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:
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.
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:
I made a big series of edits to WikiDev17/Topic ideas to make it easier to:
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:
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.
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.