Matrix.org (both the protocol and the home server) are used quite a bit
by Wikimedia communities:
https://meta.wikimedia.org/wiki/Matrix.org
Currently a number of channels have their primary home on matrix.org and
we advertise app.element.io as primary client too. This means we're
currently relying on the resources of a central entity for what is
supposed to be a decentralised protocol.
Now we know that trouble is brewing: «This is completely unsustainable,
and Element is now literally unable to fund the entirety of the Matrix
Foundation on behalf of everyone else - and has had to lay off some of
the folks working on the core team as a result».
https://matrix.org/blog/2022/12/25/the-matrix-holiday-update-2022https://matrix.org/blog/2022/12/01/funding-matrix-via-the-matrix-org-founda…
For context, Matrix currently has about the same number of users
WhatsApp had in 2012; in 2013, WhatsApp had expenses of 150 M$. You know
what happened next.
https://en.wikipedia.org/w/index.php?title=WhatsApp&oldid=1129148959#cite_r…
So the Matrix Foundation is extremely cheap for what it's doing, but
still it's not gratis. As Wikimedia movement we should at very least
financially support the parts of Matrix that we use the most, like the
IRC bridges.* Alternatively, "we" should switch to some collectively
funded hoster for "our" Matrix presence, like e.g. feneas.org used to
be, and contribute to that. But that seems more complicated and
expensive to arrange.
The same argument applies to many of the upstream projects and assorted
software we rely on https://meta.wikimedia.org/wiki/FLOSS-Exchange ,
especially where it's not realistic to contribute with software
development and where a managed hosting is preferable, but the Matrix
case seems to present some urgency.
Best,
Federico
(*) And Libera Chat itself, if a need ever arises. At the moment they
have practically zero expenses and they mostly ask for borrowed
hardware, which WMF can't really provide and Wikimedia affiliates
usually don't have.
https://libera.chat/contributing/sponsor/https://libera.chat/annual-reports/2021/a1-financial-report/
Hi,
we have a MediaWiki:Deletereason-dropdown which appears as a dropdown on
Special:Delete. How can I create a similar dropdown for frequent
renaming/moving reasons?
--
Bináris
The 1.40.0-wmf.14 version of MediaWiki is [blocked]. The new version is
currently only deployed on group0 and will not proceed further:
* Parsoid: UnexpectedValueException: Invalid version string ""
https://phabricator.wikimedia.org/T325137
It is most probably related to sun setting RestBase from our
infrastructure and I have made the involved people aware of this task on
our internal communication system ( #restbase-sunset on Slack).
[blocked] https://phabricator.wikimedia.org/T320519
--
Antoine "hashar" Musso
Hello,
On our Gerrit, CI results are displayed below the commit message as a
HTML table. It is achieved by a few lines of JavaScript which parse the
comments. I went to write a replacement based on a system builtin
Gerrit: Checks API
<https://gerrit.wikimedia.org/r/Documentation/pg-plugin-checks-api.html>
. An early example: https://phabricator.wikimedia.org/F35814298 .
I could use some early adopters to try out the plugin and gather some
early feedback. If all goes well I will roll it on our Gerrit instance.
If you are curious or want to provide some feedback, below are the
instructions to run it on your local machine.
In Chrome/Chromium, install the Gerrit Frontend Dev Helper extension
<https://chrome.google.com/webstore/detail/gerrit-fe-dev-helper/jimgomcnodki…>.
It is used to inject the JavaScript plugin from a locally running web
server.
Create a new empty directory
Retrieve the JavaScript Gerrit plugin from Change 859083
<https://gerrit.wikimedia.org/r/c/operations/software/gerrit/+/859083/>:
curl -o wm-checks-api.js
'https://gerrit.wikimedia.org/r/changes/operations%2Fsoftware%2Fgerrit~85908…'
Retrieve a PHP router for the PHP built-in webserver. It would inject
cross origin headers when serving a response:
curl -o plugins-router.php
'https://gerrit.wikimedia.org/r/changes/operations%2Fsoftware%2Fgerrit~86088…'
Start a PHP Webserver to serve the plugin:
php -S 127.0.0.1:8081 plugins-router.php
Head to https://gerrit.wikimedia.org/ and enable the Gerrit FE dev
helper plugin. The page will reload.
Click again the browser extension and a configuration popup will appear.
Using the ADD button add an entry with:
* Operator: injectJSPlugin
* Destination: http://127.0.0.1:8081/wm-checks-api.js
Click SAVE. The page reloads and the plugin should have been injected
(there would be a little red box in the bottom right of the Gerrit
page). When browsing a change that previously had CI comments, you
should see a Checks tab which hold the results found by the plugin.
The series of changes is in Gerrit
https://gerrit.wikimedia.org/r/q/topic:checks-api
--
Antoine Musso
/(a good chunk of the code was written late at night over a week-end, I
had to rerelearn JavaScript and discovered TypeScript in the process)./
Hi. Is there a way for javascript to retrieve the current personal list of
recommended languages that appears at the top of the language selector when
navigating with interwiki?
Thank you,
Igal (User:IKhitron)
Hi all!
In my opinion, MediaWiki’s PHPCS ruleset feels largely rooted in an older
version of PHP, where static type declarations (formerly known as “type
hints”) did not exist. As we move towards more modern code, I think some
rules should be relaxed, and others adjusted. More specifically, I’d like
to know if most people agree with the following propositions and conclusion:
Proposition 1: *Some code is sufficiently documented by names and types*,
and does not require additional documentation. Cases where additional
documentation is required do certainly exist, but they can only be
identified by human reviewers, not by automated tools.
You can see this in our existing code wherever a doc comment specifies only
a type (with @var, @param, or @return), but no additional text. For
example, in CreditsAction
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/actions…>,
nobody needs to be told that the LinkRenderer will be used to render links,
or that the UserFactory creates User objects:
class CreditsAction extends FormlessAction {
/** @var LinkRenderer */
private $linkRenderer;
/** @var UserFactory */
private $userFactory;
Likewise, it’s not necessary to explain in great detail that the string
returned by LinksTable::getTableName()
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/deferre…>
is the table name, that the $actor parameter of ActorCache::remove(
UserIdentity $actor )
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/user/Ac…>
represents the actor to remove from the cache, or what the meaning of
the Message
$m and returned MessageValue are in Message\Converter::convertMessage()
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/Message…>
:
/**
* Convert a Message to a MessageValue
* @param Message $m
* @return MessageValue
*/
public function convertMessage( Message $m ) {
(I want to clarify that in this last example I’m only talking about the
@param and @return tags that already don’t have any prose text. While the
method comment “Convert a Message to a MessageValue” might also be
considered redundant, I think this would be more contentious, and I’m not
advocating for removing that today.)
Proposition 2: *Adding types as static types is generally preferable.*
Unlike doc comments, static types are checked at runtime and thus
guaranteed to be correct (as long as the code runs at all); the small
runtime cost should be partially offset by performance improvements in
newer PHP versions, and otherwise considered to be worth it. New code
should generally include static types where possible, and existing code may
have static types added as part of other work on it. I believe this
describes our current development practice as MediaWiki developers.
Note that some older MediaWiki classes are considered unsuitable for static
types, and should only be used in comments; this is expected to help in a
future migration away from these classes (see T240307#6191788
<https://phabricator.wikimedia.org/T240307#6191788>).
Proposition 3: *Where types can be losslessly represented as PHP static
types, types in doc comments are unnecessary.* When doc comments are
considered necessary for actual documentation beyond types, then the type
is generally still included (and Phan will check that it matches the static
type), but when no further documentation is needed (see proposition 1
above), then the @var, @param, etc. doc comment can be omitted.
Note that depending on the PHP version, not all types can be losslessly
represented as PHP static types yet (e.g. union types and mixed both need
to wait for PHP 8.0, null and false for PHP 8.2); in such cases, doc
comments can remain necessary.
Conclusion: *We should update our PHPCS ruleset to require fewer doc
comments.* Exact rules are probably to be decided, depending on how much
work we’re willing to put into the sniff implementations (e.g. is it
feasible to require /** @param */ doc comments only if a parameter has no
static type?), but generally, I argue that we want code such as the
following to be allowed by our standard PHPCS ruleset:
class CreditsAction extends FormlessAction {
private LinkRenderer $linkRenderer;
private UserFactory $userFactory;
/** Convert a Message to a MessageValue */
public function convertMessage( Message $m ): MessageValue {
When doc comments are still necessary or at least beneficial because the
type alone isn’t enough information, it’s up to humans to decide this while
writing the code or point it out during code review.
What do people think about this? :)
PS: In PHP 8, we could abbreviate some of this code even more using
constructor property promotion:
class CreditsAction extends FormlessAction {
public function __construct(
Page $page,
IContextSource $context,
private LinkRenderer $linkRenderer,
private UserFactory $userFactory
) {
parent::__construct( $page, $context );
}
(Again, I’m not saying that all code should look like this – but I think we
have plenty of existing code that effectively carries no additional
information in its documentation, and which could be converted into this
form without losing anything.)
Cheers,
Lucas
--
Lucas Werkmeister (he/er)
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.