Hi all,
This week, we're sending out a more detailed version of the TechCom
meeting minutes. Let us know if you find this helpful.
Present: Dan Andreescu, Daniel Kinzler, Timo Tijhof, Alex Paskulin,
Niklas Laxstrom
== RFC Frontend build step ==
<https://phabricator.wikimedia.org/T199004> ==
* Recently moved from open to stalled
* Discussion of the issues presented in the RFC from a process perspective:
* DA: The question on the RFC was originally: How can we implement a build
step? The discussion on the RFC has been centered around whether we should
implement a build step. The authors are trying to address concerns to enable
them to implement it since it’s an industry-wide practice.
* TT: We should focus on the underlying problems this is trying to solve.
A build step is inevitable. Many problems discussed so far on the RFC don’t
call for a build step. There are some architecture issues in the things
proposed that can’t be reconciled. We can build towards a deliverable of
compiling a Vue component.
* DK: Process-wise, what is the problem with a team deciding that they want
a server side build step? What’s the impact? In theory, we want to maximize
coherence and autonomy; there’s a polarity between the two.
* DA: If they find a mainstream way, they’ll migrate to it. I don’t think
it’s problematic. They’re saying that they’ll address all the concerns if
they can.
* TT: This impacts security for the developers running insecure code on
developer host machines, security for production (can be contained/network
isolated), and security for the end-user (this isn’t just helping create
commits or run tests, it modifies and adds code we sent to a billion
people’s
devices). Reproducing the same locally, in CI and prod. Workflow problems
like cherry-pick and revert in production branches.
* DK: To what extent are we willing to run arbitrary code on our systems?
Which communities do we trust? (Example: Debian maintainers are vetted, NPM
packages are not)
* TT: NPM packages are known for depending on a lot of unreviewed/unknown
code. See <https://phabricator.wikimedia.org/T199004#6045136>. But, there
are communities within the NPM ecosystem that follow different principles,
and use fewer dependencies.
* DA: We could set a policy about reviewing and vendoring such service,
run in a sandbox, pinned to specific versions. We could set a requirement
that packages need to be vetted.
== Send regular overview about Wikimedia development policies ==
<https://phabricator.wikimedia.org/T164538>
* Moved from Inbox to In progress on TechCom board
== RFC: Amendment to the Stability interface policy ==
<https://phabricator.wikimedia.org/T255803>
* On last call ending July 8
* Discussion ongoing
== RFC: Hybrid extension management ==
<https://phabricator.wikimedia.org/T250406>
* In Phase 3: Explore
* Discussion ongoing
== Next week public IRC discussion ==
No discussion scheduled for next week
See also the TechCom RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
--
Alex Paskulin
Technical Writer
Wikimedia Foundation
The Wikimedia Engineering Productivity team has decided that Wikimedia
projects will move from Gerrit to GitLab for code review and
continuous integration.
They have decided that this decision is not subject to any formal RFC.
Previous attempts to change the code review system went through an
RfC. They are, however, looking for feedback.
More information is at
<https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/GitLab>
and the associated talk page.
Regards,
AntICompositeNumber
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
Hello.
(Apologies for cross-posting, and that you are likely not reading this
message in your native language: translations of the full announcement may
be available on Meta [1], and will be posted to all the wikis in the next
few days. Please consider helping with translations in the meantime.
Thanks!)
The Wikimedia Foundation Board of Trustees has approved a new sister
project, temporarily titled "Abstract Wikipedia" [2].
Its goal is to generate baseline encyclopedic content in a multilingual
fashion, allowing more contributors and more readers to share more
knowledge in more languages. You can learn more on Meta [1] and can also
join the new dedicated mailing list [3].
Talk to you soon!
[1]
https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/June_…
[2] https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia
[3] https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
--
Erica Litrenta
Manager, Community Relations Specialists
https://meta.wikimedia.org/wiki/User:Elitre_(WMF)
Hi,
I'm excited to share the release of the Vue.js Migration Project
Charter[0] today.
This is an update on the Foundation's evaluation and adoption of
Vue.js framework for building user-interfaces in a modern,
developer-friendly, inclusive, and internationalization-ready way. It
is a result of the platform evolution program[1] recommendations.
We aim to achieve this with help of the shared components and patterns
library Wikimedia Vue UI (WVUI). We project to implement first,
slimmed-down components for it as part of the Vue.js Search Case
Study[2].
Please find further details on the article. Also keep in mind, that
the shared charter reflects current planning and is subject to
repeated evaluation and possible change. Provide any feedback or
questions, on the talk page[3], technical issues and ideas on
Phabricator tagged with 'Vue.js'[4] or directly to me.
Thanks specifically to Jazmin Tanner, who has played an essential part
in gathering inputs from all stakeholders and interested groups in
synthesizing the charter.
Also to Stephen Niedzielski as a thoughtful driver of the Vue.js
Search Case Study – one of the first major milestones. And generally,
thanks to all members of FAWG, WMDE, Product and Technology department
teams (Reading Web, Editing, Growth, Language, Multimedia, Design,
Core Platform, Performance) involved and leadership for continuous
strong support of this wide-reaching project.
Best,
Volker
[0] - https://www.mediawiki.org/wiki/Vue.js/Migration_Project_Charter
[1] - https://www.mediawiki.org/wiki/Platform_Evolution
[2] - https://phabricator.wikimedia.org/project/view/4767/
[3] - https://www.mediawiki.org/wiki/Talk:Vue.js/Migration_Project_Charter
[4] - https://phabricator.wikimedia.org/tag/vue.js/
Hi,
for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-07-01
Željko
--
= 2020-07-01 =
== Callouts ==
* Release Engineering
** [All] Review guidance at [[wikitech:Deployments/Covid-19]] and Code
Deployment Office Hour at 17:00UTC in #wikimedia-office
** "scap sync" will be renamed to "scap sync-world" in the next
release. If you use "scap sync" non-interactively, please add a note
to: [[phab:T250302]] (and also, explain why you're using it)
** scap sync now has option --canary-wait-time; [[phab:T217924]]
** Gerrit was updated over the weekend to version 3
== Product ==
=== iOS native app ===
* Updates:
** Early development and research on new experiments for 6.7 -
[[phab:project/view/4661]]
** WWDC research
=== Android native app ===
* Updates:
** User contribution history screen now in production.
** Starting next development phase: [[phab:project/view/4819/]]
=== Web ===
* Updates:
** '''Summary''': sidebar instrumentation and content max-width for
Desktop Improvements Project (DIP), building initial component
primitives for Vue.js search.
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project
(Vector / DIP)]]:
*** [[phab:T254195|<nowiki>Implement a core 'clearfix' mixin in
mediawiki.mixin and evaluate deprecation/removal of 'visualClear'
class</nowiki>]]
*** [[phab:T254851|<nowiki>Current checkbox hack doesn't provide
<Enter> or <Space> as toggle action</nowiki>]]
*** [[phab:T253178|<nowiki>UniversalLanguageSelector should stop using
the SkinTemplateOutputPageBeforeExec hook</nowiki>]]
*** [[phab:T250282|<nowiki>Build sidebar instrumentation</nowiki>]]
*** [[phab:T246420|<nowiki>Limit content width, and refine alignment &
styling of relevant elements</nowiki>]]
*** [[phab:T246419|<nowiki>Build collapsible sidebar and sidebar
button </nowiki>]]
*** [[phab:T60137|<nowiki>Deprecate the
SkinTemplateOutputPageBeforeExec hook</nowiki>]]
*** [[phab:T256092|<nowiki>[Modern Vector] Fix broken rendering of
`main` and `dialog` elements in IE9-11</nowiki>]]
*** [[phab:T251212|<nowiki>[Dev] Drop VectorTemplate usage in Vector</nowiki>]]
*** [[phab:T255319|<nowiki>Eventually deprecate
SkinTemplateNavigation::SpecialPage and SkinTemplateNavigation hooks
in favor of SkinTemplateNavigation::Universal </nowiki>]]
*** [[phab:T244392|Vue.js search case study]]:
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T255230|<nowiki>Align MinervaNeue's/MobileFrontend
variables to CSS variable naming scheme</nowiki>]]
*** [[phab:T251475|<nowiki>History page insert `ins`/ delete `del`
elements have accessibility issues </nowiki>]]
*** [[phab:T237036|<nowiki>ext.uls.interface should set targets and
explicitly not target the Minerva skin</nowiki>]]
*** [[phab:T235712|<nowiki>Fix the most common "Module not loadable on
target mobile" warnings (Oct 2019)</nowiki>]]
*** [[phab:T234550|<nowiki>Mobile version Star for Watchlist not
consistent</nowiki>]]
*** [[phab:T240622|<nowiki>[Technical debt payoff] Remove
InlineDiffFormatter and InlineDifferenceEngine from
MobileFrontend</nowiki>]]
*** [[phab:T219793|<nowiki>Mobile web donate link</nowiki>]]
*** [[phab:T212465|<nowiki>[EPIC] None of our View's should exhibit 2
levels of inheritance</nowiki>]]
** Standardization
*** [[phab:T256520|<nowiki>Consider 'normalize' stylesheet RL module</nowiki>]]
*** [[phab:T214477|<nowiki>Re-design progress bar for OOUI</nowiki>]]
*** [[phab:T112747|<nowiki>Devise a generic way for theme-agnostic
stylesheets to adapt to the current theme</nowiki>]]
*** [[phab:T253598|<nowiki>Focus not visible on checkbox in high
contrast dark mode</nowiki>]]
** Portals
*** [[phab:T128546|<nowiki>[Recurring Task] Update Wikipedia and
sister projects portals statistics</nowiki>]]
** Miscellaneous
*** [[phab:T255814|<nowiki>Latest version of SkinBlueSpiceCalumma is
not compatible with current version of Chameleon</nowiki>]]
*** [[phab:T255717|<nowiki>Scope and use of mediawiki.skinning's
'elements.less' file</nowiki>]]
*** [[phab:T248751|<nowiki>Adopt mustache templates in Modern and
Monobook</nowiki>]]
*** [[phab:T231615|<nowiki>Use project logo wordmarks on Wikimedia
projects in Timeless</nowiki>]]
*** [[phab:T212521|<nowiki>RFC: Reconsider how we run QUnit unit
tests</nowiki>]]
*** [[phab:T255299|<nowiki>Some images appear when Show Images is
disabled</nowiki>]]
*** [[phab:T247033|<nowiki>Add 'i18n-directionality.less' file to core
and extract overarching theme styles from legacy.less</nowiki>]]
=== Product Infrastructure ===
* Blocked by:
** RelEng: to review codehealth pipeline for push notifications
[[gerrit:604830]]
=== UI Standardization ===
* Updates:
* Design Style Guide
** Prep work for WVUI – technically and planning, including
WikimediaUI Base variables amendment and extension.
** Improved long-standing consistency imagery representation, both
desktop and mobile [[phab:T251347]]
** Icon additions: 'doubleChevronStart', 'doubleChevronEnd', 'userAdd'
** “Link” component got updated to reflect “new” treatment
https://design.wikimedia.org/style-guide/components/links.html
== Technology ==
=== Fundraising Tech ===
* Updates:
** Finishing up matching gifts data sync and form autocomplete
** Overhauling data export to bulk mailer house
** Implementing workaround for browsers blocking pixels from setting
cookies for hiding banners
=== Engineering Productivity ===
==== Release Engineering ====
* Blocking:
** Product Infrastructure - to review codehealth pipeline for push
notifications [[gerrit:604830]]
* Updates:
** [All] Deployments/Covid-19 [[wikitech:Deployments/Covid-19]]
** Train Health
*** Last week: 1.35.0-wmf.38 - [[phab:T254175]]
*** This week: 1.35.0-wmf.39 - [[phab:T254176]]
*** Next week: 1.35.0-wmf.40 - [[phab:T256668]]
=== Site Reliability Engineering ===
* Updates:
** Proton to be switched over to the k8s TLS enabled version.
** Work on mobileapps traffic being routed to k8s will start soon.
Hello,
TLDR: The following hooks are deprecated in 1.35:
SkinTemplateBuildNavUrlsNav_urlsAfterPermalink,
SkinTemplatePreventOtherActiveTabs, SkinTemplateTabAction,
BaseTemplateAfterPortlet, SkinTemplateToolboxEnd, BaseTemplateToolbox,
SkinTemplateOutputPageBeforeExe.
The longer version:
As part of the desktop improvements project
<http://mediawiki.org/wiki/Desktop%20improvements> we've been making some
exciting changes in MediaWiki's skin architecture. This has involved
migrating away from the BaseTemplate PHP class to Mustache as the render
engine for Vector. In 1.36, the Vector skin plans to use the new SkinMustache
class
<https://github.com/wikimedia/mediawiki/blob/master/includes/skins/SkinMusta…>
and do away with the BaseTemplate class. This meant that we had to
deprecate various BaseTemplate hooks, providing more suitable generic
alternatives in the shared Skin.php layer. We also took the opportunity to
reduce the number of active hooks that operate in the skin layer for
developer sanity.
>From now on it is intended that any skin modifications are done *prior *to
rendering. The renderer whether it is BaseTemplate or SkinMustache will
simply render the data that's been provided.
As a result of this I have various changes to report!
The *SidebarBeforeOutput
<https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Hooks/SidebarBefor…>
*hook now can be used to modify the toolbox and languages portals.
Previously these sidebar menus had their own bespoke hooks.
The SkinTemplateBuildNavUrlsNav_urlsAfterPermalink hook
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateBuildNavUrlsNav_url…>
is deprecated and can be replaced with the new and improved
SidebarBeforeOutput hook.
The SkinTemplatePreventOtherActiveTabs and SkinTemplateTabAction hooks
<https://phabricator.wikimedia.org/T253814>were seldom used and replaced
with SkinTemplateNavigation::Universal .
All BaseTemplate hooks should now be considered deprecated per T253809
<https://phabricator.wikimedia.org/T253809>.
- BaseTemplateAfterPortlet
<https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateAfterPortlet>
is replaced with the template-rendering agnostic SkinAfterPortlet
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinAfterPortlet>
- SkinTemplateToolboxEnd
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateToolboxEnd>is
replaced with the new and improved version of SidebarBeforeOutput
- BaseTemplateToolbox
<https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateToolbox> is
replaced with the new and improved version of SidebarBeforeOutput
Finally a big one:
The SkinTemplateOutputPageBeforeExec hook is now deprecated
<https://phabricator.wikimedia.org/T60137>. Previously this hook could do a
lot of things and often in ways that were hard to reason with. For example,
previously this hook was used alongside other hooks to add items to the
footer and to override skin internals to display portals that were normally
hidden. We looked through all the use cases for this hook and are confident
we've caught the most confident use cases. Migration depends on what it was
previously used for but are documented on mediawiki.org
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateOutputPageBeforeExe…>.
It's possible there are other use cases, we missed and if so we plan to
cover those during the 1.36 release.
If you are an extension developer and have any questions about migration
please feel free to ping me on the associated Phabricator ticket or hook
talk page, we will be happy to improve the documentation and help you find
the right way to upgrade your code.
As we go into 1.36 we plan to make changes that simplify MediaWiki skin
development and make the ecosystem friendlier to frontend developers and
make skins easier to maintain. In fact, in future, it will be possible to
write skins without a single line of PHP. If you are excited or intrigued
by these changes and want to get involved in the conversations I urge you
to subscribe to our board.
<https://phabricator.wikimedia.org/project/board/4795/>
I'm particularly interested in hearing from developers who are keen to make
skins in the new ecosystem. Your input and creativity would be much
appreciated. Feel free to drop me a private mail or engage in open
conversations.
In addition to all the extension developers who helped review changes to
their hook contracts, I would like to especially thank the following people
for getting us to this landmark: Ammarpad, Timo, Volker and Mainframe98.
I'd like to give a specific shout out for Ammarpad who has been a huge
driving force here, preventing various bugs from occurring and swiftly
responding to many of the unexpected regressions that we encountered during
this work. We couldn't have done this without you!
Thanks for reading!
Jon
[Apologies for cross-posting]
Hi,
TL;DR: We will take our Gerrit instance at gerrit.wikimeda.org offline
on Saturday, 27th of June from 17:00--22:00 UTC (hopefully much
shorter) to upgrade to the latest Gerrit v3.2.2.
(10:00--15:00 San Francisco time, and 19:00--24:00 Central
European time)
---------------------------------
We're currently running Gerrit v2.15, which is no longer supported and
we will upgrade to Gerrit v3.2 on Saturday 27th of June. This new
version brings lots of improvements. The most noticeable change is
probably the UI overhaul. The (default) "old UI" gets removed and the
"new UI" has been completely revamped. It's much more modern looking
and easier to use. And it also became far more usable on mobile
phones. But the new version of course also comes with fixes and
additions around the ssh interface, and the HTTP API.
Since this is such a big upgrade, we want to give you a chance to look
at it beforehand. You can test at
https://gerrit-test.wikimedia.org/
It holds a copy of our Gerrit data as of 15th of June, and it runs the
new Gerrit v3.2.2. We'll keep tuning things there during this week, so
it might get an occasional restart. But look around and test the new
UI, the HTTP API, etc.
If you run into issues or discover bugs, please open tickets in
Phabricator and set the Gerrit 3.x upgrade task (T254158) as parent.
Note that this test Gerrit instance is already hooked up with our
Phabricator. If you upload / merge / abandon / etc changes with a
`Bug: Tnnnn` footer, you'll get comments on the corresponding tasks in
Gerrit. So please use our test task T775 for your experiments.
As everything, also this upgrade comes with a few downsides:
* The new UI no longer works on Internet Explorer (currently ~0.02% of
Gerrit's web requests).
Microsoft's Edge browser works though.
So if you are still using Internet Explorer, please consider switching
to a different browser.
* Users of git-review need to use at least version 1.27 (released
September 2018). Otherwise uploading changes will fail.
* Your git should be at least version 2.2.0 (released November 2014)
to take advantage of the new, much simpler commit-msg hook.
Keeping my fingers crossed for a painless update,
Christian with lots of helping hands from RelEng, and SRE
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2020-06): 328
Active Maniphest users (any activity) in (2020-06): 1092
Task authors in (2020-06): 586
Users who have closed tasks in (2020-06): 317
Projects which had at least one task moved from one column to another on
their workboard in (2020-06): 321
Tasks created in (2020-06): 2713
Tasks closed in (2020-06): 2646
Open and stalled tasks in total: 44758
* Only open tasks in total: 43741
* Only stalled tasks in total: 1017
Median age in days of open tasks by priority:
Unbreak now: 4
Needs Triage: 562
High: 929
Normal: 1262
Low: 1798
Lowest: 1811
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2020-06): 3
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Wed 01 Jul 2020 12:00:23 AM UTC)
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2020-06): 328
Active Maniphest users (any activity) in (2020-06): 1092
Task authors in (2020-06): 586
Users who have closed tasks in (2020-06): 317
Projects which had at least one task moved from one column to another on
their workboard in (2020-06): 321
Tasks created in (2020-06): 2713
Tasks closed in (2020-06): 2646
Open and stalled tasks in total: 44758
* Only open tasks in total: 43741
* Only stalled tasks in total: 1017
Median age in days of open tasks by priority:
Unbreak now: 4
Needs Triage: 562
High: 929
Normal: 1262
Low: 1798
Lowest: 1811
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2020-06): 3
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Wed 01 Jul 2020 12:00:22 AM UTC)