Wikimedia Technical Conference/2018/Session notes/Making curation and contribution mechanisms equitable and consistent

Description: A key hurdle to providing an equitable experience to new and emerging communities is unlocking the powerful tools developed on older projects. This session examines the ways we can provide access to these tools “out of the box” for new projects, and remove the gap in toolsets between larger and smaller projects which have fewer users.

Questions and answers
= Features and goals =

= Important decisions to make =

= Action items =

= New Questions =

= Detailed notes = Place detailed ongoing notes here. The secondary note-taker should focus on filling any [?] gaps the primary scribe misses, and writing the highlights into the structured sections below. This allows the topic-leader to check on missing items/answers, and thus steer the discussion.


 * [Insert slides here]
 * Focus on Global aspects. Lua and similar
 * We're not going to be able to solve everything!

Breaking into 3 groups to discuss:

What do we need to do to support gloval tools/bots/gadgetsWhy are many of these tools NOT transferable/usable by multiple communities



Global gadgets and templates.


 * Do we need it at all?
 * How do we improve code reuse?
 * What is the priority?
 * Lack of ability to see changes
 * What can we do this year?
 * Take gadgets and put them somewhere with proper code review system. E.g. git. Make them globally re-usable somehow.
 * Put things in Version Control.
 * Package management
 * NOTES:
 * Some things can be reused with 3rd party wikis
 * Sharing things from enwiki requires so many precursors
 * Lots of value in providing them
 * Something like instantcommons?
 * Lacking support for javascript changes
 * Copying, testing, etc
 * If we provide support to overcome technical hurdles, how do we scale?
 * Some content should be in actual code-version system
 * Gadgets probably
 * Lua modules probably
 * Templates unlikely
 * Current support for Lua?
 * We have CI for javascript, so backend requirements are known
 * Challenge - Integration: How to show things in Recentchanges? - probably not primary, but as a mirror
 * Ideally CI would support some level of debugging
 * Via wiki-page updating, publishing a change on github could push a comment to a wikipage
 * Is it possible to do now?
 * As a prototype, yes
 * French Wikipedia community has already moved their gadgets to github
 * Wider community needs to make a decision about hosting locations -
 * Maybe have Per-gadget decisions on where to host? E.g. [foo] goes on github, and [bar] goes in gerrit
 * Gerrit too complicated for most non-developers and some newcomers
 * WMDE has some experiences and libraries with doing CI on github
 * Hosting our own gitlab? Similar to gerrit, a relevant question is "how much does free cost?"
 * Con to gerrit: existing backlogs and unreviewed patches
 * Access controls - if the code resides on github, we need different permision systems for the threat of account takeover.
 * Is this something we should focus on? Every major decision that leads to more responsibility for us, requires more ongoing resources.
 * Need even more details on costs/benefits…
 * Templatewiki as first priority? More complex caching challenges - for gadgets updates would be done manually, existing cache invalidation system can deal with that.
 * Need to understand all the social challenges and options
 * How can we re-use code more efficiently - more libraries?
 * Would we also enforce code-reuse?
 * How to make libraries discoverable? Lack of advertising is part of why existing libraries aren't well used.
 * Provide more docs for OOUI
 * Community dev wishlist - wanted better dialogue-widgets.
 * Related: Frameworks and evolution. React, Fountain, etc etc etc.
 * Incentivizing by providing new libraries at hosted locations
 * Documentation could be automated
 * Advertising could be automated
 * Toolhub - https://meta.wikimedia.org/wiki/Toolhub
 * Something like npm tags for [?]
 * Point to github raw?
 * Documentation standards?
 * Package management? Npm publish? Yarn?
 * Access controls? Smaller problem.
 * Are we recommending the Community does this? Or offering to help? Or leading by example? - Lead by example, provide standard pathway,
 * Gadgets have always been one of the ways that volunteers add immense value. It often goes very slow.
 * We could get away from changing core with gadgets, and move to more standalone 'apps' using web extensions
 * [Created a dedicated toolkit for a framework in which gadget authors could work?]
 * E.g. tools on toolforge could benefit from a more consistent UI. OOUI is currently quite complicated. We want a bootstrap 3.0 with Wikimedia theming!
 * Onwiki gadgets benefit from avoiding OAuth complexities.
 * Contributors want configurable display options
 * Why do we need individual installation
 * Gadgetwiki ?
 * Templates: Only create global modules, and not global templates? Templates can often be simply localized Wikitext shells for a module.
 * Much easier to provide custom
 * If we say JS gadgets become repos, and aren't synced to a wiki, would we do the same with modules? We do have a lot of users who understand a bit of javascript. We don't necessarily want to push them towards git.
 * M
 * Packamanget management one click, confidence of team supporting
 * Is priority template or gadgets?  Templates are more important but harder. JS has more security implications.

Global features


 * Central auth
 * OAuth
 * Translatewiki
 * Recentchanges/watchlist/eventstream
 * Global moderation
 * Global permissions

Qs

What is holding us back?

Priorities (i.e. money)