Call for participation posted to labs-l mailing list.

Related research: When the Levee Breaks: Without Bots, What Happens to Wikipedia’s Quality Control Processes?

I maintain several bots and tools and I agree that we need to have a documented plan in place here. There are a lot of indispensable tools out there (not mine!) that keep our wikis humming along, and woe betide us if we lose them. We stand to lose a hell of a lot of critical functionality and efficiency if these tools go down. But the critical roles these tools fill are complex, diverse, and often invisible, meaning we have no good way of knowing what the scale of downstream impacts if a key tool goes offline.

@Qgil I'm guessing that my 4 tokens + 1 comment is a pretty weak argument for a main room topic at this stage?

Don't forget 7 subscribers! :)

If unsure, we can keep it "on track" for now. @bd808 what is important is that you start prioritizing proposals in your area, just in (the likely) case that there are not enough pre-scheduled slots for all of them.

In a full 90 minute slot, @chasemp and I would expand the scope of this to cover:

• Planning for the Tool Labs volunteer committee to enforce the Right to fork and Abandoned Tool takeover policies
• New services/features that could be build to help that committee succeed
• Discussion of ways to contact the existing Tool Labs maintainers in addition to the labs-l/labs-announce channels

At the editing team off-site we also raised the idea of improving our frameworks so that gadgets/bots/extensions/labs/production are more similar, so that it is easier to take community-developed code and "productize" it when it becomes important to maintain... and vice-versa, to allow community members to adopt WMF tools which have dropped off the "vital to keep running" list.

Right now the entry point for many community developers is a client-side javascript gadget, which then would have to be rewritten from scratch in python to turn it into a pywikibot, and then rewritten again as a PHP extension (or standalone node.js service?) if it was going to going to be moved to production. It ought to be possibly to grease some wheels here to make it easier for community code to "be born", "grow up" in labs, spend some time being maintained by WMF in production, and then eventually "get old" and be retired out to labs and then community maintenance again.

In T149312#2921097, @cscott wrote:

Right now the entry point for many community developers is a client-side javascript gadget, which then would have to be rewritten from scratch in python to turn it into a pywikibot, and then rewritten again as a PHP extension (or standalone node.js service?) if it was going to going to be moved to production. It ought to be possibly to grease some wheels here to make it easier for community code to "be born", "grow up" in labs, spend some time being maintained by WMF in production, and then eventually "get old" and be retired out to labs and then community maintenance again.

That's a grand vision to think about. I'd love to hear more about a concrete path towards it.

There is a really big difference between the size of problems that are being solved by various tools, gadgets, bots, and scripts hosted in Tool Labs. Some have long term maintainers and others are the result of a weekend or hackathon blitz. Practically none of them are built to withstand the massive scale of anon wiki traffic, and honestly that seems fair to me since MediaWiki itself only survives it with a complex mesh of caches that have been implemented over the years. If deploying a tool was as hard as getting code into MediaWiki's core repo or operations/puppet.git we wouldn't have many tools. Many of the major obstacles to WMF production deployment are things like security review wait times, packaging guidelines, configuration management, and deployment tooling challenges which are mostly orthogonal to the idea of software framework improvements.

I am very interested in helping define and promote practices that make keeping a useful tool running easier. Today my ideas mostly lean towards promoting core FLOSS software practices like licensing and version control as baby steps. The next tier after that includes explaining the utility of separating config and code, and of using and contributing to shared libraries/frameworks rather than starting over from scratch for each project.

In T149312#2921097, @cscott wrote:

Right now the entry point for many community developers is a client-side javascript gadget, which then would have to be rewritten from scratch in python to turn it into a pywikibot, and then rewritten again as a PHP extension (or standalone node.js service?) if it was going to going to be moved to production. It ought to be possibly to grease some wheels here

Does that idea make sense? A client-side JS gadget is probably UI to make an interactive editing task easier, which wouldn't make much sense as a bot in Python or a nodejs service and as a MediaWiki extension would probably just be some boilerplate to just load the same JS. A bot running in Python might or might not be doing something that makes any sense to do server-side as a PHP MediaWiki extension, but if it does make sense it's likely the way it goes about it should be completely different: the pywikibot is likely a long-running process making many API calls, while a PHP MediaWiki extension would have trouble being long-running (use the job queue instead?) and doing things via the API instead of shared backend logic is a bad code smell. Even an extension and a service run and access data in different ways.

Server-side code, whether PHP or nodejs, also has rather different security concerns compared to a browser-based JS gadget or a pywikibot bot: the gadget has relatively few concerns, the pywikibot's concern is mainly in keeping its password private, while the PHP or nodejs doesn't have to care about a password but does need to avoid CSRF and (for the PHP at least) SQL injection.

Moving things between WMF and community "ownership" is worthy of thought, but we should probably keep the consideration along the lines of moving the apples from one place to another without turning them into goats at the same time. For example, JS gadget into extension with minimal PHP boilerplate to load the same JS, or service running on Labs infrastructure to service running on production infrastructure, or changing the "maintainer" field on an extension from WMF to community.

To the owner of this session: Here is the link to the session guidelines page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We encourage you to recruit Note-taker(s) 2(min) and 3(max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be made available in all the session rooms. Good luck prepping, see you at the summit! :)

Note-taker(s) of this session: Follow the instructions here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines#NOTE-TAKER.28S.29 After the session, DO NOT FORGET to copy the relevant notes and summary into a new wiki page following the template here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Your_Session and also link this from the All Session Notes page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/All_Session_Notes. The EtherPad links are also now linked from the Schedule page (https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Schedule) for you!

Session notes: https://etherpad.wikimedia.org/p/devsummit17-developing-community-norms
Video: https://www.youtube.com/watch?v=c7hVVz-QIBw
Slides: https://docs.google.com/presentation/d/1Q9wWhc74Sk0spkWkgpbvILBqBzDELIU8z_VAXmhBZDM

@bd808 are there any other remaining action items on this task? If not, I would close this as resolved!

In T149312#3015931, @srishakatux wrote:

@bd808 are there any other remaining action items on this task? If not, I would close this as resolved!

I've 'been meaning to' put that slides and video up on Commons and leaving this open in the hope that I will eventually remember to do so.