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
How do we make manipulating the information on our websites easier and more useful? (both for humans and computers). Improving Modular Wikitext Maintenance 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
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

 * 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.
 * 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 collaborative editing. Often discussed, rarely planned at a long-term level
 * Consolidate work on MediaWiki core
 * (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.

Inclusiveness
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
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
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
How can we make our websites better support languages other than English (and character sets other than Latin)?

Doubling down on Machine Translation Fora: translators-l, translatewiki.net
 * 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.

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