Wikimedia Developer Summit/2017/Topic ideas

Ideas originally collected in Talk:WikiDev17:"Proposals for main topics" (talk page topic started 2016-09-08 by QGil)

Wikitext
Comments welcome!

How do we make manipulating the information on our websites easier and more useful? (both for humans and computers). Also: how to improve "Modular Wikitext Maintenance" -- the underlying template/etc mechanisms we use to make our content easy to update, maintain, and reuse, without increasing the barrier-to-entry of new editors. Fora: wikitech-l, wikitext-l, and Wikidata readers and participants
 * 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
 * Multi-Content Revisions

Distribution and Analysis
Comments welcome!

How can we better distribute the information on our websites? What data should we make available? How should we offer it? What APIs should we offer to manipulate our content? Topics to discuss: Kiwix, ORES, Bots, RESTbase.

Fora: xmldumps, mediawiki-api, analytics-l, and research-l readers and participants

Collaboration
Comments welcome!
 * 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.
 * Functioning code review process, because it affects our ability to ship better software faster, and our ability to recruit volunteer contributors to these efforts.
 * Consolidate work on MediaWiki core
 * (A unified vision for) Editor Collaboration
 * 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.
 * Real-time collaboration (not just editing, but chatting, curation, patrolling). Often discussed, rarely planned at a long-term or cross-team level.
 * 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 -- a class is a wikiproject or user group, mechanisms to push quizzes/surveys/assignments/etc and pull completed homework.
 * 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.

Inclusiveness
Comments welcome!

How can we help our software development community be more inclusive and productive (and attract many more people)? 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.

Fora: Code of Conduct draft, meta:Grants:IdeaLab, GSoC, Outreachy participants

Quality
Comments welcome!

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

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

Fora: qa and wikitech-l readers and participants

Usability
Comments welcome!

How can we make our websites better learning environments?

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?

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.

Fora: usability mailing list readers and participants

Multilingualism
Comments welcome!

How can we make our websites better support languages other than English (and character sets other than Latin)?

Concrete suggestions at Internationalisation wishlist 2014.

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

Related:
 * Tightly integrating the translation UX for everyone. More: one community wearing babel fishes / Less: scattered villagers after the Tower of Babel fell.
 * If we're to make machine translation work as seamlessly as language converter, translated pages need to "feel" tightly linked to source pages in the UX, and this will have broad effects.
 * Improving harassment/vandalism/civility/inclusiveness/diversity mechanisms to handle these larger cross-cultural communities.
 * If machine translation is used to synchronize language communities, we also need to deal with vandalism and harassment, not blindly translate it.
 * i18n of global pages, global templates, etc. May need mechanisms to allow translation of comments in script code or templates, for example.
 * We can use the same translation tools to aid mutual intelligibility and synchronization of our "code" not just our "content".

Fora: translators-l, translatewiki.net, mediawiki-i18n

Wishlist
Comments welcome!

Broad technical plan agreed for the hardest wishes among the Community Wishlist 2016 results.