Seems to relate to T121470: Central Global Repository for Templates, Lua modules, and Gadgets and a lot of associated tasks. A potential worry is we end up reinventing in MediaWiki systems to conduct code review, conduct test and manage a software life cycle. I would guess the main issue is to make a "business case" for it, have it funded and commit to implement the product.

In the early days of MediaWiki, one would code the feature inside MediaWiki itself then wait for it to be reviewed and deployed (which could take a few months). That also requires knowledge of PHP as well as acquaintance with other developers. Over the years, that has been decentralized:

• The addition of hooks delegated that responsibility out of MediaWiki core and its maintainer to extension authors and eventually reaching a fixed schedule for deployment (weekly based). The ProofreadPage extension for wikisources wikis or AbuseFilter are probably good examples.

• MediaWiki templates have delegated a lot of formatting to editors, needs which previously could only be addressed by coding PHP in MediaWiki. That quickly became hard to maintain, infobox are a good example. The Lua modules at least lets one use a proper programming language instead of a lot of curly braces.

• Gadgets fill a lot of use cases, though I do not know how they are tested they might be risky?

In all cases, there are surely very helpful templates or modules which we might want to "upstream" as MediaWiki extensions or even as core functionalities of MediaWiki itself. That might help resolve the burden of synchronizing them between wikis and ensure the code is properly maintained. I would guess infobox would be a good case for upstreaming.

Anyway I am interested, if there is no conflict for me with another session.

Modules and templates must be all global, at least optionally. It's not just a necessary change for the MediaWiki platform as it is used by Wikimedia; it's the most necessary change.

As a pet project, I wrote a fairly detailed functional product-level plan for making modules and templates global, if anyone is interested: short version / long version (plug: if anyone has time to translate these pages into French, German, Spanish, Russian, or other languages, it will be very useful). I heard some support for this plan from a bunch of community members from several wikis. I'll be flattered if it's added to the "Pre-reading for all Participants" section.

What I don't have is a technical plan for implementing it. There were some proposals about this; the most notable is probably Shadow namespaces. But AFAIK none is detailed enough to cover the necessary use cases. In addition, it would make a lot of sense to break up this HUGE intimidating task to several manageable stages. This conference should be a good opportunity to do it.

I'll be happy to lead the discussion on making templates and modules global, but there should be commitment of relevant people from Core Platform, Parsing, Visual Editor, and perhaps SRE and Wikibase to participate and contribute.

Gadgets should be global, too, but this project will be completely distinct and probably much easier than templates. In fact, it's already kind of possible, albeit quite hacky, to make Gadgets global. WikidataInfo and HotCat are fairly well-known examples. So making Gadgets global is a valid topic for discussion, but its important not to mix it up with modules and templates.

I've suggested splitting out some aspect of Gadget related stuff to: T234957. Please feel free to comment there, disagree with separating, etc!

In T234661#5556881, @WMDE-leszek wrote:

I've suggested splitting out some aspect of Gadget related stuff to: T234957. Please feel free to comment there, disagree with separating, etc!

Makes sense to me. My experience from discussing this for several years tells me that gadgets should be discussed separately, if we are actually interested in seeing a solution implemented (I know I am). I commented in more details on that task.

I'm marked as a note taker for Tech Conf, I'm not positive what the schedule is for note takers yet but if it's at all possible I'd like to attend this session either in that capacity or generally.

I agree with Amir that this is a very important topic.
For example, Wikisource workflows rely a lot on templates that are slightly different in each wikis, making very hard hard to roll out change in all wikis. It leads to an increasing technological gap between big and small wikis.
Global templates/modules might decrease the technical gap that exists between wikis.

I am not aware of any volunteer written extension deployed on Wikimedia cluster in the recent years (except maybe CodeEditor?), so the already existing "extension solution" does not seem to solve this need in practice.
However, indeed, completely duplicating the existing development workflow does not seem to be the best solution either.

To summarize, there is a huge room for discussions on how the templates/modules duplication problem should be solve, and the TechConference seems a good place to start drafting what a possible solution might be.

In T234661#5552190, @hashar wrote:

I would guess the main issue is to make a "business case" for it, have it funded and commit to implement the product.

Hey @hashar yes, that's the idea behind the session. This is mainly the reason why templates, modules, gadgets, scripts are covered in the same session proposal. As we are probably tight with the schedule, one idea how we could do it (to pick up @Amire80's and @Tgr's and @WMDE-leszek's comments):

Developer Productivity and Onwiki Tooling (2 hours)

• Intro, general overview, goals of the session (20 min)
• Breakout groups: a.) T234957; b.) Modules/templates (40 min)
• Get together in big group, breakout groups present their key results (20 min)
• Bring the different aspects together + agree on recommendations/way forward (this will need some prep work + good planning, but should be doable) - 40 min

I'm happy to take over the framework part - intro, and the planning for the last 40 min (with input from the breakout group leaders). @Amire80 could run the modules/templates breakout group, and @WMDE-leszek would be responsible for the gadget session? Eventually we could also try to get more time in the schedule, depending on how many participants would be interested in this/how much time other sessions will need. What do you think?

Oh - I confused "@Tgr" and "@Tpt", really sorry ;) - @Tpt what do you think? :-)

In T234661#5564212, @WDoranWMF wrote:

I'm marked as a note taker for Tech Conf, I'm not positive what the schedule is for note takers yet but if it's at all possible I'd like to attend this session either in that capacity or generally.

Thanks @WDoranWMF! I'll add you to the task description - it should be possible unless it overlaps with the team practices session ;)

@Bmueller Thank you for the proposal! It looks great to me. +1 to split into two groups. Having a significant amount of time like you proposed for the last step with everyone seems very useful to me because the two groups conclusions might overlap and/or conflict significantly.

I went bold and added https://www.mediawiki.org/wiki/User:Amire80/Global_templates_draft_spec/TLDR to pre-reading. It's a very personal and unofficial proposal, and it explicitly excludes gadgets (even though it's totally find to discuss gadgets, too; I just want to discuss them separately in order to focus better). However, a bunch of editors from several wikis told me they liked this plan and its (much) longer version, so perhaps it can be a useful starting point. If I'm wrong about anything, please revert me :)

I think this is pretty important for our movement. I have helped some newly created Wikipedias with their templates and modules and it is extremely lenghty and frustrating. They lack everything, and normally technical people is not among the wikimedians in that language. We should imagine a way in which every functionality is present (as images are in Commons) and you can override locally everything.

In T234661#5553373, @Amire80 wrote:

Modules and templates must be all global, at least optionally. It's not just a necessary change for the MediaWiki platform as it is used by Wikimedia; it's the most necessary change.

As a pet project, I wrote a fairly detailed functional product-level plan for making modules and templates global, if anyone is interested: short version / long version (plug: if anyone has time to translate these pages into French, German, Spanish, Russian, or other languages, it will be very useful). I heard some support for this plan from a bunch of community members from several wikis. I'll be flattered if it's added to the "Pre-reading for all Participants" section.

What I don't have is a technical plan for implementing it. There were some proposals about this; the most notable is probably Shadow namespaces. But AFAIK none is detailed enough to cover the necessary use cases. In addition, it would make a lot of sense to break up this HUGE intimidating task to several manageable stages. This conference should be a good opportunity to do it.

I'll be happy to lead the discussion on making templates and modules global, but there should be commitment of relevant people from Core Platform, Parsing, Visual Editor, and perhaps SRE and Wikibase to participate and contribute.

Gadgets should be global, too, but this project will be completely distinct and probably much easier than templates. In fact, it's already kind of possible, albeit quite hacky, to make Gadgets global. WikidataInfo and HotCat are fairly well-known examples. So making Gadgets global is a valid topic for discussion, but its important not to mix it up with modules and templates.

In T234661#5553373, @Amire80 wrote:

As a pet project, I wrote a fairly detailed functional product-level plan for making modules and templates global

@Amire80: That sounds like material for T121470 where I cannot find this link?

In T234661#5570947, @Aklapper wrote:

In T234661#5553373, @Amire80 wrote:

As a pet project, I wrote a fairly detailed functional product-level plan for making modules and templates global

@Amire80: That sounds like material for T121470 where I cannot find this link?

True. I added it there now.

Super important topic that would really deserve its own session:

• understanding the onwiki tool developer community (metrics, surveys, community maps etc - unlike say MediaWiki developers we know next to nothing about them, especially on the non-English projects, they are not included on the technical community dashboard metrics etc.)
• developer engagement for onwiki developers (documentation, mentorship/training, capacity matching, UI learning curves, documentation, support channels etc) - our traditional efforts in these areas typically don't cover on-wiki developers well
• supporting sane development workflows (code review, CI and manual testing, IDE integration) - gadgets and modules/templates are probably not too different in this one
• globalization/sharing (inside and outside Wikimedia projects), tool discoverability, internationalization and customization (here, gadgets are pretty different)
• gadgets and security (not strictly a developer productivity topic, but security restrictions necessary in the current regime result in security restrictions that limit productivity)
• logging and monitoring for gadgets
• building or providing design and user testing expertise for templates
• templates and structured data (I wrote an essay on that some time ago)

There's also a (draft) movement strategy recommendation on the topic.

Thanks @Tgr! @Amire80, the goal of this session here would be to discuss a variety of questions, and come up with a list of recommendations and concrete ideas to improve developer productivity in the area of templates, modules, and gadgets. (See also Tgr’s list) Brainstorming technical solutions for global modules and gadgets only/specifically would make an awesome follow up session in the unconference part of the conference though, if you are mainly interested in that. Also - @Tgr, would you be interested in helping to run the breakout group?

