Hello,
I usually wouldn't bother people with my issues but I'm sorta desperate
here. This is about https://meet.wmcloud.org. WM Cloud jitsi instance. It's
on a bigram VM and on docker
<https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker>.
Users report that when using this "a session with three people today and it
was rather poor. Bad grainy video from my side even though I have 100 Mbps
both ways. After about 15 minutes the session froze and the other two
dropped out." or "we were 4 persons and it was very unstable (no screen
sharing). people's connection got lost, so they could often still hear but
could not participate in the call anymore." and you can reproduce the issue
too if you stay long enough in a meeting with another connection (your
phone for example).
I can't find any reason why this is happening. I wrote some of my
investigations here <https://phabricator.wikimedia.org/T268393> but we
checked the cloud's infra. CPU, memory, etc. all look fine as well as the
network throughput. It doesn't happen with a new VM but quickly (after one
meeting) builds up to have the same issues again. I added a regular restart
of the docker containers (it even destroys them and recreates them again,
also the docker service itself gets restarted) but nothing changes (maybe I
should add a restart of the network manager too?). I assume the iptables
being busy because of docker can contribute to the issue but not this much.
I'm running out of ideas. If anyone has worked with such setup and feels
comfortable debugging this, let me know and I give permission to check the
VM.
Thank you
--
Amir (he/him)
Hello all,
It's coming close to time for annual appointments of community members to
serve on the Code of Conduct (CoC) committee. The Code of Conduct Committee
is a team of five trusted individuals plus five auxiliary members with
diverse affiliations responsible for general enforcement of the Code of
conduct for Wikimedia technical spaces. Committee members are in charge of
processing complaints, discussing with the parties affected, agreeing on
resolutions, and following up on their enforcement. For more on their
duties and roles, see
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee
This is a call for community members interested in volunteering for
appointment to this committee. Volunteers serving in this role should be
experienced Wikimedians or have had experience serving in a similar
position before.
The current committee is doing the selection and will research and discuss
candidates. Six weeks before the beginning of the next Committee term,
meaning 9 April 2021, they will publish their candidate slate (a list of
candidates) on-wiki. The community can provide feedback on these
candidates, via private email to the group choosing the next Committee. The
feedback period will be two weeks. The current Committee will then either
finalize the slate, or update the candidate slate in response to concerns
raised. If the candidate slate changes, there will be another two week
feedback period covering the newly proposed members. After the selections
are finalized, there will be a training period, after which the new
Committee is appointed. The current Committee continues to serve until the
feedback, selection, and training process is complete.
If you are interested in serving on this committee or like to nominate a
candidate, please write an email to techconductcandidates AT wikimedia.org
with details of your experience on the projects, your thoughts on the code
of conduct and the committee and what you hope to bring to the role and
whether you have a preference in being auxiliary or constant member of the
committee. The committee consists of five members plus five auxiliary
members and they will serve for a year; all applications are appreciated
and will be carefully considered. The deadline for applications is the end
of day on 26 March 2021.
Please feel free to pass this invitation along to any users who you think
may be qualified and interested.
Best,
Amir on behalf of the CoC committee
Hello all,
The Wikimedia Foundation Board of Trustees is organizing a call for
feedback[1] about community selection processes between February 1 and
March 14. While the Wikimedia Foundation and the movement have grown about
five times in the past ten years, the Board’s structure and processes have
remained basically the same. As the Board is designed today, we have a
problem of capacity, performance, and lack of representation of the
movement’s diversity. Our current processes to select individual volunteer
and affiliate seats have some limitations. Direct elections tend to favor
candidates from the leading language communities, regardless of how
relevant their skills and experience might be in serving as a Board member,
or contributing to the ability of the Board to perform its specific
responsibilities. It is also a fact that the current processes have favored
volunteers from North America and Western Europe. In the upcoming months,
we need to renew three community seats and appoint three more community
members in the new seats. This call for feedback is to see what processes
can we all collaboratively design to promote and choose candidates that
represent our movement and are prepared with the experience, skills, and
insight to perform as trustees?
In this regard, two rounds of feedback meetings are being hosted to collect
feedback from the technical communities in Wikimedia. Two rounds are being
hosted with the same agenda, to accomodate people from various time zones
across the globe. We will be discussing ideas proposed by the Board and the
community to address the above mentioned problems. Please sign-up according
to whatever is most comfortable to you. You are welcome to participate in
both as well!
Round 1 - Feb 25, 4:00 pm UTC[2]
Round 2 - Mar 4, 4:00 am UTC[3]
Sign-up and meeting details:
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_of_Trustees/Call…
Please let me know if you have any questions.
Best,
Krishna Chaitanya
[1]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_of_Trustees/Call…
[2] https://zonestamp.toolforge.org/1614268826
[3] https://zonestamp.toolforge.org/1614830440
https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-02-24
=2021-02-24=
== Callouts ==
** Graphoid was undeployed unblocking the decomissoning of the scb cluster.
Many thanks to all those that contributed
** Sign up for the second 2021 frontend web performance training by
emailing Gilles. Monday April 19 until Friday April 23, from 13:00 until
16:30 UTC. 3 seats left!
** Production excellence monthly for Jan 2021 published:
https://phabricator.wikimedia.org/phame/post/view/227/production_excellence…
=== No updates ===
CommTech, Editing, Android
=== '''No notes provided''' ===
Prod Infra, Parsing, Language, Inuka, Analytics, Cloud Services, Platform,
Quality & Test,
== SoS Meeting Bookkeeping ==
* Updates:
** from retro ideas to try:
*** Bolding items to read aloud +JF +TC
*** relaxing the start time
*** Template
**** Perhaps add a contact point (email, url, office hours, whatever) for
easy reaching out to teams when a bullet point seems interesting. +GG +JF
+TC
== Product ==
=== Anti-Harassment Tools ===
* Blocked by:
* Blocking:
* Thank you:
* Updates:
** Deploying a new logging feature for SecurePoll to votewiki - logs when
Admins access private user data
=== Growth ===
* Blocked by:
* Blocking:
* Thank you:
** SRE and Search for their help with Add Link
* Updates:
** Work on Add Link continues https://wikitech.wikimedia.org/wiki/Add_Link
*** hoping to enable on Beta this week
*** opening up the mwaddlink service to external traffic
*** new CirrusSearch maintenance script UpdateWeightedTags for setting
things like ORES topics in a local dev environment
** Deploying GrowthExperiments to more wikis
** Improvements to mentorship, including a new {{#mentor}} keyword for
querying the name of the user's mentor
=== iOS native app ===
* Blocked by:
* Blocking:
* Thank you:
** Harry Marcus for upgrading our build machine while in the SF office
yesterday.
* Updates:
** No Updates
=== Web ===
* Blocked by:
* Blocking:
* Thank you:
** Peter Hedenskog (Performance) for his help in setting up the performance
monitoring for the WVUI search autocomplete widget (
https://phabricator.wikimedia.org/T251544 )
* Updates:
** Enabling the WVUI search autocomplete widget A/B test this week
** Continuing to work on moving and instrumenting the language button in
Vector V2
=== Structured Data ===
* Blocked by:
* Blocking:
* Thank you:
* Updates:
** Publicly announced our intention to make Special:MediaSearch the default
search experience on Wikimedia Commons:
https://commons.wikimedia.org/wiki/Commons:Village_pump#Moving_toward_Speci…
** Building a tool for manual testing of image recommendations (
https://phabricator.wikimedia.org/T273062 )
** Evaluating the effects of adding the aliases of Wikidata items related
to the search term to the search query (
https://phabricator.wikimedia.org/T258053 )
** Adding edit tags for multimedia edits to Wikipedia articles (
https://phabricator.wikimedia.org/T266067 )
** Continuing to instrument events on Special:MediaSearch
=== Abstract Wikipedia ===
* Blocked by:
** None.
* Blocking:
** None known.
* Thank you:
** Thanks to Timo Tijhof from Performance for their support and advice.
* Updates:
** Continuing on phase gamma:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases
** Working with SRE on load estimations for next year, such fun.
** Logo concept vote for Wikifunctions will start soon:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wikifunctions_logo_conce…
=== Library ===
* Blocked by:
* Blocking:
* Thank you:
** Amir for helping improve our translatable messages in The Wikipedia
Library
* Updates:
** Reviewing external PRs made by external volunteers
** Minor fix in our GlitchTip environments
** Working on installation of MediaWiki dev environment (Vagrant) to start
work on TheWikipediaLibrary extension
*** Got some errors on installing GlobalPreferences, found a bug and will
create a patch to fix it soon
*** Still getting errors when trying to install Echo – Error:
/usr/local/bin/mwscript createAndPromote.php
--wiki='wiki' 'Selenium Echo user b' 'vagrant' returned 255 instead of one
of [0] Need some help on this
*** JamesF Advice: run composer update manually and try again
*** Thcipriani: ask in #wikimedia-releng IRC if that doesn't work
=== Vue.js ===
* Blocked by:
** Performance on code review of
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657953 and
https://gerrit.wikimedia.org/r/c/mediawiki/libs/Minify/+/664700
** Fundraising Tech on code review of
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/663946
* Blocking:
* Thank you:
* Updates:
** ES6 support in ResourceLoader is "done", waiting for code review (see
above)
** Vue migration team will take over the maintenance of WVUI
** We will aim to consolidate different component implementations that have
been developed across WMF teams into a single set of components (not a
complete OOUI replacement but hopefully enough to be useful) over the next
few months
** Vue migration team and WMDE will continue to share notes on their
respective component projects in hopes of finding ways to converge our
efforts in the coming quarters
** We are exploring upgrading WVUI to Vue 3 in the short term (before more
components are introduced), also exploring alternative build tools (notably
Vite)
*** Initial proposal for a Vue 2->3 migration shim here:
https://phabricator.wikimedia.org/T251974#6854561
== Technology ==
=== Fundraising Tech ===
* Blocked by:
* Blocking:
** VueJS folks - we'll take a look at
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/663946
pronto
* Thank you:
** RelEng for review on our docker dev environment
* Updates:
** Working on donor email preference center (
https://phabricator.wikimedia.org/T268495,
https://phabricator.wikimedia.org/T268497)
** Annual PCI paperwork to keep accepting credit cards
** Trying to get Latin American Spanish (es-419) working as a variant
throughout donation pipeline, falling back to Castillian Spanish. Have a
hook-based way to get this on payments-wiki, looking for a config-only way
to get it on donatewiki. (https://phabricator.wikimedia.org/T199682,
https://phabricator.wikimedia.org/T199733)
** More fixes for our docker setup (
https://phabricator.wikimedia.org/T274943,
https://phabricator.wikimedia.org/T268683) (thanks RelEng for review!)
=== Engineering Productivity ===
==== Performance ====
* Blocked by:
* Blocking:
* Thank you:
* Updates:
** Migrating web perf alerts to new alerts pipeline
==== Release Engineering ====
* Blocked by:
**
* Blocking:
**
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** [https://versions.toolforge.org/ Train Health]
*** Last week: 1.36.0-wmf.31 [[phab:T271344]] <!--
https://phabricator.wikimedia.org/T271345 -->
*** This week: 1.36.0-wmf.32 [[phab:T274936]] <!--
https://phabricator.wikimedia.org/T274936 -->
*** Last week: 1.36.0-wmf.33 [[phab:T274937]] <!--
https://phabricator.wikimedia.org/T274937 -->
* Thanks
** Serviceops for unsticking VMs for GitLab
** Moritz, jbond, godog for input on GitLab things
** Timo for production excellence
=== Search Platform ===
* Blocked by:
* Blocking:
* Thank you:
* Updates:
** Remove dependency on Maven for CI for Java projects and align Jenkins
job configuration. -https://phabricator.wikimedia.org/T271541
** WDQS Flink based Updater - Create pipelines for late/spurious/failed
events -https://phabricator.wikimedia.org/T269619
=== Security ===
* Blocked by:
** None
* Blocking:
* Thank you:
** All, for patience and understanding as we work through resourcing
challenges.
* Updates:
** Risk Management @ Office Hours 2/25. See Staff Calendar! Risk Owners
should try to join.
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Thank you:
** Growth for an excellent experience while deploying AddLink
* Updates:
** Graphoid was undeployed unblocking the decomissoning of the scb cluster.
Many thanks to all those that contributed
** Myanmar blockage, see
https://lists.wikimedia.org/pipermail/wikimedia-l/2021-February/096264.html
** Some issues with upload @ eqsin
=== WMDE Technical Wishes ===
* Updates:
** Syntax highlighter bracket matching is going out to additional pilot
wikis on March 1st, including wikitech and mediawiki.org -
https://phabricator.wikimedia.org/T273591
** All of our event schemas are migrated to the new platform now.
** Considering attempting a Vue prototype in the Popups extension.
*** Feedback: Moriel did this as a demo already, in React and Vue. Ed S.
would like to see us make it extendable.
== Cross-cutting ==
* Blocked by:
** Search Platform: PHP 8.0 work is long-term blocked on the migration to
ElasticSearch 7.0 https://phabricator.wikimedia.org/T263142
* Blocking:
** None
* Thank you:
** Thanks again to Umherirrender for their on-going work on the backlog of
jsonlint -> eslint replacements https://phabricator.wikimedia.org/T220036
* Updates:
** No significant movement.
** On PHP 8.0 work, we're now looking to enable PHP 8.0 as voting on the
REL1_35 branch for MediaWiki itself and as a gradual opt-in for extensions.
https://phabricator.wikimedia.org/T274965
** CI tools' upgrade status is adequate:
https://libraryupgrader2.wmcloud.org/status?branch=master
On Tue, Feb 23, 2021 at 4:55 PM Galder Gonzalez Larrañaga <
galder158(a)hotmail.com> wrote:
> Great news! I have tried today I couldn't upload a file, does it take some
> time to upload or is there a queue?
>
Hi Galder Gonzalez Larrañaga!
The videos which are present in the devices have to get uploaded to the
server and then processed for the editings, So this might take some time to
get upload and then processed. The uploading video time will depend on the
internet speed, the size, and the length of the video.
If you notice the same again i.e if your video didn't get upload, please
feel free to create a ticket here:
https://phabricator.wikimedia.org/tag/videocuttool/ so we can see how we
can avoid them :-)
Thanks & Regards
Gopa Vasanth <https://www.mediawiki.org/wiki/User:Gopavasanth>
Amrita Vishwa Vidyapeetham <http://www.amrita.edu/> | Blog
<https://gopavasanth.wordpress.com/>
amFOSS <https://amfoss.in/@gopavasanth> | GitHub
<https://github.com/gopavasanth> | Gerrit
<https://gerrit.wikimedia.org/r/#/q/gopavasanth>
“Yesterday is not ours to recover, but tomorrow is ours to win or lose.”
Hi,
I would like to uhhh... start the discussion? ask for opinions? about the
future of UploadWizard.
It is a rather special extension, that was from the start made mostly for
Commons' very specific needs and getting it to work anywhere else presents
some challenges (some of which I attempt to tackle here
<https://phabricator.wikimedia.org/T256616>). Interestingly, it still is
used by many third-party wikis
<https://wikiapiary.com/wiki/Extension:Upload_Wizard> and although some of
them don't need its full set of capabilities related to describing
licenses, authors and sources, there are wikis that do need that. The wiki
I maintain, Nonsensopedia, has a Commons-like file description system based
on Semantic MediaWiki (see example here
<https://nonsa.pl/wiki/Plik:Creative_Commons_evolution.jpg>) and
UploadWizard has been a *blessing* for us, greatly simplifying the task of
file moderation.
Opinion time: Wikis should be *encouraged* to properly describe the
authorship of files that they use, to meet the licensing requirements. IMO
Wikimedia Foundation as the maintainer of MediaWiki and a foundation
dedicated to dissemination of free culture should provide a usable tool for
properly describing free multimedia. UploadWizard could be just that.
At the same time, the extension has been basically unmaintained
<https://phabricator.wikimedia.org/T261589#6674315> since the Multimedia
team was dissolved and I've been rather surprised to discover that patches
improving third-party support were met with uhm... very limited enthusiasm?
<https://phabricator.wikimedia.org/T256616#6264584> There are a few obvious
features lacking like mobile support (seriously, try opening
https://commons.wikimedia.org/wiki/Special:UploadWizard on a narrow screen
device, it's been like this since.. always) and configurability (you have
to jump through some serious hoops
<https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl> to just add a
license; customizing the tutorial is similarly hard).
I've been thinking of what to do with the above and I really wouldn't want
to embark on something that will be rendered redundant or obsolete in a
year, so my question is: are there any plans for UploadWizard? What makes
me suspect that things may change is primarily Structured Data on Wikimedia
Commons, which in the future will maybe (?) supersede the description
system around the {{Information}} template. Are there any rough roadmaps or
outlines of anything resembling a plan for that? If Commons was to
implement full, structured file descriptions in the upload tool, that code
would be probably hardly usable outside Commons, given that Wikibase is not
something easy to install or maintain, it is also awfully overkill for the
vast majority of applications. In such a situation, would it make sense to
consider completely separating the "Wikimedia Commons Shiny Upload Tool"
from a more general extension that would be usable for third
parties, stripped of any Commons-specific code? A lot of things could be
much simplified if the extension was to target just the needs of third
parties and not Commons.
I ask about this because I really don't see any sort of interest of the
extension's *de facto* owner (and that is WMF) in developing it, there are
also no public plans for it, as far as I know. Yes, I can make a fork
anytime, but first I'd prefer to know if I'm not missing something. Well,
actually, I already did make a fork of UW
<https://gitlab.com/nonsensopedia/extension-forks/uploadwizard-nonsa> over
a year ago, but this particular version of it is tailored for a wiki I
manage, making it useless for others. At the time that was the only
reasonable way we could get a good upload tool that was capable of properly
describing licensing information. I probably don't have to tell seasoned
open-source developers why this type of approach is not optimal for the
future of the project. :)
Any opinions on the topic are very welcome.
--
Ostrzyciel (he/him)
How’d we do in our strive for operational excellence last month? Read on to
find out!
Read on Phabricator at https://phabricator.wikimedia.org/phame/post/view/227
📈 Incidents
1 documented incident last month. That's the third month in a row that we
are at or near zero major incidents – not bad! [1] [2]
Learn about recent incidents at Incident status
<https://wikitech.wikimedia.org/wiki/Incident_status> on Wikitech, or
Preventive
measures <https://phabricator.wikimedia.org/project/view/4758/> in Phabric
ator.
💡 *Did you know: Our Incident status
<https://wikitech.wikimedia.org/wiki/Incident_status> page provides a
green-yellow status reflection over the past ten days, with a link to the
most recent incident doc if there was any during that time.*
-------
📊 Trends
This January saw a small recovery in our otherwise negative upward trend.
For the first time in twelve month more reports were closed than new
reports having outlived the previous month without resolution. What
happened twelve months ago? That January 2020, which also saw a small
recovery during the otherwise upward trend before and after it.
Perhaps its something about the post-December holidays that temporarily
improves the quality and/or reduces the quantity — of code changes. Only
time will tell if this is the start of a new trend, or merely a
post-holiday dip. [3]
While our month-to-month trend might not (yet) be improving, we do see
persistent improvements in our overall backlog of pre-2019 reports. This is
in part because generally don't file new reports there, so it makes sense
that it doesn't go up, but it's still good to see downward progress every
month, unlike with reports from more recent months which often see no
change month-to-month (see "Outstanding errors" below, for example).
This positive trend on our "Old" backlog started in October 2020 and has
consistently progressed every month since then (refer to the "Old" numbers
in red on the below chart, or the same column in the spreadsheet
<https://docs.google.com/spreadsheets/d/1tRCh8aB0UYyLlhftvcHvhWH4-e7cF5V01Xv…>.
[3][4]
Figure 1, Figure 2: Unresolved error reports stacked by month.
<https://phabricator.wikimedia.org/phame/post/view/227/production_excellence…>
-------
📖 Outstanding errors
Summary over recent months:
- ⚠️ July 2019 (2 of 18 issues left): *no change*.
- ⚠️ August 2019 (1 of 14 issues): *no change*.
- ✅ September 2019 (0 of 12 issues): Last two tasks were resolved (-2).
- ⚠️ October 2019 (4 of 12 issues): One task resolved (-1).
- ⚠️ November 2019 (1 of 5 issues): *no change*.
- ⚠️ December 2019 (2 of 9 issues), Two tasks resolved (-2).
- ⚠️ January 2020 (2 of 7 issues), no change.
- ⚠️ February 2020 (1 of 7 issues left), One task resolved (-1).
- March 2020 (2 of 2 issues left), no change.
- April 2020 (9 of 14 issues left): *no change*.
- May 2020 (6 of 14 issues left): One task resolved (-1).
- June 2020 (7 of 14 issues left): *no change*.
- July 2020 (9 of 24 new issues
<https://phabricator.wikimedia.org/maniphest/query/s__D8Kd0xuQH/#R>): *no
change*.
- August 2020 (22 of 53 new issues
<https://phabricator.wikimedia.org/maniphest/query/hu1yhWu4sXkP/#R>):
One task resolved (-1).
- September 2020 (13 of 33 new issues
<https://phabricator.wikimedia.org/maniphest/query/CGFQViLShnOY/#R>):
One task resolved (-1).
- October 2020 (31 of 69 new issues
<https://phabricator.wikimedia.org/maniphest/query/MYnnBybPTYpd/#R>):
Four tasks fixed (-4).
- November 2020 (14 of 38 new issues
<https://phabricator.wikimedia.org/maniphest/query/CkC_VqQq5VC0/#R>): *no
change*.
- December 2020 (19 of 33 new issues
<https://phabricator.wikimedia.org/maniphest/query/10NQy74iKaZJ/#R>)
Three tasks resolved (-3)
- *January 2021*: 7 of 50 new issues
<https://phabricator.wikimedia.org/maniphest/query/WIP9W8q54HB6/#R>
survived the month and remained unresolved (+50; -43)
Recent tally
160 issues open, as of Excellence #27
<https://phabricator.wikimedia.org/phame/post/view/219/production_excellence…>
(4 Feb 2021).
-15 issues closed since, of the previous 160 open issues.
+7 new issues that survived January 2021.
152 issues open, as of today (16 Feb 2021).
January saw +50 new production errors reported in a single month, which is
an unfortunate all-time high. However, we've also done remarkably well on
addressing 43 of them within a month, when the potential root cause and
diagnostics data are still fresh in our minds. Well done!
For the on-going month of February, there have been 16 new issues
<https://phabricator.wikimedia.org/maniphest/query/xjFr73QLJYlE/#R>
reported so far.
Take a look at the workboard
<https://phabricator.wikimedia.org/tag/wikimedia-production-error/> and
look for tasks that could use your help!
-------
🎉 Thanks!
Thank you to everyone else who helped by reporting, investigating, or
resolving problems in Wikimedia production. Thanks!
Until next time,
– Timo Tijhof
-------
Footnotes:
[1] Incident status Wikitech
<https://wikitech.wikimedia.org/wiki/Incident_status>.
[2] Wikimedia incident stats by Krinkle, CodePen
<https://codepen.io/Krinkle/full/wbYMZK>.
[3] Month-over-month, Production Excellence spreadsheet
<https://docs.google.com/spreadsheets/d/1tRCh8aB0UYyLlhftvcHvhWH4-e7cF5V01Xv…>
.
[4] Open tasks, Wikimedia-prod-error, Phabricator
<https://phabricator.wikimedia.org/maniphest/query/Fw3RdXt1Sdxp/#R>.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-02-17
=2021-02-17=
== Callouts ==
* RelEng: Longer-term train disruption calendar (caveats apply)
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
=== No updates ===
AHT, Library
=== '''No notes provided''' ===
Web, Prod Infrastructure, Parsing, Language, Inuka, Analytics, Cloud
Services, Platform, Quality & Test, Security
== SoS Meeting Bookkeeping ==
*Updates:
** from retro ideas to try:
*** Bolding items to read aloud +JF +TC
*** relaxing the start time
*** Template
**** Perhaps add a contact point (email, url, office hours, whatever) for
easy reaching out to teams when a bullet point seems interesting. +GG +JF
+TC
**** Adding a section where teams can add Gerrit patches or GitHub Pull
Requests to request reviews or feedback. +GG +TC [DONE]
**** Adding a "thanks" section +GG +JF +TC+AP [DONE]
== Product ==
=== Community Tech ===
* Blocked by:
* Blocking:
* Updates:
** We are now preparing for our next project (OCR Improvements) while
wrapping up our work on WS-Export improvements
***
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2020/Wikisource/N…
***
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Wikisource/I…
=== Editing ===
* Blocked by:
* Blocking:
* Updates:
** Releasing new topic tool as a Beta Feature on three Wikipedias (ar/cs/hu)
=== Growth ===
* Blocked by:
* Blocking:
* Updates:
** working on Add Link https://wikitech.wikimedia.org/wiki/Add_Link
** working on improvements in configuration (for more scalable deployments)
and mentorship
=== iOS native app ===
* Blocked by: None
* Blocking: I hope none.
* Updates: Finishing touches on Chinese varient work, bunches of other
small things.
=== Android native app ===
* Blocked by: None
* Blocking: I hope none.
* Updates: Refining watchlist and talk pages, moving to releasing every 2
weeks.
=== Structured Data ===
* Blocked by:
* Blocking:
* Updates:
** MediaSearch: splitting off frontend into separate extension
** Image recommendations: started working on scripts to evaluate POC
results (T273882, T273062) & tweak search profile based on analysis from
Research team (T271799)
** Continuing SDAW architecture discussions
=== Abstract Wikipedia ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Continuing on phase gamma:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases
*** First route for back-end executor service has landed.
*** Looking at re-using firejail for isolation of run-times within executor
service.
** Thanks to Dave Pifke and Timo Tijhof from Performance for their support
and advice.
** Final week for community suggestions for the logo concept for
Wikifunctions:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wikifunctions_logo_conce…
=== Vue.js ===
* Blocked by: Performance (Timo), review of
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657953
* Blocking:
* Updates:
** WVUI v0.1.0 merged into core, yay! Thank you to Jon R, Jan D, Nick R,
Sam S, Mark H (Web team), Scott B (Security), and Timo T (Performance)
** Patch for ES6-only module support in ResourceLoader awaiting review
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657953
** New patch up (as of last night) adding ES6 support to JavaScriptMinifier
https://gerrit.wikimedia.org/r/c/mediawiki/libs/Minify/+/664700
*** Thanks to Timo for setting up the mediawiki/libs/Minify repo
== Technology ==
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Working on donor email preference center (
https://phabricator.wikimedia.org/T268495,
https://phabricator.wikimedia.org/T268497)
** Annual PCI paperwork to keep accepting credit cards
** Trying to get Latin American spanish (es-419) working as a variant
throughout donation pipeline, falling back to Castillian Spanish (
https://phabricator.wikimedia.org/T199682,
https://phabricator.wikimedia.org/T199733)
** More fixes for our docker setup (
https://phabricator.wikimedia.org/T274943,
https://phabricator.wikimedia.org/T268683) (will need +2s from RelEng
eventually)
=== Engineering Productivity ===
==== Performance ====
* Blocked by:
* Blocking:
* Updates:
** Second frontend web perf training session budget approved, will be at
EMEA-friendly times. Provisional dates April 19 - 23
==== Release Engineering ====
* Blocked by:
** ServiceOps: [https://phabricator.wikimedia.org/T274459 VM requests for
GitLab]
* Blocking:
** Hopefully no longer blocking fundraising
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** Longer-term train calendar
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
** Train Health
*** Last week: 1.36.0-wmf.30 [[phab:T271343]] <!--
https://phabricator.wikimedia.org/T271344 -->
*** This week: 1.36.0-wmf.31 [[phab:T271344]] <!--
https://phabricator.wikimedia.org/T271345 -->
*** Next week: 1.36.0-wmf.32 [[phab:T274936]] <!--
https://phabricator.wikimedia.org/T274936 -->
== Thanks ==
* Serviceops: [https://phabricator.wikimedia.org/T274306 docker-pkg help]!
* Everyone who helped us get the train unstuck over the past few weeks <3
=== Search Platform ===
* Blocked by:
* Updates:
** Outdated data still present in WCQS a month after statement update -
https://phabricator.wikimedia.org/T267825
** Resolve WDQS changelog situation -
https://phabricator.wikimedia.org/T272265
** Reduce default page weighting on wikitech and mediawikiwiki for pages
with "Historical" or "Archive"templates -
https://phabricator.wikimedia.org/T274082
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Working with Product Infra on maps
** Having some issues with upload edge caches recently
** Some SREs alongside Chris Albon made it to mainstream news for
https://phabricator.wikimedia.org/T273741
== WMDE ==
=== Technical Wishes ===
* Updates:
** Finishing a round of intensive analytics work, thanks for all the review
and support.
** Planning many changes in the Visual Editor template dialog.
== Cross-cutting ==
* Blocked by:
** Search Platform: PHP 8.0 work is long-term blocked on the migration to
ElasticSearch 7.0 https://phabricator.wikimedia.org/T263142
* Blocking:
** None
* Updates:
** No major changes.
** On PHP 8.0 work, we're now looking to enable PHP 8.0 as voting on the
REL1_35 branch for MediaWiki itself and as a gradual opt-in for extensions.
https://phabricator.wikimedia.org/T274965
** CI tools' upgrade status is adequate:
https://libraryupgrader2.wmcloud.org/status?branch=master
** Particular thanks this week to Umherirrender for their work on the
backlog of jsonlint -> eslint replacements
https://phabricator.wikimedia.org/T220036
Thad,
Thank you for the information about schema.org with respect to ClaimReview<https://schema.org/ClaimReview>.
A point of disagreement with that schema.org model is the ratings system concept (x out of N). Instead, for discussion, I prefer a more annotational approach for fact checking with typed annotations produced and consumed by both humans and software tools. That is, I prefer the concept of an informational message, warning, error system for fact checking resembling software IDE’s. Such a model is intuitive, can be readily formalized, made machine-utilizable, and typed annotations – informational messages, warnings, and errors – can be merged from multiple sources or service providers.
Best regards,
Adam
P.S.: As interesting, a new W3C Community Group is launching on the topic of document services. The group intends to discuss and make new architecture and API to facilitate: spellchecking, grammar checking, proofreading, fact checking, mathematical proof checking, reasoning checking, argumentation checking, and narrative checking. If the group interests you, please do feel free to support the creation of the group: https://www.w3.org/community/groups/proposed/#services .
From: Thad Guidry<mailto:thadguidry@gmail.com>
Sent: Friday, February 5, 2021 3:12 PM
To: Discussion list for the Wikidata project<mailto:wikidata@lists.wikimedia.org>
Cc: wikitech-l(a)lists.wikimedia.org<mailto:wikitech-l@lists.wikimedia.org>; Wikispore experimental project<mailto:wikispore@lists.wikimedia.org>
Subject: Re: [Wikidata] [Wikimedia-l] Idea of a new project: Wikifacts ?
Oops, the better link for the Schema.org work to support fact checking (some even still in progress after 3 years) probably should have been this: http://blog.schema.org/2017/08/schemaorg-33-news-fact-checking.html
Thad
https://www.linkedin.com/in/thadguidry/https://calendly.com/thadguidry/
