Jump to content

Topic on Talk:Wikimedia Developer Summit/2017

Proposals for main topics

17
Summary by Qgil-WMF

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:

  • 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
Qgil-WMF (talkcontribs)

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

KSmith (WMF) (talkcontribs)

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.)

Qgil-WMF (talkcontribs)

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.

Florianschmidtwelzow (talkcontribs)

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 :)

RobLa-WMF (talkcontribs)

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.

RobLa-WMF (talkcontribs)

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.

Strainu (talkcontribs)

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)

Qgil-WMF (talkcontribs)

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.

Strainu (talkcontribs)

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).

Florianschmidtwelzow (talkcontribs)

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

Cscott (talkcontribs)

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.
RobLa-WMF (talkcontribs)

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).

Qgil-WMF (talkcontribs)

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.

Qgil-WMF (talkcontribs)

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.

RobLa-WMF (talkcontribs)

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)

Qgil-WMF (talkcontribs)

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

Reply to "Proposals for main topics"