In T234661#5584790, @Bmueller wrote:

Thanks @Tgr! @Amire80, the goal of this session here would be to discuss a variety of questions, and come up with a list of recommendations and concrete ideas to improve developer productivity in the area of templates, modules, and gadgets.

Similar topics were discussed in last year's tech conf, so can the discussion continue from where it stopped then? It's documented fairly well in the photos at T206056, T206060, and T206085.

@Amire80, yes. Ideally, we'd use a part of the first 20 min ("Intro") to provide an overview on known issues to get everyone on the same page. We should also add links to the outcome of sessions that cover aspects of this topic to the pre-reading list, so that we can build upon previous discussions in the breakout groups. Let's talk about this in more detail next week, when the session plan is finalised and session leaders can start to work on their sessions :-)

In T234661#5584790, @Bmueller wrote:

@Tgr, would you be interested in helping to run the breakout group?

Sure!

In T234661#5588306, @Tgr wrote:

In T234661#5584790, @Bmueller wrote:

@Tgr, would you be interested in helping to run the breakout group?

Sure!

great :-)

(Programming note)

This session was accepted and will be scheduled.

Notes to the session leader

• Please continue to scope this session and post the session's goals and main questions into the task description.
  • If your topic is too big for one session, work with your Program Committee contact to break it down even further.
  • Session descriptions need to be completely finalized by November 1, 2019.
• Please build your session collaboratively!
  • You should consider breakout groups with report-backs, using posters / post-its to visualize thoughts and themes, or any other collaborative meeting method you like.
  • If you need to have any large group discussions they must be planned out, specific, and focused.
  • A brief summary of your session format will need to go in the associated Phabricator task.
  • Some ideas from the old WMF Team Practices Group.
• If you have any pre-session suggested reading or any specific ideas that you would like your attendees to think about in advance of your session, please state that explicitly in your session’s task.
  • Please put this at the top of your Phabricator task under the label “Pre-reading for all Participants.”

Notes to those interested in attending this session

(or those wanting to engage before the event because they are not attending)

• If the session leader is asking for feedback, please engage!
• Please do any pre-session reading that the leader would like you to do.

What slows me down is not having an efficient quick way to filter properties that don't include " ID" (non-authority properties), in various Property explorer tools such as the excellent https://tools.wmflabs.org/prop-explorer/
Perhaps other Property explorer tools have a quick filter mechanism for this? I tried a simple regex in the Label column filter, but it doesn't work. https://github.com/stevenliuyi/wikidata-prop-explorer/issues/1

Perhaps there could be a universal way for Property explorer tools to more easily provide this filter mechanism such as enhancing some Wikidata API's?

I created a subtask for collecting the answers (hopefully helps with reducing the comment notification spam in both directions): T237490: Collect feedback from module and gadget authors for Developer Productivity & onwiki tooling techconf session

End of first session (part 1) pictures of sticky notes:

Some ideas for improvement from our sub-group discussion:

• From the gadget list on https://en.wikipedia.org/wiki/Special:Preferences link to https://en.wikipedia.org/wiki/Special:Gadgets (the existence of the latter is not obvious from the user preferences. And/or add the "view source" links to the list in user preferences.

• From the gadget list link to "report a bug" for each gadget. Create Phabricator tags for each of them following the same naming scheme (gadget-x). Some gadgets have this but only a few and Phab tags are named inconsistently. Users searching for it probably find the tag for the extension that lists gadgets which explicitly says this is not for reporting issues with gadgets themselves.

• At the bottom of an edit page add a message saying which gadgets are in use to make it more obvious. Some gadgets are enabled by default and users don't even know they are using them.

• Identify the most used gadgets and "adopt" them into MediaWiki itself so they are not gadgets anymore. (Which would involve code review).

• Create a "wiki remote" which allows git pushing to wiki after code review in Gerrit or another code review tool.

• Identify the most duplicated user scripts across wikis and attempt to turn them into gadgets to avoid duplication.

Part 2 pictures of sticky notes:

Notes from etherpad:

Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
Developer Productivity and onwiki tooling
Session Leader: Bmueller, WMDE-leszek, Amire80, Tgr

https://phabricator.wikimedia.org/T234661

Session Attendees (rough estimate: about 45 people)
Alexandros Kosiaris, James Forrester, Jeena Huneidi, Moriel
Schottlender, Timo Tijhof, Piotr Miazga, Ryan Kaldari, Stephen
Niedzielski, Cormac Parle, Tyler Cipriani, Greg Grossmeier, Daniel Zahn,
Bryan Davis, [+ cpl dozen more]

Tasks for Documentation Sprint

• DONE: Transcribe post-its with who am I / what is my issue
• DONE: Transcribe post-its with ideas for solutions

Notes:

• https://docs.google.com/presentation/d/10ls0ZH29e173YB1KtesPYshfdheTf-i7qlPYL2wh9G4/edit?usp=sharing
• Programming notes:  2 breakout rooms.  Gadgets/scripts and templates/modules.
• Issues transcribed from Phabricator have been distributed to discussion subgroups for discussion/triage.
• Unnessecarily complicated gears
• Tools will not be discussed in this session
• Goals: Shared understanding on key issues, prioritized list for improvements including impact/cost estimate.
• Recurring themes in gadgets/scripts small-group discussion:
  • Code management and hosting, automation of code publication from external repositories (Gerrit, GitHub)
  • Code review
  • Dependency management
  • Testability
  • User-metrics - Who uses what?  
  • Communication - How are users/developers informed of changes?

Gadget/Script -- Who / Problem statements (transcription of
post-its)

• Volunteer developer, Wikimedian, Wikipedian for many years, also WMF staff. Has worked on various gadgets, scripts, userscripts, templates, modules for many reasons, copy pasted and reused in many cases.
• Volunteer. Used Hotcat on en.wiktionary to categorize about 20K uncategorized pages. Would not have been possible without HotCat. We should try to stop using so many duplicate code lines. It would require turning userscripts into gadgets.
• WMF staff member, Analytics. Not affected at all by gadgets. Has experience analyzing and categorizing content en masse.
• Engineering Manager, WMF. Understanding of gadgets/userscripts rather limited. INterested in how both of these things could be encorporated with what is considered software development best practice - i.e. CI release/integration testing, versioning, branching.
• Engineering Manager, WMF. 
  • Issues: Deploying gadgets requires special rights
  • No "Sandbox" for creating a gadget before deploy
  • No code review, line based feedback mechanism
  • cross wiki sync missing
  • translation of gadgets is not easy
  • configuration of gadgets is difficult
• volunteer developer of scripts, gadgets, bots and tools developer at frwiki and wikidata, and I do some occasional training for Scribunto beginners, even though I'm not very active in modules development. (from phab ticket)
  • Generally happy, things that could be better: Lack of attention from upstream to the tools that people actully use; lack of propper maintainership. More integration with existing tools so that developers can use their development systems of choice.
• Volunteer developer who has created several gadgets on EnWP. Due to increasing restrictions on access to the MediaWiki namespace, I can no longer maintain my gadgets or respond to bugs.
• WMF, Director of Engineering. As a user of gadgets I have a hard time knowing where to go to slove my needs. I usually just discover things from coworkers, namely James F. But not everyone has a James F ... .
• As a person who is going to work on a Desktop Refresh project I have no idea what are "possible UI differences" caused by gadgets
• As a WMF developer I have no idea what "lives" on each wiki. Sometimes our change doesn't work on some wikis and we have no idea why.
• The quality of user gadgets/scripts is usually pretty low. No tests/bad performance. Flagged Revs could help?
• Moriel
  • I'm WMF staff, developing extensions and gadgets
  • I help develop and fix gadgets on-wiki with primarily OOUI
  • Issues:
    • OOUI is not as easy to use in on-wiki gadgets (requires extending classes, instantiating multiple tools before they can start actually building)
    • No code review!!
      • bad practices all around, affect other code, hard to fix.
    • No good way to contribute
      • no convention on storing code in github for allowing contributions
    • Extensions - no repo to know what exists
    • MWStew <3 MWCLI <3
• Volunteer dev cswiki
  • Unix-like diffs for Lua/JS (using wikitext diffs is strange)
  • matej_suchanek
• I am Niharika. I work as a Product Manager on the Anti-Harassment Team
  • My issue is that my team's projects can end up breaking gadgets across projects. It is hard to know [when this has happened]{.underline} and [who is responsbile]{.underline} for resolving this problem.
• James
  • All gadgets and site scripts are terrible
• Timo
  • Developing gadgets since 2010
  • rewrote the gadget system in 2013 (resourceloader)
  • Issues:
    • slow-down: duplication
    • completeness: localisation
• Daniel: WMF/CPT
  • Gadgets break when we change skins or JS code. Need stable interfaces
• MusikAnimal. Gadget developer and problem maker
  • My gadget is on ~12 wikis, all different versions
  • Hard to localize
  • JSON behind ResourceLoader
  • Easier localization through Translate extension
• Volunteer @ frwiki.
  • Some scripts are maintenace nightmers.
  • We have a low bus factor
  • Wants more modularity & decoupling, slicing up monoliths
• Issues without connection to roles/background:
  • Some gadgets have different names on each wiki, also those gadgets can be slightly different. If you have gadget-specific config, it will be different on each wiki.
  • No way to know which gadgets will potentially break unless you check them individually.
• Volunteer bots/scripts/gadgets/tools dev frwiki/wikidata
  • wants to reduce bus factor
• Arkanosis
  • A lack of relevant metrics about who uses what and what depends on what
