Wikitech-l November 2022

wikitech-l@lists.wikimedia.org

42 participants
42 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 28 Jun '24

28 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24

We just released a new version of Research:FAQ on Meta [1], significantly expanded and updated, to make our processes at WMF more transparent and to meet an explicit FDC request to clarify the role and responsibilities of individual teams involved in research across the organization. The previous version – written from the perspective of the (now inactive) Research:Committee, and mostly obsolete since the release of WMF's open access policy [2] – can still be found here [3]. Comments and bold edits to the new version of the document are welcome. For any question or concern, you can drop me a line or ping my username on-wiki. Thanks, Dario [1] https://meta.wikimedia.org/wiki/Research:FAQ [2] https://wikimediafoundation.org/wiki/Open_access_policy [3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953 *Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter <http://twitter.com/readermeter>

2 1

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

Notification about Gerrit related request
by Zoran Dori 15 Feb '23

15 Feb '23

Hello, as per https://www.mediawiki.org/wiki/Gerrit/Privilege_policy , I want to notify you that I made task https://phabricator.wikimedia.org/T323247 about granting me ownership of the Gerrit repository of the UnblockMe extension. I would appreciate your suggestions or +1s. :) Thank you for your time and consideration! Best regards, Zoran

1 1

Unsubscribe from mail list
by Arpit Maheshwari 11 Jan '23

11 Jan '23

This is a request to please kindly unsubscribe me from your mailing list

4 4

List related to repositories which haven't mediawiki/mediawiki-codesniffer
by Zoran Dori 11 Jan '23

11 Jan '23

Hello, can someone to update list https://phabricator.wikimedia.org/P10500 which contains repositories which haven't mediawiki/mediawiki-codesniffer. I found in list that much repositories are empty, and repositories which aren't available on Gerrit. So, can someone please update this list of repositories (in mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at least, contains one PHP file. or to provide me command with which I can update list when I want, so I don't need to request it every time. Best regards, Zoran. P. S.: Happy weekend! :)

4 6

Repository ownership of the Lingo extension
by Zoran Dori 11 Jan '23

11 Jan '23

Hi everyone, I want to notify you that I have, on behalf of the WikiTeq company, made a task https://phabricator.wikimedia.org/T298277 for requesting repository ownership for the Lingo extension. In case that you have any kind of questions, please let me know. :) Best regards, Zoran

3 3

Movereason-dropdown
by Bináris 15 Dec '22

15 Dec '22

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

2 3

Feedback wanted: PHPCS in a static types world
by Lucas Werkmeister 08 Dec '22

08 Dec '22

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.

10 13

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 2022