Hi,
I'm Fabrice, new to the organization. I heard of gsoc very late but still
decided to give it a try. I don't know much on how/where to communicate
with members of the organization. I'll be really grateful if someone could
help me out.🙏
All,
Ahead of the release of MediaWiki 1.35.0, a number of people have been
working to make sure that MediaWiki is compatible with PHP 7.4.[0] We have
now reached the final phase of that work, where we are checking that we
don't regress in CI. This is running on the master branch, as REL1_34 is
not compatible.
To that end, * Wikimedia CI is now running PHP 7.4 as voting* for almost
all PHP code. This covers MediaWiki core, most extensions, skins, and
libraries. PHP74 jobs will appear in the 'gate-and-submit' and 'php'
pipelines for your projects.
If your code works in PHP 7.3 but not in PHP 7.4, it will now fail. Most of
the changes are documented in PHP's migration guidance.[1] Note that this
is rare; almost all PHP 7.2- and 7.3-compatible code works fine in PHP 7.4.
There are a few extensions which are known to not yet be PHP
7.4-compatible, and so currently aren't running PHP74 tests yet; others
will probably exist. I've spot-checked a few dozen projects, and fixed
several issues, but it is likely that I have missed some; we have well over
a thousand repos, after all.
If your repo is broken by this change and needs the PHP 7.4 testing
temporarily removed, please file a task on the workboard[2] and I'll be
happy to get it fixed.
Thank you to everyone who has worked on this.
[0] - https://phabricator.wikimedia.org/T233012
[1] - https://www.php.net/manual/en/migration74.php
[2] - https://phabricator.wikimedia.org/tag/php_7.4_support/
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
The 1.35.0-wmf.23 version of MediaWiki is blocked[0].
The new version can't proceed to group2 [1] until these issues are
resolved, and may be rolled back to group0 if necessary:
* T247458 PHP Notice: Undefined index: wgKartographerLiveData
- https://phabricator.wikimedia.org/T247458
* T247466 SimpleCacheWithBagOStuff: Cache key contains characters that
are not allowed
- https://phabricator.wikimedia.org/T247466
* T247484 Lots of "EventBus: Unable to deliver all events"
- https://phabricator.wikimedia.org/T247484
If all issues are resolved before 15:00 PST, the train can resume today,
otherwise the train will resume Monday, March 16th at the earliest.
Thank you for your help resolving these issues!
-- Your harried train functionary
[0]. <https://phabricator.wikimedia.org/T233871>
[1]. <https://tools.wmflabs.org/versions/>
Hi all!
TL;DR: A new policy defining stable interfaces for use by extensions, and the
deprecation process that must be followed when changing such stable interfaces,
is now in the Last Call period. If no concerns remain unaddressed by March 11,
the new policy will be adopted as official policy. The policy will apply to
MediaWiki 1.35 and later.
The new policy is designed to better protect extensions from breakage when
things change in core, by being more restrictive about what extensions can
safely do.
Draft document: https://www.mediawiki.org/wiki/Stable_interface_policy
RFC ticket: https://phabricator.wikimedia.org/T193613
Please comment there. Read below for a summary of changes.
Long version:
TechCom has been working on a Stable Interface Policy for MediaWiki's PHP code
for a while[1]. Previously, the definition of the stable interface that can be
used by extensions was part of the Deprecation Policy[2]. The new policy[3] is
much more detailed and explicit about what extensions can expect to remain
stable and follow the deprecation process, and which things can change without
notice.
The introduction of the new policy is driven by problems we found while trying
to refactor core code with the aim to reduce coupling. For instance, when
following the Dependency Injection pattern, the constructor of service classes
is technically public, but is not stable for use outside the module.
The solution is to be more explicit about different kinds of stability (e.g.
whether a method is stable for callers, or can also be safely overwritten).
To allow us more freedom to restructure the source code, the new policy is more
restrictive with respect to what extensions can expect to be able to do safely
(e.g. subclass core classes). This is balanced by improved guarantees in
previously unspecified cases (e.g. stability of protected methods).
The new policy specifies different kinds of stability, establishes defaults for
different parts of the code, and defines new annotations to be used in the
documentation. Once the policy has been adopted, these annotations are soon to
be added to the code.
This will hopefully allow us to more quickly improve the structure and quality
of core code, and reduce the risk of breaking extensions in the future.
Summary of the new policy:
For extension authors:
* It's generally safe to call public methods, and to access public fields in
classes defined by MediaWiki core, unless these methods are documented to be
unsafe (e.g. annotated as @deprecated, @unstable, or @internal).
* It's generally unsafe to extend (subclass) classes or implement interfaces
defined by MediaWiki core, unless that class or interface was marked as @stable
for subclassing or @stable for implementation, respectively. In particular, the
constructor signature may change without notice, and abstract methods may be
added to interfaces.
* It's generally unsafe to directly instantiate (using new) classes defined by
MediaWiki core, unless that class is marked as @newable.
* It's generally unsafe to rely on global variables from MediaWiki core. Use
methods such as MediaWikiServices::getInstance() or
MediaWikiServices::getMainConfig() instead.
When changing existing code:
* Keep public methods and hook signatures backwards compatible for callers.
Follow the deprecation process when removing them.
* Keep constructor signatures backwards compatible if the constructor was marked
@stable for calling.
* Ensure compatibility of method signatures for code that overrides them if they
are marked @stable for overriding.
* Do not add abstract methods to classes or interfaces marked as @stable for
subclassing or @stable for implementation.
When defining extension points:
* When defining hooks, keep the signature minimal, and expose narrow interfaces,
ideally only pure value objects.
* When defining an interface to be implemented by extensions, provide a base
class, and mark it as @stable for subclassing.
* Discourage extensions from directly implementing interfaces by marking them as
@unstable for implementation. If direct implementation is to be allowed, mark
the interface @stable for implementation.
Notable changes from the 1.34 policy:
* Public methods are per default considered stable only for calling, not for
overriding.
* Constructors are considered unstable per default.
* Classes and interfaces are considered unstable for subclassing and
implementation, unless documented otherwise.
* Code not used in a public repository that is part of the Wikimedia ecosystem
may be changed or removed without deprecation.
[1] https://phabricator.wikimedia.org/T193613
[2] https://www.mediawiki.org/wiki/Deprecation_policy
[3] https://www.mediawiki.org/wiki/Stable_interface_policy
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Hi,
for HTML version see
https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-03-11
Željko
--
= 2020-03-11 =
== Callouts ==
* Release Engineering
** [All] MediaWiki 1.35.0 will get cut on 7 April 2020. If your team has
any proposed blockers/deadlines for that, please get them done:
[[phab:tag/MW-1.35-release]]
** [All] Beta Cluster Parsoid service is not currently working; sorry! Work
underway to fix this in [[phab:T246833]].
== SoS Meeting Bookkeeping ==
* Updates:
** sent e-mail reminder about the meeting to Foundation Optional mailing
list [[phab:T245278]]
== Product ==
=== Community Tech ===
* Updates:
** we're still focusing on the back-end work for watchlist expiry. we're
fixing a long-standing security issue with password resets (an issue before
our changes). we are collecting feedback on the project talk page for
section name in diff. early stages of research for the 'ebook export
improvement project,' and she hopes to work on that project page next.
=== Anti-Harassment Tools ===
* Updates:
** Working on checkuser. User interviews completed (summary coming soon).
=== Editing ===
* Updates:
** DiscussionTools:
*** parser: Detect comments transcluded from another page (task
[[phab:T245694]])
*** Fix signatureRanges overlapping for some comments
*** Wrap reply link in container so it may contain more links in future
*** Move wikitext comment building to the controller
*** parser: Return signature and timestamp ranges (task [[phab:T245220]])
*** Only allow opening one reply widget at once (on IE 11)
*** controller: apply ve.fixBase to the parsed Parsoid response (task
[[phab:T245781]])
*** Add reply links at the end of a line, even if the signature is in the
middle (task [[phab:T245695]])
=== Growth ===
* Updates:
** Newcomer tasks 1.1 (topic matching)
*** We deployed ORES topic models to Arabic, Vietnamese, and Czech
Wikipedias on 2020-03-05. Korean Wikipedian's models had some issues that
are causing its deployment to be delayed.
*** In the coming weeks, we'll be publishing some information about how
other Wikimedians and developers can access these models for their own
work. As an example, one way to use them is with the "articletopic" search
keyword. This works by typing something like "articletopic:sports" in a
Wikipedia search bar to retrieve articles that are likely to be about
sports. This page and links from it show the 64 possible topics to search.
** Newcomer tasks 1.2 (guidance): Engineering continues on this project.
=== iOS native app ===
* Updates:
** Wrapping up development on 6.6 release (mobile-html integration)
[[phab:project/view/4273]]
=== Android native app ===
* Updates:
** Final updates and testing of mobile html integration
** Final testing of Image tagging Suggested edits feature.
=== Web ===
* Updates:
** Summary: continuing desktop improvements (DIP).
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project (Vector
/ DIP)]]:
*** [[phab:T246296|<nowiki>Responsive monobook preference should be listed
under a section "Monobook preferences" a la Vector</nowiki>]]
*** [[phab:T245456|<nowiki>[Dev] Adopt template partials in Vector and
revise sidebar component</nowiki>]]
*** [[phab:T244481|<nowiki>Provide basic FeatureManagement in Vector
codebase</nowiki>]]
*** [[phab:T243281|<nowiki>Build opt-out link for logged-in users with new
vector on</nowiki>]]
*** [[phab:T242381|<nowiki>Add a Vector skin version preference</nowiki>]]
*** [[phab:T113095|<nowiki>A cached server-side HTML template should update
when you change a partial template which it includes</nowiki>]]
*** [[phab:T245793|<nowiki>[Firefox 73] Infusing a RadioOptionWidget
changes first-child alignment</nowiki>]]
*** [[phab:T242177|<nowiki>Technical: Deprecate mediawiki.legacy modules in
favor of ResourceLoaderSkinModule</nowiki>]]
*** [[phab:T239262|<nowiki>Type check JavaScript documentation</nowiki>]]
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T245160|<nowiki>[Bug] Many MobileFormatter lead paragraph
transform alerts starting on Feb 11, 2020</nowiki>]]
*** [[phab:T244106|<nowiki>[M] Setup storybook for all Minerva
components</nowiki>]]
=== Product Infrastructure ===
* Updates:
** Push notification discussions continue
== Technology ==
=== Fundraising Tech ===
* Updates:
** Deployed recurring donations for backup card processor, testing them
out: [[phab:T242278]]
** Working on NL bank transfers (iDEAL) for backup processor:
[[phab:T246819]]
** More performance optimizations for CiviCRM: [[phab:T241688]]
** Still working on CentralNotice features for sub-national targeting,
reviewing contractor work on
=== Core Platform ===
* Blocking:
** Search: MW Job consumers sometimes pause for several minutes
[[phab:T224425]]
* Updates:
** Hooks interface
** Core REST API
=== Engineering Productivity ===
==== Release Engineering ====
* Blocking:
** [All] Beta Cluster Parsoid service is not currently working; sorry! Work
underway to fix this in [[phab:T246833]].
* Updates:
** [All] MediaWiki 1.35.0 will get cut on 7 April 2020. If your team has
any proposed blockers/deadlines for that, please get them done:
[[phab:tag/MW-1.35-release]]
** Train Health
*** This week: 1.35.0-wmf.23 - [[phab:T233871]]
*** Next week: 1.35.0-wmf.24 - [[phab:T233872]]
=== Search Platform ===
* Blocked by:
** Core: MW Job consumers sometimes pause for several minutes
[[phab:T224425]]
* Updates:
** new elasticsearch servers now in production - [[phab:T246975]]
** Add "source" to A/B test schema for DYM suggestions - [[phab:T238246]]
** Search input box does not contain identification label - [[phab:T246303]]
=== Site Reliability Engineering ===
* Blocking:
** Product infrastructure for creation of kubernetes namespaces tokens for
proton, mobileapps
** Research on recommendation-api chart
* Updates:
** Changeprop first staging deploy by CPT
Hello, I’m a web developer currently working with the Research Team in developing a new Template for Research Sub-Programs to be hosted on Meta, using the TemplateStyles extension.
I’ve never edited something on Wiki before but I’ve managed to create my user page, and build a sub-page with a sub-sub-page styles.css to later be moved to the Template namespace.
I’ve tested TemplateStyles using my page as the src attribute, but, apparently, my CSS’s content model defaults to CSS once I create it but in order to use TemplateStyles I need to make the content model sanitized-css for that page. And I noticed there’s a Content Model editor but it’s only available to Administrators.
My styles.css is here: https://meta.wikimedia.org/wiki/User:DiegoQuintanaCL/Research_Program/style…
So my question is, could you change my CSS page’s content model to sanitized-css, or is there a way to create a new .css page and have it be sanitized-css from its creation.
Thank you very much.
Introduction
The topics of real-time fact-checking services and AI dialogue systems are broached and some opinions are shared for purposes of discussion.
Crowdsourced Fact-checking Resources
Are crowdsourced real-time fact-checking services possible? What might the design criteria be for such resources? Can such resources be of use to AI dialogue systems?
Determining the truth value of a given statement – or selecting one statement from a set of mutually exclusive statements – might not always be possible for a crowd at an instant. The instantaneous state of and, in some cases, resolution of, fact-checking processes might be such that multiple mutually-exclusive alternative statements are each supported by evidence and argumentation.
Crowdsourced real-time fact-checking resources should facilitate evidence-based argumentation for elements of sets of mutually exclusive statements as a component of providing groups with processes to determine the factuality of statements. There may be other means of clustering statements beyond mutual exclusivity.
Crowdsourced real-time fact-checking resources should support non-anonymous users as well as verified users, non-anonymous users who, for example, are journalists or fact-checkers.
Crowdsourced real-time fact-checking resources should allow users to opt into receiving notifications whenever a particular statement or statement-cluster is updated and AI dialogue systems should similarly be able to subscribe to such events.
Crowdsourced real-time fact-checking resources should support machine-utilizable output formats, output formats beyond HTML.
Efficiencies and Optimizations Regarding Dialogue Systems and Knowledgebases with Remote Fact-checking Services
At an instant, does a given topic require a dialogue system to poll one or more real-time fact-checking resources? Not every topic that a dialogue system might speak about would seem to require polling the data of one or more fact-checking resources. If dialogue systems could determine which topics were volatile, contentious or dynamic, and if these determinations were cacheable for durations, then dialogue systems could more efficiently provide their services at scale while making use of real-time fact-checking services.
It might be possible to determine the volatility, contentiousness, or dynamicism of a given topic by checking on or receiving notifications with respect to the quantity of recent activity for a topic on one or more fact-checking resources. Dialogue systems could asynchronously seek or receive updates regarding this data to best produce responses for users.
Dialogue System Behaviors
Which behaviors should dialogue systems exhibit if asked about volatile, contentious or dynamic topics? For instance, topics of some unfolding discussion on one or more fact-checking resources?
These scenarios might arise as users ask dialogue systems questions about topics recently discussed or debated, e.g. in the news.
Some options are indicated:
Option 1: I Don’t Know
A dialogue system could indicate that it doesn’t know the answer.
Option 2: I Need More Time to Answer that Question
A dialogue system could indicate that the matter is being reviewed by fact-checkers and somehow provide an estimate of when it should be able to answer the question. A dialogue system could ask a user if they desire a notification, including within specified hours, with respect to updates and could provide notifications to users via one of a number of communication channels.
Option 3: Refer Users to Fact-checking Resources
A dialogue system could refer the user to Web materials, for example to the unfolding discussion on a fact-checking resource. Multimodal dialogue systems could present users with Web content.
Option 4: Explain Alternatives and Possibilities
A dialogue system could, in particular when a fact-checking resolution appears to be disagreement, explain the elements of a set of mutually exclusive alternatives and provide the supporting argumentation for each. “Some are indicating X, while others Y.” Questions include how best to synthesize the output rhetoric in these instances, how best to sort the alternatives and possibilities, how best to specify which parties were supporting which alternatives and possibilities, and so forth.
Option 5: Decide
A dialogue system could review the argumentation and evidence supporting each element of a set of mutually exclusive statements and make a decision.
Conclusion
The topics of real-time fact-checking services and AI dialogue systems were broached and some opinions were shared for purposes of discussion.
Best regards,
Adam Sobieski
Hi!
I am Saloni from Kotkapura, Punjab, India.
Currently I am pursuing B.Tech (Computer Science and Engineering) and
new to open source and I want to contribute in Wikimedia Foundation
I am learning
Javascript. This year I want to participate in GSoC 2020 under a project -
Develop a mechanism to send Wikimedia-specific Zulip welcome messages.
Can you guide me about this?
Thank you.
--
Saloni
https://github.com/saloniig
Hello!
The Wikimedia Foundation is soliciting your feedback to measure developer
satisfaction and determine where to invest resources in the future. This is
the second iteration of this survey.
Topics covered include:
* Local Development Environment
* Beta Cluster / Staging Environment
* Testing / CI
* Code Review
* Deployments
* Production Systems
* Development and Productivity Tools
* Developer Documentation
We are soliciting feedback from all Wikimedia developers, including Staff,
3rd party contributors and volunteer developers. *The survey will be open
for a little over 2 weeks, closing on Friday March 6th.*
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement
https://foundation.wikimedia.org/wiki/Developer_Satisfaction_Survey_Privacy…
To participate in this survey, please start here:
https://docs.google.com/forms/d/e/1FAIpQLSclq5vtaonRjwQykpfi2lbLIzJl-9wcOzm…
Thank you for your participation,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
The SimpleBatchUpload [1] extension uses the MW API to batch-upload files. In the simplest case the user just goes to Special:BatchUpload, dumps a bunch of files and they are uploaded in parallel.
I got a bug report recently [2] where I am not sure what to do:
"Our group has been using Extension:SimpleBatchUpload (1.5.0) extensively, but unfortunately we are running into an issue where files are uploaded but fail to be written as a row in the _fileData MW db table or saved to our Cargo db table."
"The problem with server communication error seems to occur more frequently when uploading many files (20 or more) at once via drag & drop and tends to be more problematic on faster network speeds compared to a slower one."
"No MW errors are thrown in the debug log and no glaring apache errors are seen when the communication problem happens."
"Here is the error I see in the console for the two files showing server communication error when trying to upload 50 images. Not sure how helpful this is:
Notice: Uncommitted DB writes (transaction from Wikimedia\Rdbms\Database::begin). in /var/www/html/includes/libs/rdbms/database/Database.php on line 4543
\n","status":200,"statusText":"parsererror"},"1":"parsererror","2":{}}
In addition, I also see many files with another error: Could not store file "/tmp/phpaFwbHh" at "mwstore://local-backend/local-public/
These problems are worse when uploading very quickly on a 1 gigabit network in our office vs when I do it at home on a slower connection.
"
Is this an API bug or should the extension somehow react to the Notice from the server?
Does anyboody have an idea how to mitigate the DB issues?
Any insight greatly appreciated
Stephan
[1] https://github.com/s7eph4n/SimpleBatchUpload
[2] https://github.com/s7eph4n/SimpleBatchUpload/issues/25