• Cormac
  • wmf staff memeber
  • never wrote a gadget
  • have broken gadgets/userscripts by accident
• I am a frontend dev and don't want to bfreak tooling. We make changes, eg, to the DOM without a complete understanding of the impact.
  • Because of poor visibility and understanding fear of breaking tooling clouds discussions & slows development
• Tacsipacsi - ticket input
  • The inability to deploy gadgets and other JS/CSS files stored in MW namespace to certain pages.
  • Templatestyles is a big step forward but it has some restrictions
  • some things require JS to work
  • Some pages need CSS that applies outside conten area 
• PerfektesChaos
  • Volunteer dev on dewiki
  • wants focused communication on things that affect script authors
• Pablo
  • software (extension) developer
  • People ask me "not to break their gadgets by changing my software because they rely on my mark-up not to change
• Joaquin
  • Professional developer developing wikimedia software and writing technical documentation
  • I have written a few prototype gadgets for testing UIs, and have some small scripts for changing the appearance of the page.
  • Gadgets touching HTM makes changing the underlying UI/HTML in MW error prone.
  • I missed standard APIs for modifying the UIs from scripts/gadgets
  • finding gadgets is hard
• TheDJ
  • I am a volunteer developer of userscripts/gadgets/MediaWiki:Common.js
  • sharing code, (dependency management and conventions)
  • who uses what (like which code is actually being run)
  • lack of api for extending / stable interaction
  • unit testing
• Matej_suchanek
  • Volunteer dev on cswiki
  • Gadgets 2.0/ Gadget manager
  • has localization concerns

Gadget/User scripts - ideas for improvements,as presented as outcome
(transcription from sticky notes)

• Group 1
  • 1. Stable APIs for "common" user cases (rather then relying on DOM)
  • 2. Activity of deprecation/error hit, making it visible to other users/developers
  • 3. Show dependency graph for gadget loading other gadgets
  • Expand MW:Commons.js checks in Jenkins to somehow notify someone (tm)  -- https://integration.wikimedia.org/ci/job/audit-resources/ -> "Expand all" T71519
  • error handler -> grafana and then use internal/restricted tooling to retrieve stracktrace. Also for admin/sysop
  • Index HTML/CSS classes/IDs and warn in changesets in Gerrit how many scripts might be affected by your DOM/code change
  • Development guidelines for gadgets/user JS
  • i18n best practices for script authors
  • /i18n/lc.json convention to load translations. See also: /doc
  • Expand MW:Common.js checks in Jenkins to also check gadgets -- https://integration.wikimedia.org/ci/job/audit-resources -> "Expand all" T71519
• Group 2
  • 1. Create a Gadget API that is standardized and limits the scope of what gadgets can do so things use best practices
  • 2. Host gadget/script code in version control repo like Github. That solves:
    • no code review
    • no CI
    • Gives authors visibility as open source contributors
    • Gadget creators getting locked out of MediaWiki namespace acces
    • no IDE
    • No explicit software licenses
  • 3. Having two "pipes" of changes.
    • First one is the way how wiki gets WMF staff changes.
    • Second pipe would be all gadgets, common scripts, user scripts, wiki scripts, Central auth?
    • There should some extensions that controls the second pipe
• Group 3
  • 1. Maintain on git deploy as extension -> wikimedia-gadgets
  • 2. Thinking about gadget ownership/maintenance responsbility
  • 3. Disallow use of someone else's user sscript
  • Process for deprecating old/unused gadgets
  • One-in, one-out policy for gadgets
  • Catalog gadgets/scripts with description & tags so people can find them
  • Force people to use browser extensions instead of gadgets
  • Integration with translatewiki.net
  • Local JSON pages behind ResourceLoader
  • Gadget opt-in expires/prompts to re-new
  • "Gadgets 3.0"
• Group 4
  • 1: Integration with gerrit/github to reuse existing tools rather thabn reinventing in wiki
  • JSFiddle like gadget editing tools. on-wiki + sandbox sample page to test gadget
  • 2: Easier way to know as an editor - or a reader ! - what gadgets user scripts are loaded
  • Organize phabricator tags for gadgets to make it really easy to create for each gadget to file bug reports
  • explicit maintainers for individual gadgets in structure data. similiar to gerrit +2 groups per repo ?
  • 3. Clear path for promotion from gadget to extension

<!-- -->

• -

Templates/Modules - First part of the session - Group 1 notes

•  <Will has photographs of the areas raised and the top 3 selected topics>
• Who / Problem statements pairs
  • RheingoldRiver
    • Lead admin of a wiki League of Legends esports; lot of work w/lua and cargo
    • Issues:
      • Would like a standard class system as part of scribunto, mw.class alongside mw.html, etc
    • Issues on extra notes:
      • (Improving) Standard library for modules
      • There should be global templates and modules
  • Tascipacsi
    • Volunteer developer working with templates/modules and multilingual projects
    • Also developing gadgets and scripts for Hungarian projects
    • Issues:
      • Insufficient tools to find out where globally loaded things are actually used. For example, I want to remove a CSS rule, I want a way to know if it is in use elsewhere
  • Tobi
    • WMDE developer
    • Issues:
      • Docentation is hard or non-existing
    • Issues on extra notes: 
      • Add support for comments in template syntax
  • Elena
    • QA
    • Issues:
      • No quality assurance/testing involved in template development
      • Lua
    • Issues on notes:
      • Limited template matching in ContentTranslation
      • There should be a built in testing system for templates and modules and a nice UI to add new tests and update them
  • Gergo
    • Mediawiki developer and template editor
    • Issues:
      • Styling of templates is very difficult
    • Issues on extra notes:
      • No javascript possible to use templates
      • Extracting data from templates out of extensions is very difficult
      • Lua method for pushing data to some structured channel
      • Templates/modules in git w/ preview on wiki
      • Modules: No ide support and no real development work flow
  • Thomas
    • Mediawiki template editor + extension developer
    • Issues:
      • Now easy translation for templates/modules
    • Issues on notes:
      • Standard way of translating parameters and contents
  • Niklas
    • Language team at WMF
    • Issues:
      • No readable template syntax
      • Difficult to format template code
  • Christoph (FIsch)
    • WMDE developer(no editor but know how to write templates)
    • Notes:
      • Importing pages with many templates and modules is annoying
    • Issues on extra notes:
      • A lof of duplication of templates + modules as exixsting ones are hard to find
      • Having templates imported and working in beta cluster. Then it'd be easier to test, debug or just to see what's happening with templates
      • Easy way to import/export articles with all module/template dependencies
      • WYSIWYG for using modules and templates
  • Arkanosis
    • A volunteer scripts, gadgets, bots and tools developer. Have working on this since 2009, generally happy
    • Issues:
      • The inability to effectively share and localize code across wikis
      • Lack of proper maintainership
  • matej_suchaner
    • Volunteer dev cswiki
    • Issues:
      • Central global reposoitory for templates, lua modules, gadgets( T121470)
  • Giuseppe
    • As an SRE I am worried about:
    • Issues:
      • widely used templates
      • no instrumentation for template writers
      • no staging area
      • no code review system
      • more than look wiki pages
    • Issues on extra notes
      • It is difficult to quickly determine a full list of dependencies between templates and the impact of changing a given template
  • Unattributed Notes:
    • Global Templates, no way of sharing templates and modules, there should be global templates
    • Sharing templates and modules across multiple wikis is problematic
    • Multiwiki synchronisation
      • What are the semantics of templates in different languages
      • How do the template in different languages link to each other
      • Third party multi-wiki admin, sysadmin, user, etc
        • Templates used in multiple wikis (like template:infobox or template:person) are hard to keep in sync across multiple wikis
        • Need a sync/share tool for templates across wikis still allowing customisation
    • New wiki is created
      • You can use math, egyptian hieroglyphs and musical score with zero steps but you can not use infoboxes and citations without importing a lot of templates
    • It would be good to have more module tools
      • Global search and replace
      • Grouping modules into packages
      • Templates/modules should be easily translatable just like MW
    • When a new wiki starts it is totatlly blank; not even basic modules or templates or even a way to show coordinates
    • I have developed automiatic templates from wikidata based on catalan WP module: wikidata. Having to copy everything is hard and not easily trackable
    • As a developer I cannot test how new features work with existing templates
    • Make template data mandatory to improve documentation
      • Templating is not very intuitive to new users
    • Templates mix content and presentation and metadata all together in wikitext
      • When you copy a module from another project, you have to figure if the dependencies are also the same. Modules are not maintained across wikis
      • Nesting templates is powerful but quickly becomes a problem and adds complexity for understanding and maintenance
    • For beginners sometimes the documentation for templates isn't very clear. As a module app developer I use templates just once in a while and it's difficult to understand where to get started
      • Lua knowledge is really limited. Wikicode can be easier, but is not universal or simple for small communities
    • Template inclusion
      • Weird templates are required to render a set of wiki pages?
      • Weird version of the template was used at a particular point in time?
    • Lua is not the most programmer-friendly language
    • Lua IDE?
      • Editing lua code in the browser is a pain, especially if multiple dependant modules are involved
      • Interaction of modules and parser
        • Some lua modules create problems for rendering
        • It would be good to model the interactions
    • Limitations of template transclusion can be difficult to optimize (to not breach the limits and to improve pageload times)
    • A lot of templates are not mobile-friendly

 Templates/Modules condensed and merged outcomes of the two groups

• 1) A consumer hub for templates/modules
  • Show versions locally and pull updates
  • Documentation/Transactions
  • Allow rollback?
  • Reviews? Ratings? Feedback?
