Wikitech-l November 2015

wikitech-l@lists.wikimedia.org

118 participants
109 discussions

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`
by Yongmin Hong 07 Nov '15

07 Nov '15

2015. 11. 6. 오전 8:26에 "Ryan Lane" <rlane32(a)gmail.com>님이 작성: > > Is this simply to support hosted providers? npm is one of the worst package > managers around. This really seems like a case where thin docker images and > docker-compose really shines. It's easy to handle from the packer side, > it's incredibly simple from the user side, and it doesn't require > reinventing the world to distribute things. > > If this is the kind of stuff we're doing to support hosted providers, it > seems it's really time to stop supporting hosted providers. It's $5/month > to have a proper VM on digital ocean. There's even cheaper solutions > around. Hosted providers at this point aren't cheaper. At best they're > slightly easier to use, but MediaWiki is seriously handicapping itself to > support this use-case. > > Please remember, not everyone is technically-enlighted to use VMs. -- revi https://revi.me -- Sent from Android -- 2015. 11. 6. 오전 8:26에 "Ryan Lane" <rlane32(a)gmail.com>님이 작성: Is this simply to support hosted providers? npm is one of the worst package managers around. This really seems like a case where thin docker images and docker-compose really shines. It's easy to handle from the packer side, it's incredibly simple from the user side, and it doesn't require reinventing the world to distribute things. If this is the kind of stuff we're doing to support hosted providers, it seems it's really time to stop supporting hosted providers. It's $5/month to have a proper VM on digital ocean. There's even cheaper solutions around. Hosted providers at this point aren't cheaper. At best they're slightly easier to use, but MediaWiki is seriously handicapping itself to support this use-case. On Thu, Nov 5, 2015 at 1:47 PM, C. Scott Ananian <cananian(a)wikimedia.org> wrote: > Architecturally it may be desirable to factor our codebase into multiple > independent services with clear APIs, but small wikis would clearly like a > "single server" installation with all of the services running under one > roof, as it were. Some options previously proposed have involved VM > containers that bundle PHP, Node, MediaWiki and all required services into > a preconfigured full system image. (T87774 > <https://phabricator.wikimedia.org/T87774>) > > This summit topic/RFC proposes an alternative: tightly integrating PHP/HHVM > with a persistent server process running under node.js. The central service > bundles together multiple independent services, written in either PHP or > JavaScript, and coordinates their configurations. Running a > wiki-with-services can be done on a shared node.js host like Heroku. > > This is not intended as a production configuration for large wikis -- in > those cases having separate server farms for PHP, PHP services, and > JavaScript services is best: that independence is indeed the reason why > refactoring into services is desirable. But integrating the services into a > single process allows for hassle-free configuration and maintenance of > small wikis. > > A proof-of-concept has been built. The node package php-embed > <https://www.npmjs.com/package/php-embed> embeds PHP 5.6.14 into a node.js > (>= 2.4.0) process, with bidirectional property and method access between > PHP and node. The package mediawiki-express > <https://www.npmjs.com/package/mediawiki-express> uses this to embed > MediaWiki into an express.js <http://expressjs.com/> HTTP server. (Other > HTTP server frameworks could equally well be used.) A hook in the ` > LocalSettings.php` allows you to configure the mediawiki instance in > JavaScript. > > A bit of further hacking would allow you to fully configure the MediaWiki > instance (in either PHP or JavaScript) and to dispatch to Parsoid (running > in the same process). > > *SUMMIT GOALS / FOR DISCUSSION* > > > - Determine whether this technology (or something similar) might be an > acceptable alternative for small sites which are currently using shared > hosting. See T113210 <https://phabricator.wikimedia.org/T113210> for > related discussion. > - Identify and address technical roadblocks to deploying modular > single-server wikis (see below). > - Discuss methods for deploying complex wikitext extensions. For > example, the WikiHiero > <https://www.mediawiki.org/wiki/Extension:WikiHiero> extension would > ideally be distributed with (a) PHP code hooking mediawiki core, (b) > client-side JavaScript extending Visual Editor, and (c) server-side > JavaScript extending Parsoid. Can these be distributed as a single > integrated bundle? > > > *TECHNICAL CHALLENGES* > > > - Certain pieces of our code are hardwired to specific directories > underneath mediawiki-core code. This complicates efforts to run > mediawiki > from a "clean tree", and to distribute piece of mediawiki separately. > In > particular: > - It would be better if the `vendor` directory could (optionally) live > outside the core mediawiki tree, so it could be distributed > separately from > the main codebase, and allow for alternative package structures. > - Extensions and skins would benefit from allowing a "path-like" list > of directories, rather than a single location underneath the > core mediawiki > tree. Extensions/skins could be distributed as separate packages, > with a > simple hook to add their locations to the search path. > - Tim Starling has suggested that when running in single-server mode, > some internal APIs (for example, between mediawiki and Parsoid) would be > better exposed as unix sockets on the filesystem, rather than as > internet > domain sockets bound to localhost. For one, this would be more "secure > by > default" and avoid inadvertent exposure of internal service APIs. > - It would be best to define a standardized mechanism for "services" to > declare themselves & be connected & configured. This may mean standard > ro > utes on a single-server install (`/w` and `/wiki` for core, `/parsoid` > for parsoid, `/thumb` for the thumbnailer service, etc), standard ports > for each service (with their own http servers), or else standard > locations > for unix sockets. > - Can we leverage some of the various efforts to bridge composer and npm > (for example <https://github.com/eloquent/composer-npm-bridge>), so we > don't end up with incompatible packaging? > > Phabricator ticket: https://phabricator.wikimedia.org/T114457 > > Download the code for mediawiki-express and play with it a bit and let's > discuss! > --scott > > -- > (http://cscott.net) > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

7 11

[RFC/Summit] `npm install mediawiki-express`
by C. Scott Ananian 07 Nov '15

07 Nov '15

Architecturally it may be desirable to factor our codebase into multiple independent services with clear APIs, but small wikis would clearly like a "single server" installation with all of the services running under one roof, as it were. Some options previously proposed have involved VM containers that bundle PHP, Node, MediaWiki and all required services into a preconfigured full system image. (T87774 <https://phabricator.wikimedia.org/T87774>) This summit topic/RFC proposes an alternative: tightly integrating PHP/HHVM with a persistent server process running under node.js. The central service bundles together multiple independent services, written in either PHP or JavaScript, and coordinates their configurations. Running a wiki-with-services can be done on a shared node.js host like Heroku. This is not intended as a production configuration for large wikis -- in those cases having separate server farms for PHP, PHP services, and JavaScript services is best: that independence is indeed the reason why refactoring into services is desirable. But integrating the services into a single process allows for hassle-free configuration and maintenance of small wikis. A proof-of-concept has been built. The node package php-embed <https://www.npmjs.com/package/php-embed> embeds PHP 5.6.14 into a node.js (>= 2.4.0) process, with bidirectional property and method access between PHP and node. The package mediawiki-express <https://www.npmjs.com/package/mediawiki-express> uses this to embed MediaWiki into an express.js <http://expressjs.com/> HTTP server. (Other HTTP server frameworks could equally well be used.) A hook in the ` LocalSettings.php` allows you to configure the mediawiki instance in JavaScript. A bit of further hacking would allow you to fully configure the MediaWiki instance (in either PHP or JavaScript) and to dispatch to Parsoid (running in the same process). *SUMMIT GOALS / FOR DISCUSSION* - Determine whether this technology (or something similar) might be an acceptable alternative for small sites which are currently using shared hosting. See T113210 <https://phabricator.wikimedia.org/T113210> for related discussion. - Identify and address technical roadblocks to deploying modular single-server wikis (see below). - Discuss methods for deploying complex wikitext extensions. For example, the WikiHiero <https://www.mediawiki.org/wiki/Extension:WikiHiero> extension would ideally be distributed with (a) PHP code hooking mediawiki core, (b) client-side JavaScript extending Visual Editor, and (c) server-side JavaScript extending Parsoid. Can these be distributed as a single integrated bundle? *TECHNICAL CHALLENGES* - Certain pieces of our code are hardwired to specific directories underneath mediawiki-core code. This complicates efforts to run mediawiki from a "clean tree", and to distribute piece of mediawiki separately. In particular: - It would be better if the `vendor` directory could (optionally) live outside the core mediawiki tree, so it could be distributed separately from the main codebase, and allow for alternative package structures. - Extensions and skins would benefit from allowing a "path-like" list of directories, rather than a single location underneath the core mediawiki tree. Extensions/skins could be distributed as separate packages, with a simple hook to add their locations to the search path. - Tim Starling has suggested that when running in single-server mode, some internal APIs (for example, between mediawiki and Parsoid) would be better exposed as unix sockets on the filesystem, rather than as internet domain sockets bound to localhost. For one, this would be more "secure by default" and avoid inadvertent exposure of internal service APIs. - It would be best to define a standardized mechanism for "services" to declare themselves & be connected & configured. This may mean standard ro utes on a single-server install (`/w` and `/wiki` for core, `/parsoid` for parsoid, `/thumb` for the thumbnailer service, etc), standard ports for each service (with their own http servers), or else standard locations for unix sockets. - Can we leverage some of the various efforts to bridge composer and npm (for example <https://github.com/eloquent/composer-npm-bridge>), so we don't end up with incompatible packaging? Phabricator ticket: https://phabricator.wikimedia.org/T114457 Download the code for mediawiki-express and play with it a bit and let's discuss! --scott -- (http://cscott.net)

4 5

Parsoid convert arbitrary HTML?
by James Montalvo 06 Nov '15

06 Nov '15

Can Parsoid be used to convert arbitrary HTML to wikitext? It's not clear to me whether it will only work with Parsoid's HTML+RDFa. I'm wondering if I could take snippets of HTML from non-MediaWiki webpages and convert them into wikitext. Thanks, James

4 6

MW support for Composer equivalent for JavaScript packages
by Daniel Werner 06 Nov '15

06 Nov '15

Hey, I just wanted to check in about the status of enabling JavaScript package management usage in MediaWiki. I am basically talking about an equivalent for JS to what we have with Composer for PHP. Real-world example: The "data-values/value-view" package[0] is defining "jquery.event.special.eachchange.js": ValueView/lib/jquery.event/jquery.event.special.eachchange.js Now, recently I needed the same functionality in one of my extensions, so I just copied it over. [1] I know that this is the worst way one could do this, but as far as I can see we don't have that much of a choice right now. Here are the alternative options I can see: Moving "jquery.event.special.eachchange.js" out of the "data-values/value-view" package into its own "WMDE/jquery-eachchange" package... 1. ... and using it in my extension via composer. + pro: two or more extensions or other packages requiring this package will still result in having only one MW-wide installation.. - con: requires MW specific code which is actually not related to the MW-independent package to feed the resource loader. - con: using Composer to manage pure JavaScript packages! Uuuh, ugly! 2. ... and having a build step in other packages using the package, pulling the "WMDE/jquery-eachchange" somewhere into the file structure of the packages/extensions using it. + pro: don't need to abuse composer, we can use "npm", "Bower" or any other arbitrary JS package manager here. - con: got to tell resource loader somehow... (didn't think so much about that yet) - con: if more than one extensions or other packages require this package we still end up with the same code twice or more often in one MW installation. 3. Combining 1 and 2: Start with 2, using a JS package manager. Then going to 1, creating a composer package and pulling the "WMDE/jquery-eachchange" package in via some build script. + pro: The two pros from 1 + 2 + pro: ^^ - con: still got to tell resource loader somehow... - con: Overhead; We now create two packages where the Composer one is just a bridge to the MW-world, still polluting packagist.org. Still kind of ugly and more effort for publishing a package and therefore potentially scaring programmers away from doing so since they've got better things to do than doing work that could be automated. I have not seen Approach 2 and 3 yet. Though I could imagine that the VisualEditor team has used something like that. Approach 1 is the way the "data-values/value-view" package itself is being handled. And that package should actually be a MW independent pure JS package but right now it contains MW specific code and uses composer for distribution! There is still another option but that had to be properly implemented: 4. Choose one native JS package manager for now and go with it (add support for others later perhaps). Integrate it properly with MW (resource loader to begin with), document how to use it and finally distribute JS code coming from the MW world but useful for other projects in a way where it can actually be used in a non-MW context. This has already been bugging me when working on Wikidata. Now I'd like to reuse some of the code I have written there without spending hours and hours with option 3 because there should be support for option 4 rather sooner or later. So I am wondering; Does anyone have any thoughts, any alternatives perhaps or is there any roadmap on anything like the option 4 that I have shown? Cheers, Daniel [0]: https://packagist.org/packages/data-values/value-view [1]: https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/r…

7 9

Superprotect is gone
by Quim Gil 06 Nov '15

06 Nov '15

Superprotect [1] was introduced by the Wikimedia Foundation to resolve a product development disagreement. We have not used it for resolving a dispute since. Consequently, today we are removing Superprotect from Wikimedia servers. Without Superprotect, a symbolic point of tension is resolved. However, we still have the underlying problem of disagreement and consequent delays at the product deployment phase. We need to become better software partners, work together towards better products, and ship better features faster. The collaboration between the WMF and the communities depends on mutual trust and constructive criticism. We need to improve Wikimedia mechanisms to build consensus, include more voices, and resolve disputes. There is a first draft of an updated Product Development Process [2] that will guide the work of the WMF Engineering and Product teams.[3] It stresses the need for community feedback throughout the process, but particularly in the early phases of development. More feedback earlier on will allow us to incorporate community-driven improvements and address potential controversy while plans and software are most flexible. We welcome the feedback of technical and non-technical contributors. Check the Q&A for details.[4] [1] https://meta.wikimedia.org/wiki/Superprotect [2] https://www.mediawiki.org/wiki/WMF_Product_Development_Process [3] https://www.mediawiki.org/wiki/Wikimedia_Engineering [4] https://www.mediawiki.org/wiki/WMF_Product_Development_Process/2015-11-05#Q… -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 3

[RfC/Summit] Shadow namespaces
by Legoktm 06 Nov '15

06 Nov '15

Hi, I'm behind on my summit planning, but here's what I'd like to discuss at the developer summit for the Shadow namespaces RfC[1]. 1. At what layer should shadow namespaces be integrated into the code? Should we continue to subclass Article? How do we efficiently implement things like batch lookups? (T88644) 2. How will we integrate remote content with search and other discovery mechanisms? We currently have Commons file results integrated with normal search results, but it's usefulness is questionable (T96535). Will it be possible to implement this for people using remote content via the API? 3. How will we keep track of usage and invalidate caches? Should we just have a central link table like GlobalUsage? What about API users? 4. Should we allow people to chain "repositories" like we currently allow with file repos? The outcome I'd like to see is having a plan ready on how to migrate the foreign file system to a generic arbitrary namespace one, which should completely obsolete the GlobalUserPage extension. The Phabricator task for this session at the summit is T115762[2]. [1] https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces [2] https://phabricator.wikimedia.org/T115762 -- Legoktm

1 0

mediawiki-extension cli extension installer/updater released
by Daniel Friesen 06 Nov '15

06 Nov '15

As part of a side project in my job at Redwerks[1], I've released an early version of a mediawiki-extension cli tool. https://github.com/redwerks/mediawiki-extension-command#readme The tool requires Node.js (in addition to git and php to run clones and composer). It can be installed with `sudo npm install -g mediawiki-extension` and then `mediawiki-extension setup`. The command can download and upgrade any extension we have in Gerrit. Extensions using composer will automatically be installed via composer otherwise it'll be cloned from git. If available, release tags (like "1.0.0" or "v3.0.0") will be used, otherwise master will be used. You'll still need to require and configure the extension yourself. But this is supposed to greatly simplify acquiring and bulk-updating extensions via the cli. Some examples of use. Clone ParserFunctions from git. $ mediawiki-extension download ParserFunctions Install SemanticMediaWiki and SemanticForms with composer. $ mediawiki-extension download SemanticMediaWiki SemanticForms Clone Widgets with from git and checkout the most recent version tag. $ mediawiki-extension download Widgets Update all your MediaWiki extensions: $ mediawiki-extension update --all Switch an extension cloned from git master to the REL branch for the installed version of MediaWiki. $ mediawiki-extension switch ParserFunctions git-rel [1] http://redwerks.org/ -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

3 3

Update from the Wikimedia Performance Team
by Ori Livneh 06 Nov '15

06 Nov '15

Hello, This is the first monthly report from the Wikimedia Performance Team. The purpose of these reports is to showcase our work, track our progress, and spark conversation. ## Who we are ## As the Wikimedia Foundation’s Performance Team, we want to create value for readers and editors by making it possible to retrieve and render content at the speed of thought, from anywhere in the world, on the broadest range of devices and connection profiles. We are five engineers: Aaron Schulz, Gilles Dubuc, Peter Hedenskog, Timo Tijhof, and me. Each of us was born in a different country and has a different mother tongue. We work out of San Francisco, London, Stockholm, and Montpellier. ## What we are working on ## * Availability. Although Wikimedia Foundation currently operates six data centers, MediaWiki is only running on one (in Ashburn, Virginia). If you are an editor in Jakarta, Indonesia, content has to travel over 15,000 kilometers to get from our servers to you (or vice versa). To run MediaWiki concurrently from multiple places across the globe, our code needs to be more resilient to failure modes that can occur when different subsystems are geographically remote from one another. https://phabricator.wikimedia.org/T88445 * Performance testing infrastructure. WebPageTest provides a stable reference for a set of browsers, devices, and connection types from different points in the world. It collects very detailed telemetry that we use to find regressions and pinpoint where problems are coming from. This is addition to the more basic Navigation Timing metrics we gather from real users in production. https://phabricator.wikimedia.org/T109666 * Media stack. We're currently working on overhauling our thumbnail infrastructure to achieve multiple goals. Improving future-proof maintainability by taking thumbnail code out of MediaWiki-Core and using a service instead to perform thumbnail operations. Saving on expensive storage by no longer storing multiple copies of all thumbnails on disk forever. Enabling far-future expires for images, to greatly improve their client cacheability. And finally switching to the best performing underlying software to generate thumbnails faster. https://phabricator.wikimedia.org/T111718 * ResourceLoader. ResourceLoader is the MediaWiki subsystem that is responsible for loading JavaScript and CSS. Whereas much of MediaWiki's code executes only sparingly (in reaction to editors modifying content) ResourceLoader code runs over half a billion times a day on hundreds of millions of devices. Its contribution to how users experience our sites is very large. Our current focus is on improving ResourceLoader's cache efficiency by packaging and delivering JavaScript and CSS code in a way that allows it to be reused across page views without needing to be repeatedly downloaded. https://phabricator.wikimedia.org/T102578 ## How are we doing? ## In future reports, we will spend less time on introductions and more time reporting on how particular performance metrics have trended since the previous report and why. In the meantime, we invite you to check out our dashboards: * https://performance.wikimedia.org/ * https://grafana.wikimedia.org/dashboard/db/navigation-timing * https://grafana.wikimedia.org/dashboard/db/time-to-first-byte * https://grafana.wikimedia.org/dashboard/db/job-queue-health ## Feedback? ## Please let us know what you think about these reports and whether we have picked the right lists to send it to. (We're going to make sure this information is available on mediawiki.org too.) Until next time, Aaron, Gilles, Peter, Timo & Ori

2 2

Developer Relations Weekly Summary
by Quim Gil 05 Nov '15

05 Nov '15

Original web version: https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2015-11-05 Help develop the next summary here <https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary/Next>! Software - Wikimedia UI elements available in HTML + Bootstrap <http://wikimedia-ui.wmflabs.org/> help you producing quick and visually accurate mockups. (demo <https://www.youtube.com/watch?v=LNAQD4RCeWM&feature=youtu.be&t=1997>, discussion <http://thread.gmane.org/gmane.org.wikimedia.mediawiki.design/1390>) - OOjs UI <https://www.mediawiki.org/wiki/OOjs_UI> 0.13.0 (breaking change, announcement <http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/84712> ) - Kiwix <http://www.kiwix.org/> for iOS 1.2 (announcement <https://lists.wikimedia.org/pipermail/offline-l/2015-October/001343.html> , download <https://itunes.apple.com/us/app/kiwix/id997079563>) Events - The Wikimedia Developer Summit 2016 <https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016> has 27 session proposals on track <https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/>, 12 missing active discussion, 12 missing expected information. - By 2015-11-06 all Summit proposals must have active discussions and a Summit plan <https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Submissions_…> documented in the description. - Invitation to Wikimania 2016 Scholarship Committee <https://lists.wikimedia.org/pipermail/wikimedia-l/2015-November/079655.html> (deadline: 2015-11-15) - Wikisource Conference 2015 <https://meta.wikimedia.org/wiki/Wikisource_Community_User_Group/Wikisource_…> (includes hackathon and technical workshops) on 20-22 Nov 2015 in Vienna. - Upcoming Lightning Talks <https://www.mediawiki.org/wiki/Lightning_Talks#Upcoming_Lightning_Talks> on 2015-11-24. You can sign up or propose a talk. - Video recording of Tech Talk: Nothing Left but Always Right: The Twisted Road to RTL Support <https://plus.google.com/u/0/b/103470172168784626509/events/ck5ibgn8l2t056h5…> Documentation - New: Presenting Wikidata knowledge <https://www.mediawiki.org/wiki/API:Presenting_Wikidata_knowledge>. Display multilingual information from Wikidata in your application by associating items with 'Q' entities. Outreach - After the deadline for submitting Outreachy round 11 <https://www.mediawiki.org/wiki/Outreachy/Round_11> proposals, Wikimedia mentors are evaluating 14 candidates <https://phabricator.wikimedia.org/tag/outreachy-round-11/>. Community feedback is especially welcomed now. Selected participants will be announced on 2015-11-17. The proposals, sorted by order of submission: - Easier categorization of pictures in Upload to Commons Android app <https://phabricator.wikimedia.org/T115101>, by josephine_l <https://phabricator.wikimedia.org/p/josephine_l/> - Improving static analysis tools for MediaWiki <https://phabricator.wikimedia.org/T115585>, by TasneemLo <https://phabricator.wikimedia.org/p/TasneemLo/> - Add ZIM format support for OCG <https://phabricator.wikimedia.org/T115907>, by Minervaxox <https://phabricator.wikimedia.org/p/Minervaxox/> - Wiki 3d warehouse <https://phabricator.wikimedia.org/T115987>, by Jeeltcraft <https://phabricator.wikimedia.org/p/Jeeltcraft/> - Making Education Dash Program usable for all languages and projects <https://phabricator.wikimedia.org/T116201>, by Haritha28 <https://phabricator.wikimedia.org/p/Haritha28/> - Implement HTML e-mail support in MediaWiki <https://phabricator.wikimedia.org/T116223>, by rosalieper <https://phabricator.wikimedia.org/p/rosalieper/> - Extension to transclude Git content into Wiki Pages <https://phabricator.wikimedia.org/T116277>, by Galorefitz <https://phabricator.wikimedia.org/p/Galorefitz/> - Implement HTML e-mail support in MediaWiki <https://phabricator.wikimedia.org/T116303>, by Devirk <https://phabricator.wikimedia.org/p/Devirk/> - Add ZIM format support for OCG <https://phabricator.wikimedia.org/T116482>, by Adishaporwal <https://phabricator.wikimedia.org/p/Adishaporwal/> - Improving MediaWikiAnalysis <https://phabricator.wikimedia.org/T116733>, by Anmolkalia <https://phabricator.wikimedia.org/p/Anmolkalia/> - Technology to transclude git content into wiki pages <https://phabricator.wikimedia.org/T117167>, by Akangupt <https://phabricator.wikimedia.org/p/Akangupt/> - Making Education Dash Program usable for all languages and projects <https://phabricator.wikimedia.org/T117363>, by Wdssilva <https://phabricator.wikimedia.org/p/Wdssilva/> - Making Education Dash Program usable for all languages and projects <https://phabricator.wikimedia.org/T117372>, by Kenua <https://phabricator.wikimedia.org/p/Kenua/> - Technology to transclude git content into wiki pages <https://phabricator.wikimedia.org/T117426>, by Shrutika719 <https://phabricator.wikimedia.org/p/Shrutika719/> Community health - The discussion about the Code of Conduct draft <https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft> welcomes feedback on Finishing the "Report a problem" section <https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finishing_the_.22…>. Open topics: - "All reports will be processed confidentially" <https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#.22All_reports_wi…> - If you send a report to maintainers, include a reference to this document <https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#If_you_send_a_rep…> Project management - No news? Code review - Wikia <https://www.mediawiki.org/wiki/Wikia> has instituted a review process for sitewide JavaScript pages <http://community.wikia.com/wiki/Help:JavaScript_review_process> after experiencing two attacks <http://community.wikia.com/wiki/Thread:890734> that revoked certain permissions to admins. (source <https://phabricator.wikimedia.org/T71445>) Metrics - m:Gadgets <https://meta.wikimedia.org/wiki/Gadgets> offers monthly reports about usage of Gadgets in Wikimedia wikis. - Related, the announcement <http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/84737> of the new Special:GadgetUsage report available in all wikis. Gerrit Key performance indicators <https://www.mediawiki.org/wiki/Community_metrics#Key_performance_indicators> [1] <http://korma.wmflabs.org/browser/kpi_overview.html> [2] <http://korma.wmflabs.org/browser/repository.html?repository=gerrit.wikimedi…> - Median age of open changesets waiting for review: 36.4 days in October (was 36.2 in September, 54.4 a year ago) - MediaWiki core: 64.2 days (was 58.2, 65.1) - Number of open changesets waiting for review: 1183 (was 1053, 1052) - MediaWiki core: 208 (was 200, 267) - Number of new changesets submitted per month: 3421 (was 3703, 3164) - MediaWiki core: 508 (was 512, 526) - Number of code uploaders per month: 212 (was 214) - Number of code reviewers per month: 195 (was 195) - Number of code committers per month: 131 (was 131) Code repositories with slowest code review <http://korma.wmflabs.org/browser/gerrit_review_queue.html>: 1. Wikistats <https://gerrit.wikimedia.org/r/#/q/project:analytics/wikistats+status:open,…>: 505 days, 5 changesets. (T113695 <https://phabricator.wikimedia.org/T113695>) 2. BookManagerv2 <https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…>: 473 days, 21 changesets. (T117105 <https://phabricator.wikimedia.org/T117105>) 3. BayesianFilter <https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…>: 416 days, 1 changeset. 4. UploadWizard <https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…>: 383 days, 12 changesets. 5. extdist <https://gerrit.wikimedia.org/r/#/q/status:open+project:labs/tools/extdist,n…>: 342 days, 1 changeset. Phabricator - 885 active users in Wikimedia Phabricator <https://www.mediawiki.org/wiki/Community_metrics> during October, our highest number so far. - 348 new accounts in Wikimedia Phabricator <https://www.mediawiki.org/wiki/Community_metrics> (was 363 in September). -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 1

2015-11-04 Scrum of Scrums meeting notes
by Grace Gellerman 05 Nov '15

05 Nov '15

https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-11-04

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l November 2015