• 2) A central developer hub to create packages of templates and modules that support peer/code review and versioning and allows synchronisation to wikis. Possibly replicated, overwritable, cascaded
• 3) A way to visualise templates dependencies and modules and instrumentation
• Additional ideas voted for that did not make it into the condensed ones
  • Make tempalte data mandatory to improve documentation

• Gadgets/scripts
  • - Creating some kind of gadget API - make it easier for gadgets not to rely on DOM
    • Make use of version control systems to store gadget code - to enable using existing code tooling - avoid reinventing things on wiki, for code review, CI, testing, etc.  Visibility in the open source community, use of IDEs, etc. Software-licensing.
    • Invest more in maintenance and ownership of gadgets and userscripts - make it easier to determine who owns stuff, define responsibilities for maintainers/owners of gadgets, etc.

• - Deep Dive - on 6 topics from earlier breakout groups
  • Impact?
  • Ideas for concrete steps to get there?
  • Who should be involved?
  • What resources would be needed (rough estimate - people needed, size of project, amount of time)?

Documentation of discussions in the 3 subgroups for gadgets/userscripts
(part II of the session)

Questions: 

• Impact? 
• Ideas for concrete steps to get there? 
• Who should be involved? 
• What resources would be needed (rough estimate)?

Gadget APIs breakout group

• Idea is that we don't know what gadgets are going to do
• Stuff is happening with frontend
• We're going to have to limit what gadgets can do, but also help them to do things correctly
• This brings us to an API
• Instead of telling a gadget owner to manipulate DOM, we give them a way to say how to manipulate the output the way you need, here's the defined API you use
• Directly manipulating the DOM is going to be hard
• PM: You can still use jQuery, but we don't support that.
• JF: We don't support any gadgets currently in an official sense
• MS: Practically speaking, we have to deal with it when we break things
• MS: WordPress as an example:  Ways to add things - "put a box here", "here's a hook that gives you the data that you are allowed to manipulate".
• What if you break the DOM?
• ...
• Hook system in JS is notify-only - could change that into a system that ???
• PM: Right now, it's hard to know what gadgets can do.
• Would need to figure out what use cases would satisfy the most gadgets
• This is going to have to be very opinionated
• There's going to be a limit to what we can allow
• It's understood this is meant to be a playground, but the things that are going to be common should have a mechanism for implementation
• Cross reference to the idea of source code control and using standard tools for things like CI
• Nutshell:  identify common needs, add to our existing JavaScript API
• We're going to radically change things with the desktop refresh - this is an opportunity to solve some existing problems
• A concern:  Will we be dogfooding this?
• It's hard
• Impact:
  • For better or worse, there will a lot
  • Will need to have a process of discovering common use cases as time goes on
  • We might get a test entrypoint out of the deal
• Concrete steps
  • Identify use cases from popular gadgets, sort out the good bad and ugly
  • Analyze how things work in other systems (WordPress, Joomla, etc.)
  • Define expectations for API deprecation policy
• Who
  • Lots of people
  • Working group?  Half a year?
• What resources
  • ???

Gadget API breakout group

• - IMPACT:
  • • Differentiate between supported/not supported gadgets -> that'd be clear to the community
    • More control (over supported gadgets)
    • We will be more clear on what to expect from gadgets or what gadgets will do
    • Gadgets will support (all skins)
    • Unit integration testing will be possible and it will be easy o/
  • Next steps:
    • 1: Identify current uses / what are gadgets doing
    • 2: a nalyse those and identify:
      • useful
      • good / bad
      • wished for/ ..
    • 3: Check best practices. eg. Wordpress & Co (Drupal, joomla), how they deal with such an issue eg. skins

Gadget/Userscript Tooling breakout group

• line by line code review would be interesting problem to solve. 
• git upstream has *mw-to-git* - could be adapted to target wikis. Bi-directional exists. https://github.com/git/git/tree/master/contrib/mw-to-git 
  • ACTION: Just needs onwiki documentation, and minor adaptation?
  • Do we need an extension to do it for gadget namespace?
  • if you're looking at version history onwiki, what shows up?
    • username
• Concern: problem of people being locked out of maintaining their gadget, because of being locked out of mediawiki namespace.
• how does authorization work with git?
• How do we solve the problem that led to Interface Admins being created.
  • limited via gerrit/github - different people can edit 
• if you're the author of a gadget, would we want it to be bidrectional?  choose to only accept code from repo, or also accept from 
• Are there enough contributors at all to require a +2 system?
• Pull-requests and comments are useful regardless
• Is this basically Release Engineering for gadgets?
• Testing?  
  • have a sandbox in a page, of everything that a gadget would interact with, to test on. e.g. https://www.mediawiki.org/wiki/Help:Sample_page 
  • Simple? Probably not. Too many gadgets are so contextual that 
• Completion missing. Need to go to docs to find anything. Can we add Typing/autocomplete?  Codepen style.
• Could have a 2nd build of the api, add a preference that gives it inline. _doc.
• ideally you could go into mw.hook - and find out "what does this do?" etc
• - 2 paths:
  • - improve the onwiki dev experience
    • migrate into a version control system
  • Questions
    • Grant: Is there any browser extension that can do versioning from the browser. Looker VI tool, VI does this for designs.
    • Grant: How do you do it in ngen (?) ?  
    • Need to avoid requiring someone to have a GitHub account.
    • IDEA: Require global gadgets to be in version system?
    • IDEA: Require anything with dependencies to be in version system?
    • making gadgets multifile content rather than a single file, that way they match better to what a repo is.
    • give option of multiple backends? github, gitlab, bitbucket, gerrit.
      • Could be agnostic - have a button onwiki to "Remote publish from whatever"
        • Cannot grant autosync though -- "As a gadget author, I submit great looking gadget, it gets approved for autosync, then i add nefarious code"
      • This would actually be a cleaner workflow than is currently available for non-interface admins (IAs), who have to request IAs to edit the page for them.
      • What would octopus merges look like onwiki?

• - Userscripts:
  • • Promote some to gadgets for this nicer workflow
      • ACTION: Criteria need to be developed
      • ACTION: Docs need to be written
      • We can help people transition
    • WANT: UI for subscribing to userscripts
      • Gives metrics and dependencies

• STEPS: 
  • Deploy something as an experiment? Might only take a few hours for a basic test.
  • Support multiple options - github/gitlab/gerrit
  • Make a gadget, as prototype for extension
  • Need an API for 
• PEOPLE: 
  • Who could help build the bidirectional system
  • Releng?
  • Interface admins
• RESOURCES:
  • Unknown

Gadget maintenance/ownership group (Bryan D, Sam R, Daniel Z, Timo,
Andre, Niharika, Greg)

• Andre: if some gadget authors decide Phabricator is they want to use, but it should not be decision that is imposed on gadget authors from "above"
  • People should not be reporting things that no one will ever look at - This though is not different that gadget talk pages
• Andre: using tag for gadget is problematic as the "same" gadget could still vary between different wikis, so one tag would be referring to different software
• Andre: tracking gadgets on phabricator does not make sense to me as long as theree is no central repository of gadgets
• Bryan: There are two worlds here: one we (MW devs) live in, with Phabricator used as a tracking system, and the other which happens on wiki. Would there be any value in having a unified universe (e.g. opening a phabricator ticket from wiki?)
• Timo: due to specific nature of gadgets it seems more important for the user to find a developer, I think what is essential here is the discoverability of gadgets
• Sam: it could be made part of the gadget definition is that the gadget developer defines how to contact them, where to report the bug (whether it is talk page, wiki page, phabricator would be completely up to them)
• Bryan: We could borrow the concept  of JSON schema for tools, being created for the Toolhub, and use similar structure for gadget definition
• Timo: There is already code (not enabled/merged?) that introduces gadget definition (as a namespace)
• Do we want to have a list of options ppeople can use to pick on where to report those issue, or do we want to allow it to be completely free-form?
  • Might make sense to start with freeform
• Timo: Gadgets 2.0 also changes the gadget page more visual
• DanielZ: on the bottom of the page it could be shown what gadgets are loaded
  • Do we really want to show it to users some details related to the default gadgets
• Bryan: there is this split between us who care about the code quality etc, and others who focus on different things (i..e are not interested in the "how" it works, what is loaded, etc)
• Bryan: there is also people who triage problems and report them on wikis, than in other tech spaces (pharbicator)
• Idea picked up for further consideration:Have hadget have some metadata manifest specifying: original authors, active maintainers, where to report bugs, license)
  • That would be added to the Gadgets extension
  • Impact: other tools could be built to improve discoverability, maintainership would be improved (who do I contact to get things fixed), the licensing topic would also be better surfaced
  • Andre: how would I see it on Special:Gadgets?
    • That seems to be implementation detail. One we have the metadata, there would be variety of ways how to display what to display
  • Timo: Gadgets 2.0 have a lot of things already that would help with
  • Bryan: what do we need to have Gadgets 2.0 to POC state that could deployed
    • Timo: there was a lot concerns about how to roll it out, most of the controversial bits were removed. There is completely automated scripts for converting existing gadgets.
    • Community Liaisons/Product Managers would also needed to help with communication to the communities, help prioritizing regressions, etc. 
  • Timo: There is no much of consensus needed. What is needed is two engineers for certain amount of time (2 quarters). Design help would be also valuable.
  • greg: that would be infrastructure part, what could follow is gamification aspects, e.g. define levels of gadgets (golden gadget = has X active maintainers, silver = ...)
  • DanielZ: for existing gadgets we would need to find current maintainers, so that they define the metadata parts like how to contact them, how to report bugs
  • Timo: I would prefer Processes over People for things that are community related 
• Side note: Gadgets 3.0 = have per-user gadget repositories, which would provide better way for users to pick other user's scripts they could enabled for themselves
  • Not certain if this concept is going to be needed
• Task for the documentation sprint: Group members review notes and polish them up in places the scribe got the details wrong etc
  • [Speaking as a scribe, the scribe definitely got some details wrong. -- BPB]

PRESENTATION
Questions: 

• Impact? 
• Ideas for concrete steps to get there? 
• Who should be involved? 
• What resources would be needed (rough estimate)?

• Publishing gadgets:
  • Workflow:
    • publish on gitlab etc
    • CI
    • publish when ready
    • Interface admin publishes
  • There's a git-remote thing that exists, calls API. Could be a gadget?
  • Userscript registry idea - some method of subscribing.
    • Gives structure, and metrics, dependencies
    • Find who's using what

• APIs for common use cases of gadgets
  • Differentiate supported / unsupported gadgets
  • Be clear on what to expect from gadgets, what they can do with pages they interact with
  • Gadgets could support all skins
  • Possibility of unit testing / CI for gadgets
  • All the things gadgets do
    • Analyse these and ensure sensible
      • What is good, bad, wished for, unhelpful
      • What are the best practices elsewhere for skins (wordpress, joomla etc)
• General problem of how to report bugs, who maintains gadgets, how to find them
  • Initial path, rigid phab hierarchy tracking in detail everything
    • Andre highlighted issues with this appraoch
  • Richer metadata to go with gadget description
    • where do I file a bug report, where do I find the help page
    • Original author
    • Active maintainers
    • Source code license
  • Timo input on Gadgets 2.0 extension
    • Undeployed but appears to be an already worked on area
    • 2 engineers for 2 quarters, with support from community liaison , with PM
      • Could move Gadgets 2.0 forward to an initial launch

• Templates/Modules
  • Fisch: A way to visual template dependencies
    • Currently hard to maintain templates/modules because you don't know where they're used.
      • Changes are hard, hard to inform people what you're doing because you don't know the people using them
    • Support people in making these things maintainable should lead to less duplication as templates are findable
    • Steps:
      • MVP
        • Get the data on where they're used. It exists, just needs to be compiled and visualized.
          • Some of this may not be right away available as it depends on process executing
        • Generate a graph out of the data to visualize usages of modules/templates
      • Bonus
        • Figure out a way to gather the same data on parameters used or not used
        • Demonstrate what parameters are used
    • Who?
      • CPT
      • Performance
      • DBA
      • Template authors/users
    • Resources
      • PM
      • 2-3 devs
      • UX for visualization
      • Community Person
    • Timeframe
      • Over 1 year
        • But not necessarily solidly
        • Overall a quarter spread over a year

transcription of stickies: (F31064506)

• Amir: A central consumer hub to create packages of templates and modules that support peer/code review and versioning and allows synchronisation to wikis. Possibly replicated, overwritable, cascaded

<!-- -->

• - Bundle: templates, modules, translations, documentation, feedback, export/import
  • Impact: Translations, Declared dependencies, Bundle
  • Concrete steps:
    • Way to define bundle
    • Hub to discover bundles. Special:Bundles
    • Better name than "Bundle"
    • Predefined export list
  • Resources
    • designer
    • Product manager
    • 2 engineers
    • 6 months
    • some volunteers
  • Who: Anyone. You !!

• Amir: Make templates global
  • Need to understand impact and steps
  • Impact
    • Templates have to be transfered that's challenging but possible
    • Good propagation of contents across wikis
    • Good propagation of technical innovation across communities
    • Easy access to a lot of features to small communities
    • The community wants it
  • Steps
    • Balanced templates make cahcing easier
    • Dependency tracking across wikis
    • Move some very internal modules like "no globals" into scribunto
    • Make documentation for module development practice that works without causing bad performance problems
    • Similar to what the parsing team did for the migration from Tidy to Remex - tools, special pages...
    • Create a across wiki group of templates maintainers and coordintors
    • Consider Performance and Caching
      • CPT suggests: Framework to ensure performance of templates
    • Making parsing and balancing measured, to improve [???]
    • consider internationalization
      • messages
      • parameters
      • titles
      • parameter documentation
  • Resources:
    • Not specified

Unstructured documentation from the session (probably from 1 sub
group):

• Volunteer bots/scripts/gadgets/tools dev on frwiki/wikidata - Wants to reduce bus factor
• Volunteer on dewiki - Wants focused communication on things that affect script authors
• Lack of relevant metrics about who uses what and what depends on what
• Extension dev - people ask me "not to break their gadgets" by changing my software because they rely on my markup not to change
• WMF staff member - never wrote a gadget, have broken gadgets/userscripts by accident
• Wikimedia dev and writer of technical documentation - have written a few prototype gadgets for testing UIs and have some small scripts for changing the appearance of a page
  • Gadgets touching HTML makes changing the underlying UI/HTML in MW error prone.  Missed standard APIs for modeling the UIs from scripts/gadgets.  Finding gadgets is hard.
• Frontend dev - don't want to break tooling.  We make changes, e.g., to the DOM without a complete understanding of the impact.  Because of poor visibility and understanding, fear of breaking tooling clouds discussions and slows dev.
• Volunteer dev of userscripts/gadgets/??? - problems include sharing code, who uses what (execution), lack of API for extending/stable interaction, unit testing
• Inability to deploy gadgets and other JS/CSS files stored in MW namespace to certain pages
• Template styles is a big step forward but it has some restrictions, some things require JS to work, some pages need CSS that applies outside content area
• QUESTION: Does global mean "global" like GlobalCommons?
• TheDJ: stacktrace is often missing

Gadget/Script -- ideas for improvements (unstructured notes of
discussion in one subgroup)

• Daniel: maintain on git, deploy as extension -> wikimedia-gadgets
• Andre: Jenkins has a system that finds errors [?] but currently not easily findable or notifying anyone.
• Stephen: in MF, eventlogging sends notices. 
• Dependency graphs
• user metrics
• localization improvements - i18n best practices, and json convention to load translations
• code review systems
• automated testing systems
• errors shown live to admins. (used on Commons)
  • errors logged somewhere centrally where non-users can see it
• Deprecation/Change news in a high-signal communication channel
• global code repos for de-fragmentation
• upstream awareness of what/how tools are used.

First mayor re-structuring of the live notes and transcribed post-its. Could probably still use some improvements at the end:

Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
Developer Productivity and onwiki tooling
Session Leader: Bmueller, WMDE-leszek, Amire80, Tgr

https://phabricator.wikimedia.org/T234661

Session Attendees (rough estimate: about 45 people)
Alexandros Kosiaris, James Forrester, Jeena Huneidi, Moriel
Schottlender, Timo Tijhof, Piotr Miazga, Ryan Kaldari, Stephen
Niedzielski, Cormac Parle, Tyler Cipriani, Greg Grossmeier, Daniel Zahn,
Bryan Davis, [+ cpl dozen more]

Tasks for Documentation Sprint

• DONE: Transcribe post-its with who am I / what is my issue
• DONE: Transcribe post-its with ideas for solutions

Notes:

• https://docs.google.com/presentation/d/10ls0ZH29e173YB1KtesPYshfdheTf-i7qlPYL2wh9G4/edit?usp=sharing
• Programming notes: 2 breakout rooms. Gadgets/scripts and templates/modules.
• Issues transcribed from Phabricator have been distributed to discussion subgroups for discussion/triage.
• Unnessecarily complicated gears
• Tools will not be discussed in this session
• Goals: Shared understanding on key issues, prioritized list for improvements including impact/cost estimate.
• Recurring themes in gadgets/scripts small-group discussion:
  • Code management and hosting, automation of code publication from external repositories (Gerrit, GitHub)
  • Code review
  • Dependency management
  • Testability
  • User-metrics - Who uses what?
  • Communication - How are users/developers informed of changes?

Breakout session notes - users and problem statements (part I)

Gadget/Script -- Who / Problem statements ( all groups ) (transcription of post-its)

• Group 1
  • Volunteer developer, Wikimedian, Wikipedian for many years, also WMF staff. Has worked on various gadgets, scripts, userscripts, templates, modules for many reasons, copy pasted and reused in many cases.
  • Volunteer. Used Hotcat on en.wiktionary to categorize about 20K uncategorized pages. Would not have been possible without HotCat. We should try to stop using so many duplicate code lines. It would require turning userscripts into gadgets.
  • WMF staff member, Analytics. Not affected at all by gadgets. Has experience analyzing and categorizing content en masse.
  • Engineering Manager, WMF. Understanding of gadgets/userscripts rather limited. INterested in how both of these things could be encorporated with what is considered software development best practice - i.e. CI release/integration testing, versioning, branching.
  • Engineering Manager, WMF.
    • Issues: Deploying gadgets requires special rights
    • No "Sandbox" for creating a gadget before deploy
    • No code review, line based feedback mechanism
    • cross wiki sync missing
    • translation of gadgets is not easy
    • configuration of gadgets is difficult
  • volunteer developer of scripts, gadgets, bots and tools developer at frwiki and wikidata, and I do some occasional training for Scribunto beginners, even though I'm not very active in modules development. (from phab ticket)
    • Generally happy, things that could be better: Lack of attention from upstream to the tools that people actully use; lack of propper maintainership. More integration with existing tools so that developers can use their development systems of choice.
  • Volunteer developer who has created several gadgets on EnWP. Due to increasing restrictions on access to the MediaWiki namespace, I can no longer maintain my gadgets or respond to bugs.
  • WMF, Director of Engineering. As a user of gadgets I have a hard time knowing where to go to slove my needs. I usually just discover things from coworkers, namely James F. But not everyone has a James F ... .
  • As a person who is going to work on a Desktop Refresh project I have no idea what are "possible UI differences" caused by gadgets
  • As a WMF developer I have no idea what "lives" on each wiki. Sometimes our change doesn't work on some wikis and we have no idea why.
  • The quality of user gadgets/scripts is usually pretty low. No tests/bad performance. Flagged Revs could help?
  • Moriel
    • I'm WMF staff, developing extensions and gadgets
    • I help develop and fix gadgets on-wiki with primarily OOUI
    • Issues:
      • OOUI is not as easy to use in on-wiki gadgets (requires extending classes, instantiating multiple tools before they can start actually building)
      • No code review!!
        • bad practices all around, affect other code, hard to fix.
      • No good way to contribute
        • no convention on storing code in github for allowing contributions
      • Extensions - no repo to know what exists
      • MWStew <3 MWCLI <3
  • Volunteer dev cswiki
    • Unix-like diffs for Lua/JS (using wikitext diffs is strange)
    • matej_suchanek
  • I am Niharika. I work as a Product Manager on the Anti-Harassment Team
    • My issue is that my team's projects can end up breaking gadgets across projects. It is hard to know [when this has happened]{.underline} and [who is responsbile]{.underline} for resolving this problem.
  • James
    • All gadgets and site scripts are terrible
  • Timo
    • Developing gadgets since 2010
    • rewrote the gadget system in 2013 (resourceloader)
    • Issues:
      • slow-down: duplication
      • completeness: localisation
  • Daniel: WMF/CPT
    • Gadgets break when we change skins or JS code. Need stable interfaces
  • MusikAnimal. Gadget developer and problem maker
    • My gadget is on ~12 wikis, all different versions
    • Hard to localize
    • JSON behind ResourceLoader
    • Easier localization through Translate extension
  • Volunteer @ frwiki.
    • Some scripts are maintenace nightmers.
    • We have a low bus factor
    • Wants more modularity & decoupling, slicing up monoliths
  • Issues without connection to roles/background:
    • Some gadgets have different names on each wiki, also those gadgets can be slightly different. If you have gadget-specific config, it will be different on each wiki.
    • No way to know which gadgets will potentially break unless you check them individually.
  • Volunteer bots/scripts/gadgets/tools dev frwiki/wikidata
    • wants to reduce bus factor
  • Arkanosis
    • A lack of relevant metrics about who uses what and what depends on what
  • Cormac
    • wmf staff memeber
    • never wrote a gadget
    • have broken gadgets/userscripts by accident
  • I am a frontend dev and don't want to bfreak tooling. We make changes, eg, to the DOM without a complete understanding of the impact.
    • Because of poor visibility and understanding fear of breaking tooling clouds discussions & slows development
  • Tacsipacsi - ticket input
    • The inability to deploy gadgets and other JS/CSS files stored in MW namespace to certain pages.
    • Templatestyles is a big step forward but it has some restrictions
    • some things require JS to work
    • Some pages need CSS that applies outside conten area
  • PerfektesChaos
    • Volunteer dev on dewiki
    • wants focused communication on things that affect script authors
  • Pablo
    • software (extension) developer
    • People ask me "not to break their gadgets by changing my software because they rely on my mark-up not to change
  • Joaquin
    • Professional developer developing wikimedia software and writing technical documentation
    • I have written a few prototype gadgets for testing UIs, and have some small scripts for changing the appearance of the page.
    • Gadgets touching HTM makes changing the underlying UI/HTML in MW error prone.
    • I missed standard APIs for modifying the UIs from scripts/gadgets
    • finding gadgets is hard
  • TheDJ
    • I am a volunteer developer of userscripts/gadgets/MediaWiki:Common.js
    • sharing code, (dependency management and conventions)
    • who uses what (like which code is actually being run)
    • lack of api for extending / stable interaction
    • unit testing
  • Matej_suchanek
    • Volunteer dev on cswiki
    • Gadgets 2.0/ Gadget manager
    • has localization concerns

• Group 2
  • Volunteer bots/scripts/gadgets/tools dev on frwiki/wikidata - Wants to reduce bus factor
  • Volunteer on dewiki - Wants focused communication on things that affect script authors
  • Lack of relevant metrics about who uses what and what depends on what
  • Extension dev - people ask me "not to break their gadgets" by changing my software because they rely on my markup not to change
  • WMF staff member - never wrote a gadget, have broken gadgets/userscripts by accident
  • Wikimedia dev and writer of technical documentation - have written a few prototype gadgets for testing UIs and have some small scripts for changing the appearance of a page
    • Gadgets touching HTML makes changing the underlying UI/HTML in MW error prone. Missed standard APIs for modeling the UIs from scripts/gadgets. Finding gadgets is hard.
  • Frontend dev - don't want to break tooling. We make changes, e.g., to the DOM without a complete understanding of the impact. Because of poor visibility and understanding, fear of breaking tooling clouds discussions and slows dev.
  • Volunteer dev of userscripts/gadgets/??? - problems include sharing code, who uses what (execution), lack of API for extending/stable interaction, unit testing
  • Inability to deploy gadgets and other JS/CSS files stored in MW namespace to certain pages
  • Template styles is a big step forward but it has some restrictions, some things require JS to work, some pages need CSS that applies outside content area
  • QUESTION: Does global mean "global" like GlobalCommons?
  • TheDJ: stacktrace is often missing

Gadget/User scripts - ideas for improvements (group by group) (transcription of post-its)

• Group 1
  • 1. (voted for) Stable APIs for "common" user cases (rather then relying on DOM)
  • 2. (voted for) Activity of deprecation/error hit, making it visible to other users/developers
  • 3. (voted for) Show dependency graph for gadget loading other gadgets
  • Expand MW:Commons.js checks in Jenkins to somehow notify someone (tm) -- https://integration.wikimedia.org/ci/job/audit-resources/- "Expand all" T71519
  • error handler -grafana and then use internal/restricted tooling to retrieve stracktrace. Also for admin/sysop
  • Index HTML/CSS classes/IDs and warn in changesets in Gerrit how many scripts might be affected by your DOM/code change
  • Development guidelines for gadgets/user JS
  • i18n best practices for script authors
  • /i18n/lc.json convention to load translations. See also: /doc
  • Expand MW:Common.js checks in Jenkins to also check gadgets -- https://integration.wikimedia.org/ci/job/audit-resources- "Expand all" T71519
• Group 2
  • 1. (voted for) Create a Gadget API that is standardized and limits the scope of what gadgets can do so things use best practices
  • 2. (voted for) Host gadget/script code in version control repo like Github. That solves:
    • no code review
    • no CI
    • Gives authors visibility as open source contributors
    • Gadget creators getting locked out of MediaWiki namespace acces
    • no IDE
    • No explicit software licenses
  • 3. (voted for) Having two "pipes" of changes.
    • First one is the way how wiki gets WMF staff changes.
    • Second pipe would be all gadgets, common scripts, user scripts, wiki scripts, Central auth?
    • There should some extensions that controls the second pipe
• Group 3
  • 1. (voted for) Maintain on git deploy as extension -wikimedia-gadgets
  • 2. (voted for) Thinking about gadget ownership/maintenance responsbility
  • 3. (voted for) Disallow use of someone else's user sscript
  • Process for deprecating old/unused gadgets
  • One-in, one-out policy for gadgets
  • Catalog gadgets/scripts with description & tags so people can find them
  • Force people to use browser extensions instead of gadgets
  • Integration with translatewiki.net
  • Local JSON pages behind ResourceLoader
  • Gadget opt-in expires/prompts to re-new
  • "Gadgets 3.0"
• Group 4
  • 1. (voted for) Integration with gerrit/github to reuse existing tools rather thabn reinventing in wiki
  • 2. (voted for) Easier way to know as an editor - or a reader ! - what
  • 3. (voted for) Clear path for promotion from gadget to extension
  • JSFiddle like gadget editing tools. on-wiki + sandbox sample page to test gadget gadgets user scripts are loaded
  • Organize phabricator tags for gadgets to make it really easy to create for each gadget to file bug reports
  • explicit maintainers for individual gadgets in structure data. similiar to gerrit +2 groups per repo ?

Templates/Modules -- Who / Problem statements ( all groups ) (transcription of post-its)

• Who / Problem statements pairs
  • RheingoldRiver
    • Lead admin of a wiki League of Legends esports; lot of work w/lua and cargo
    • Issues:
      • Would like a standard class system as part of scribunto, mw.class alongside mw.html, etc
    • Issues on extra notes:
      • (Improving) Standard library for modules
      • There should be global templates and modules
  • Tascipacsi
    • Volunteer developer working with templates/modules and multilingual projects
    • Also developing gadgets and scripts for Hungarian projects
    • Issues:
      • Insufficient tools to find out where globally loaded things are actually used. For example, I want to remove a CSS rule, I want a way to know if it is in use elsewhere
  • Tobi
    • WMDE developer
    • Issues:
      • Docentation is hard or non-existing
    • Issues on extra notes:
      • Add support for comments in template syntax
  • Elena
    • QA
    • Issues:
      • No quality assurance/testing involved in template development
      • Lua
    • Issues on notes:
      • Limited template matching in ContentTranslation
      • There should be a built in testing system for templates and modules and a nice UI to add new tests and update them
  • Gergo
    • Mediawiki developer and template editor
    • Issues:
      • Styling of templates is very difficult
    • Issues on extra notes:
      • No javascript possible to use templates
      • Extracting data from templates out of extensions is very difficult
      • Lua method for pushing data to some structured channel
      • Templates/modules in git w/ preview on wiki
      • Modules: No ide support and no real development work flow
  • Thomas
    • Mediawiki template editor + extension developer
    • Issues:
      • Now easy translation for templates/modules
    • Issues on notes:
      • Standard way of translating parameters and contents
  • Niklas
    • Language team at WMF
    • Issues:
      • No readable template syntax
      • Difficult to format template code
  • Christoph (FIsch)
    • WMDE developer(no editor but know how to write templates)
    • Notes:
      • Importing pages with many templates and modules is annoying
    • Issues on extra notes:
      • A lof of duplication of templates + modules as exixsting ones are hard to find
      • Having templates imported and working in beta cluster. Then it'd be easier to test, debug or just to see what's happening with templates
      • Easy way to import/export articles with all module/template dependencies
      • WYSIWYG for using modules and templates
  • Arkanosis
    • A volunteer scripts, gadgets, bots and tools developer. Have working on this since 2009, generally happy
    • Issues:
      • The inability to effectively share and localize code across wikis
      • Lack of proper maintainership
  • matej_suchaner
    • Volunteer dev cswiki
    • Issues:
      • Central global reposoitory for templates, lua modules, gadgets( T121470)
  • Giuseppe
    • As an SRE I am worried about:
    • Issues:
      • widely used templates
      • no instrumentation for template writers
      • no staging area
      • no code review system
      • more than look wiki pages
    • Issues on extra notes
      • It is difficult to quickly determine a full list of dependencies between templates and the impact of changing a given template
  • Unassociated issues
    • New wiki is created
      • You can use math, egyptian hieroglyphs and musical score with zero steps but you can not use infoboxes and citations without importing a lot of templates
    • When a new wiki starts it is totatlly blank; not even basic modules or templates or even a way to show coordinates
    • I have developed automiatic templates from wikidata based on catalan WP module: wikidata. Having to copy everything is hard and not easily trackable
    • As a developer I cannot test how new features work with existing templates
    • For beginners sometimes the documentation for templates isn't very clear. As a module app developer I use templates just once in a while and it's difficult to understand where to get started
      • Lua knowledge is really limited. Wikicode can be easier, but is not universal or simple for small communities

Templates/Modules - ideas for improvements (group 1) (transcription of post-its)

• • 1. (voted for) Global Templates, no way of sharing templates and modules, there should be global templates
    • Sharing templates and modules across multiple wikis is problematic
• 2. (voted for) Make template data mandatory to improve documentation
  • Templating is not very intuitive to new users
• 3. (voted for) Multiwiki synchronisation
  • What are the semantics of templates in different languages
  • How do the template in different languages link to each other
  • Third party multi-wiki admin, sysadmin, user, etc
    • Templates used in multiple wikis (like template:infobox or template:person) are hard to keep in sync across multiple wikis
    • Need a sync/share tool for templates across wikis still allowing customisation
• Improve Template inclusion
  • Weird templates are required to render a set of wiki pages?
  • Weird version of the template was used at a particular point in time?
  • Limitations of template transclusion can be difficult to optimize (to not breach the limits and to improve pageload times)
• Improve mobile friendly-ness
  • A lot of templates are not mobile-friendly
• It would be good to have more module tools
  • Global search and replace
  • Grouping modules into packages
  • Templates/modules should be easily translatable just like MW
• Templates mix content and presentation and metadata all together in wikitext
  • When you copy a module from another project, you have to figure if the dependencies are also the same. Modules are not maintained across wikis
  • Nesting templates is powerful but quickly becomes a problem and adds complexity for understanding and maintenance
• Lua is not the most programmer-friendly language
• Lua IDE?
  • Editing lua code in the browser is a pain, especially if multiple dependant modules are involved
  • Interaction of modules and parser
    • Some lua modules create problems for rendering
    • It would be good to model the interactions

Templates/Modules condensed and merged outcomes of the two groups

• 1) A consumer hub for templates/modules
  • Show versions locally and pull updates
  • Documentation/Transactions
  • Allow rollback?
  • Reviews? Ratings? Feedback?
• 2) A central developer hub to create packages of templates and modules that support peer/code review and versioning and allows synchronisation to wikis. Possibly replicated, overwritable, cascaded
• 3) A way to visualise templates dependencies and modules and instrumentation

Breakout session notes - deep dive into the three main ideas (part II)

• Deep Dive - on 6 topics from earlier breakout groups
  • Impact?
  • Ideas for concrete steps to get there?
  • Who should be involved?
  • What resources would be needed (rough estimate - people needed, size of project, amount of time)?

Gadget/User scripts - deep dive into the ideas (discussions and post-its)

Gadget APIs breakout group (discussion)

• Idea is that we don't know what gadgets are going to do
• Stuff is happening with frontend
• We're going to have to limit what gadgets can do, but also help them to do things correctly
• This brings us to an API
• Instead of telling a gadget owner to manipulate DOM, we give them a way to say how to manipulate the output the way you need, here's the defined API you use
• Directly manipulating the DOM is going to be hard
• PM: You can still use jQuery, but we don't support that.
• JF: We don't support any gadgets currently in an official sense
• MS: Practically speaking, we have to deal with it when we break things
• MS: WordPress as an example: Ways to add things - "put a box here", "here's a hook that gives you the data that you are allowed to manipulate".
• What if you break the DOM?
• ...
• Hook system in JS is notify-only - could change that into a system that ???
• PM: Right now, it's hard to know what gadgets can do.
• Would need to figure out what use cases would satisfy the most gadgets
• This is going to have to be very opinionated
• There's going to be a limit to what we can allow
• It's understood this is meant to be a playground, but the things that are going to be common should have a mechanism for implementation
• Cross reference to the idea of source code control and using standard tools for things like CI
• Nutshell: identify common needs, add to our existing JavaScript API
• We're going to radically change things with the desktop refresh - this is an opportunity to solve some existing problems
• A concern: Will we be dogfooding this?
• It's hard
• Impact:
  • For better or worse, there will a lot
  • Will need to have a process of discovering common use cases as time goes on
  • We might get a test entrypoint out of the deal
• Concrete steps
  • Identify use cases from popular gadgets, sort out the good bad and ugly
  • Analyze how things work in other systems (WordPress, Joomla, etc.)
  • Define expectations for API deprecation policy
• Who
  • Lots of people
  • Working group? Half a year?
• What resources

Gadget APIs breakout group (summary)

• Creating some kind of gadget API - make it easier for gadgets not to rely on DOM
• Make use of version control systems to store gadget code - to enable using existing code tooling - avoid reinventing things on wiki, for code review, CI, testing, etc. Visibility in the open source community, use of IDEs, etc. Software-licensing.
• Invest more in maintenance and ownership of gadgets and userscripts - make it easier to determine who owns stuff, define responsibilities for maintainers/owners of gadgets, etc.
• IMPACT:
  • Differentiate between supported/not supported gadgets -> that'd be clear to the community
  • More control (over supported gadgets)
  • We will be more clear on what to expect from gadgets or what gadgets will do
  • Gadgets will support (all skins)
  • Unit integration testing will be possible and it will be easy o/
• STEPS:
  • 1: Identify current uses / what are gadgets doing
  • 2: a nalyse those and identify:
    • useful
    • good / bad
    • wished for/ ..
  • 3: Check best practices. eg. Wordpress & Co (Drupal, joomla), how they deal with such an issue eg. skins

Gadget/Userscript Tooling breakout group

• line by line code review would be interesting problem to solve.
• git upstream has *mw-to-git* - could be adapted to target wikis. Bi-directional exists. <https://github.com/git/git/tree/master/contrib/mw-to-git
  • ACTION: Just needs onwiki documentation, and minor adaptation?
  • Do we need an extension to do it for gadget namespace?
  • if you're looking at version history onwiki, what shows up?
    • username
• Concern: problem of people being locked out of maintaining their gadget, because of being locked out of mediawiki namespace.
• how does authorization work with git?
• How do we solve the problem that led to Interface Admins being created.
  • limited via gerrit/github - different people can edit
• if you're the author of a gadget, would we want it to be bidrectional? choose to only accept code from repo, or also accept from
• Are there enough contributors at all to require a +2 system?
• Pull-requests and comments are useful regardless
• Is this basically Release Engineering for gadgets?
• Testing?
  • have a sandbox in a page, of everything that a gadget would interact with, to test on. e.g. <https://www.mediawiki.org/wiki/Help:Sample_page
  • Simple? Probably not. Too many gadgets are so contextual that
• Completion missing. Need to go to docs to find anything. Can we add Typing/autocomplete? Codepen style.
• Could have a 2nd build of the api, add a preference that gives it inline. _doc.
• ideally you could go into mw.hook - and find out "what does this do?" etc

• 2 paths:
  • improve the onwiki dev experience
  • migrate into a version control system

• Questions
  • Grant: Is there any browser extension that can do versioning from the browser. Looker VI tool, VI does this for designs.
  • Grant: How do you do it in ngen (?) ?
  • Need to avoid requiring someone to have a GitHub account.
  • IDEA: Require global gadgets to be in version system?
  • IDEA: Require anything with dependencies to be in version system?
  • making gadgets multifile content rather than a single file, that way they match better to what a repo is.
  • give option of multiple backends? github, gitlab, bitbucket, gerrit.
    • Could be agnostic - have a button onwiki to "Remote publish from whatever"
      • Cannot grant autosync though -- "As a gadget author, I submit great looking gadget, it gets approved for autosync, then i add nefarious code"
    • This would actually be a cleaner workflow than is currently available for non-interface admins (IAs), who have to request IAs to edit the page for them.
    • What would octopus merges look like onwiki?

• - Userscripts:
  • Promote some to gadgets for this nicer workflow
    • ACTION: Criteria need to be developed
    • ACTION: Docs need to be written
    • We can help people transition
  • WANT: UI for subscribing to userscripts
    • Gives metrics and dependencies
• STEPS:
  • Deploy something as an experiment? Might only take a few hours for a basic test.
  • Support multiple options - github/gitlab/gerrit
  • Make a gadget, as prototype for extension
  • Need an API for
• PEOPLE:
  • Who could help build the bidirectional system
  • Releng?
  • Interface admins
• RESOURCES:
  • Unknown

Gadget maintenance/ownership group (Bryan D, Sam R, Daniel Z, Timo,
Andre, Niharika, Greg)

• Andre: if some gadget authors decide Phabricator is they want to use, but it should not be decision that is imposed on gadget authors from "above"
  • People should not be reporting things that no one will ever look at - This though is not different that gadget talk pages
• Andre: using tag for gadget is problematic as the "same" gadget could still vary between different wikis, so one tag would be referring to different software
• Andre: tracking gadgets on phabricator does not make sense to me as long as theree is no central repository of gadgets
• Bryan: There are two worlds here: one we (MW devs) live in, with Phabricator used as a tracking system, and the other which happens on wiki. Would there be any value in having a unified universe (e.g. opening a phabricator ticket from wiki?)
• Timo: due to specific nature of gadgets it seems more important for the user to find a developer, I think what is essential here is the discoverability of gadgets
• Sam: it could be made part of the gadget definition is that the gadget developer defines how to contact them, where to report the bug (whether it is talk page, wiki page, phabricator would be completely up to them)
• Bryan: We could borrow the concept of JSON schema for tools, being created for the Toolhub, and use similar structure for gadget definition
• Timo: There is already code (not enabled/merged?) that introduces gadget definition (as a namespace)
• Do we want to have a list of options ppeople can use to pick on where to report those issue, or do we want to allow it to be completely free-form?
  • Might make sense to start with freeform
• Timo: Gadgets 2.0 also changes the gadget page more visual
• DanielZ: on the bottom of the page it could be shown what gadgets are loaded
  • Do we really want to show it to users some details related to the default gadgets
• Bryan: there is this split between us who care about the code quality etc, and others who focus on different things (i..e are not interested in the "how" it works, what is loaded, etc)
• Bryan: there is also people who triage problems and report them on wikis, than in other tech spaces (pharbicator)
• Idea picked up for further consideration:Have hadget have some metadata manifest specifying: original authors, active maintainers, where to report bugs, license)
  • That would be added to the Gadgets extension
  • Impact: other tools could be built to improve discoverability, maintainership would be improved (who do I contact to get things fixed), the licensing topic would also be better surfaced
  • Andre: how would I see it on Special:Gadgets?
    • That seems to be implementation detail. One we have the metadata, there would be variety of ways how to display what to display
  • Timo: Gadgets 2.0 have a lot of things already that would help with
  • Bryan: what do we need to have Gadgets 2.0 to POC state that could deployed
    • Timo: there was a lot concerns about how to roll it out, most of the controversial bits were removed. There is completely automated scripts for converting existing gadgets.
    • Community Liaisons/Product Managers would also needed to help with communication to the communities, help prioritizing regressions, etc.
  • Timo: There is no much of consensus needed. What is needed is two engineers for certain amount of time (2 quarters). Design help would be also valuable.
  • greg: that would be infrastructure part, what could follow is gamification aspects, e.g. define levels of gadgets (golden gadget = has X active maintainers, silver = ...)
  • DanielZ: for existing gadgets we would need to find current maintainers, so that they define the metadata parts like how to contact them, how to report bugs
  • Timo: I would prefer Processes over People for things that are community related
• Side note: Gadgets 3.0 = have per-user gadget repositories, which would provide better way for users to pick other user's scripts they could enabled for themselves
  • Not certain if this concept is going to be needed
• Task for the documentation sprint: Group members review notes and polish them up in places the scribe got the details wrong etc
  • [Speaking as a scribe, the scribe definitely got some details wrong. -- BPB]

PRESENTATION
Questions:

• Impact?
• Ideas for concrete steps to get there?
• Who should be involved?
• What resources would be needed (rough estimate)?

Gadget/User scripts - PRESENTATION

• Publishing gadgets:
  • Workflow:
    • publish on gitlab etc
    • CI
    • publish when ready
    • Interface admin publishes
  • There's a git-remote thing that exists, calls API. Could be a gadget?
  • Userscript registry idea - some method of subscribing.
    • Gives structure, and metrics, dependencies
    • Find who's using what

• APIs for common use cases of gadgets
  • Differentiate supported / unsupported gadgets
  • Be clear on what to expect from gadgets, what they can do with pages they interact with
  • Gadgets could support all skins
  • Possibility of unit testing / CI for gadgets
  • All the things gadgets do
    • Analyse these and ensure sensible
      • What is good, bad, wished for, unhelpful
      • What are the best practices elsewhere for skins (wordpress, joomla etc)
• General problem of how to report bugs, who maintains gadgets, how to find them
  • Initial path, rigid phab hierarchy tracking in detail everything
    • Andre highlighted issues with this appraoch
  • Richer metadata to go with gadget description
    • where do I file a bug report, where do I find the help page
    • Original author
    • Active maintainers
    • Source code license
  • Timo input on Gadgets 2.0 extension
    • Undeployed but appears to be an already worked on area
    • 2 engineers for 2 quarters, with support from community liaison , with PM
      • Could move Gadgets 2.0 forward to an initial launch

Templates/Modules scripts - PRESENTATION

• Templates/Modules
  • Fisch: A way to visual template dependencies
    • Currently hard to maintain templates/modules because you don't know where they're used.
      • Changes are hard, hard to inform people what you're doing because you don't know the people using them
    • Support people in making these things maintainable should lead to less duplication as templates are findable
    • Steps:
      • MVP
        • Get the data on where they're used. It exists, just needs to be compiled and visualized.
          • Some of this may not be right away available as it depends on process executing
        • Generate a graph out of the data to visualize usages of modules/templates
      • Bonus
        • Figure out a way to gather the same data on parameters used or not used
        • Demonstrate what parameters are used
    • Who?
      • CPT
      • Performance
      • DBA
      • Template authors/users
    • Resources
      • PM
      • 2-3 devs
      • UX for visualization
      • Community Person
    • Timeframe
      • Over 1 year
        • But not necessarily solidly
        • Overall a quarter spread over a year

transcription of stickies: (F31064506)

• Amir: A central consumer hub to create packages of templates and modules that support peer/code review and versioning and allows synchronisation to wikis. Possibly replicated, overwritable, cascaded

<!-- -->

• - Bundle: templates, modules, translations, documentation, feedback, export/import
  • Impact: Translations, Declared dependencies, Bundle
  • Concrete steps:
    • Way to define bundle
    • Hub to discover bundles. Special:Bundles
    • Better name than "Bundle"
    • Predefined export list
  • Resources
    • designer
    • Product manager
    • 2 engineers
    • 6 months
    • some volunteers
  • Who: Anyone. You !!

• Amir: Make templates global
  • Need to understand impact and steps
  • Impact
    • Templates have to be transfered that's challenging but possible
    • Good propagation of contents across wikis
    • Good propagation of technical innovation across communities
    • Easy access to a lot of features to small communities
    • The community wants it
  • Steps
    • Balanced templates make cahcing easier
    • Dependency tracking across wikis
    • Move some very internal modules like "no globals" into scribunto
    • Make documentation for module development practice that works without causing bad performance problems
    • Similar to what the parsing team did for the migration from Tidy to Remex - tools, special pages...
    • Create a across wiki group of templates maintainers and coordintors
    • Consider Performance and Caching
      • CPT suggests: Framework to ensure performance of templates
    • Making parsing and balancing measured, to improve [???]
    • consider internationalization
      • messages
      • parameters
      • titles
      • parameter documentation
  • Resources:
    • Not specified

Additional notes on gadgets:

Major benefits for gadget authors include - CI, localization, CR,
Daniel: maintain on git, deploy as extension -> wikimedia-gadgets
QUESTION: Does global mean "global" like GlobalCommons, available to external sites?
Andre: Jenkins has a system that finds errors [?] but currently not easily findable or notifying anyone.
Stephen: in MF, eventlogging sends notices.
TheDJ: stacktrace is often missing

In T234661#5676401, @Quiddity wrote:

Andre: Jenkins has a system that finds errors [?] but currently not easily findable or notifying anyone.

To see JS errors for enabled-by-default gadgets and MediaWiki:Common.js, go to https://integration.wikimedia.org/ci/job/audit-resources/ , under "Last Successful Artifacts" click "Expand all", and select the site.

Hi all. I've created w:en:User:Evad37/WikiUnit.js to make on-wiki unit testing of gadgets and scripts a bit easier to implement, and available when previewing or showing changes to code. Ideally this, or something like, it would become an extension. Feedback would be appreciated at https://en.wikipedia.org/wiki/Wikipedia:Interface_administrators%27_noticeboard#Gadget_and_userscript_unit_testing