Wikitech-l August 2020

wikitech-l@lists.wikimedia.org

67 participants
54 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 23 Feb '23

23 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

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

Making breaking changes without deprecation?
by Daniel Kinzler 04 Nov '20

04 Nov '20

Hi all! Since the new Stable Interface Policy[1] has come into effect, there has been some confusion about when and how the deprecation process can be accelerated or bypassed. I started a discussion about this issue on the talk page[2], and now I'm writing this email in the hope of gathering more perspectives. tl;dr: the key question is: Can we shorten or even entirely skip the deprecation process, if we have removed all usages of the obsolete code from public extensions? If you are affected by the answer to this question, or you otherwise have opinions about it, please read on (ok ok, this mail is massive - at least read the proposed new wording of the policy). I'm especially interested in the opinions of extension developers. So, let's dive in. On the one hand, the new (and old) policy states: Code MUST emit hard deprecation notices for at least one major MediaWiki version before being removed. It is RECOMMENDED to emit hard deprecation notices for at least two major MediaWiki versions. EXCEPTIONS to this are listed in the section "Removal without deprecation" below. This means that code that starts to emit a deprecation warning in version N can only be removed in version N+1, better even N+2. This effectively recommends that obsolete code be kept around for at least half a year, with a preference for a full year and more. However, we now have this exception in place: The deprecation process may be bypassed for code that is unused within the MediaWiki ecosystem. The ecosystem is defined to consist of all actively maintained code residing in repositories owned by the Wikimedia foundation, and can be searched using the code search tool. When TechCom added this section[3][4], we were thinking of the case where a method becomes obsolete, but is unused. In that case, why go through all the hassle of deprecation, if nobody uses it anyway? However, what does this mean for obsolete code that *is* used? Can we just go ahead and remove the usages, and then remove the code without deprecation? That seems to be the logical consequence. The result is a much tighter timeline from soft deprecation to removal, reducing the amount of deprecated code we have to drag along and keep functional. This is would be helpful particularly when code was refactored to remove undesirable dependencies, since the dependency will not actually go away until the deprecated code has been removed. So, if we put in the work to remove usages, can we skip the deprecation process? After all, if the code is truly unused, this would not do any harm, right? And being able to make breaking changes without the need to wait a year for them to become effective would greatly improve the speed at which we can modernize the code base. However, even skipping soft deprecation and going directly to hard deprecation of the construction of the Revision class raised concerns, see for instance <https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg92871.html>. The key concern is that we can only know about usages in repositories in our "ecosystem", a concept introduced into the policy by the section quoted above. I will go into the implications of this further below. But first, let me propose a change to the policy, to clarify when deprecation is or is not needed. I propose that the policy should read: Obsolete code MAY be removed without deprecation if it is unused (or appropriately gated) by any code in the MediaWiki ecosystem. Such removal must be recorded in the release notes as a breaking change without deprecation, and must be announced on the appropriate mailing lists. Obsolete code that is still used within the ecosystem MAY be removed if it has been emitting deprecation warnings in AT LEAST one major version release, and a best effort has been made to remove any remaining usages in the MediaWiki ecosystem. Obsolete code SHOULD be removed when it has been emitting deprecation warnings for two releases, even if it is still used. And further: The person, team, or organization that deprecates code SHOULD drive the removal of usages in a timely manner. For code not under the control of this person, team, or organization, appropriate changes SHOULD be proposed to the maintainers, and guidance SHOULD be provided when needed. Compared to the old process, this puts more focus on removing usages of obsolete code. Previously, we'd often just wait and hope that usages of deprecated methods would vanish eventually. Which may take a long time, we still have code in MediaWiki that was deprecated in 1.24. Of course, every now and then someone fixes a bunch of usages of deprecated code, but this is a sporadic occurrence, not designed into the process. With the change I am proposing, whoever deprecates a function also commits to removing usages of it asap. For extension developers, this means that they will get patches and support, but they may see their code broken if they do not follow up. Now, my proposal hinges on the idea that we somehow know all relevant code that needs fixing. How can that work? When TechCom introduced the idea of the "MediaWiki ecosystem" into the policy, our reasoning was that we want to support primarily extension developers who contribute their extensions back to the ecosystem, by making them available to the public. We found it fair to say that if people develop extensions solely for their own use, it is up to them to read the release notes. We do not need to go out of our way to protect them from changes to the code base. Effectively, with the proposed change to the policy, maintainers of public extensions will get more support keeping their extensions compatible, while maintainers of private extensions will receive less consideration. It seems desirable and fair to me to allow for "fast track" removal of obsolete code, but only if we create a clear process for making an extensions "official". How exactly would an extension developer make sure that we know their extension, and consider it part of the ecosystem? In practice, "known code" is code accessible via codesearch[5]. But how does one get an extension into the codesearch index? There is currently no clear process for this. Ideally, it would be sufficient to: * create a page on mediawiki.org using the {{Extension}} infobox, * setting the status to "stable" (and maybe "beta"), * and linking to a public git repository. It should be simple enough to create a script that feeds these repos into codesearch. A quick look at Category:Extensions_by_status category tells me that there are about a thousand such extensions. So, my question to you is: do you support the change I am proposing to the policy? If not, why not? And if you do, why do you think it's helpful? -- daniel PS: This proposal has not yet been vetted with TechCom, it's just my personal take. It will become an RFC if needed. This is intended to start a conversation. [1] https://www.mediawiki.org/wiki/Stable_interface_policy [2] https://www.mediawiki.org/wiki/Topic:Vrwr9aloe6y1bi2v [3] https://phabricator.wikimedia.org/T193613 [4] https://phabricator.wikimedia.org/T255803 [5] https://codesearch.wmcloud.org/search/ -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation

13 21

Fwd: Public API for Wikimedia map tiles to be discontinued in 45 days
by Erica Litrenta 06 Oct '20

06 Oct '20

[crosspost from Maps-l] Today the Wikimedia Foundation is announcing the deprecation of the public API for Wikimedia map tiles. Around mid October the Foundation will end support for the Wikimedia Maps Service API [1]. This change affects people using Wikimedia maps on their own website or app. Maps on the Wikimedia sites, in Wikimedia-hosted tools and gadgets, and on maps.wikimedia.org won't be affected. This decision was made based on recent outage incidents, primarily due to spikes in third party usage, along with an analysis showing that more than a third of maps provided are to non-Wikimedia services (including many to for-profit organizations). After the most recent incident [2], the service was limited so that only cached maps tiles would be available. While this protected the servers, it made the service unpredictable and highlighted the unsustainability of our tile service. So, we have made the decision to discontinue the maps APIs for non-Wikimedia users. This change will allow our teams working on Maps to focus on the sustainability of the maps used within Wikimedia projects. You can follow the implementation of this change on Phabricator [3]. Best, Erica Litrenta [1] https://maps.wikimedia.org/osm-intl/ [2] https://wikitech.wikimedia.org/wiki/Incident_documentation/20200204-maps [3] https://phabricator.wikimedia.org/T261424 -- Erica Litrenta Manager, Community Relations Specialists https://meta.wikimedia.org/wiki/User:Elitre_(WMF)

1 2

"Library" for sharing useful resources for learning technical topics
by Amir Sarabadani 22 Sep '20

22 Sep '20

Hello, Recently, I stumbled upon a technical writing course which I found very useful and I wanted to share it and thought of sending an email to wikitech-l recommending it. Also, I've been looking for a resource about VueJS with not much luck and wanted to send an email asking if anyone knows any. Instead, I have this idea to have a virtual library for developers so they can share useful resources with each other. You go to a wiki page and see list of courses, books, conference videos, on each topic and different people recommanding them. You can also request a resource for a topic and people respond to you. If the wiki page grows too big, we can split them to sub pages based on topics, and so on. I started the page in https://www.mediawiki.org/wiki/User:Ladsgroup/Library but I'm planning to move it to the main namespace if no one objects. Please take a look, add more recommandations, co-sign, request for a resource, respond to a request for a resource, etc. What do you think? Please let me know if you think it's a horrible idea or you have feedback on details (mediawiki.org? maybe we should move it to wikitech.wikimedia.org?) Hope that'd be useful. Best -- Amir (he/him)

7 7

(Low prio) Do we still need AtEase?
by Krinkle 09 Sep '20

09 Sep '20

It does the same as the @ operator, except that it takes care to prevent a very bad bug that existed before PHP 7. Details at https://phabricator.wikimedia.org/T253461 If there are other issues or benefits, please write them on the task. The overhead of AtEase is prerty minor, so really any benefit at all is likely to tip the balance toward keeping it. But, in the event that there isn't any, then perhaps we should slowly phase it out. Best, -- Timo

1 1

Wikimedia Chat
by Amir Sarabadani 05 Sep '20

05 Sep '20

Hello, Due to the current situation, there are more and more collaborations happening online instead. and now you can see Wikimedia-related discussion groups in Slack, Discord, Telegram, Facebook, and many more. Besides being scattered and inaccessible to people who don't have accounts in those platforms (for privacy reasons for example), these platforms use proprietary and closed-source software, are outside Wikimedia infrastructure and some harvest our personal data for profit. IRC on freenode is a good alternative but it lacks basic functionalities of a modern chat platform. So we created Wikimedia Chat, a mattermost instance in Wikimedia Cloud. Compared to IRC, you have: * Ability to scrollback and read messages when you were offline * Push notification and email notification * You don't need to get a cloak to hide your IP from others * Proper support for sharing media * Two factor authentication * A proper mobile app support * Ability to add custom emojis (yes, it's extremely important) * Profile pictures * Ability to ping everyone with @here * much much more. You can use Wikimedia Chat by going to https://chat.wmcloud.org, anyone can make an account. This is part of Wikimedia Social suite [1], the oher similar project is "Wikimedia Meet". [2] Some notes: * This is done in my volunteer capacity and has been maintained by a group of volunteers. If you're willing to join the team (either technical or enforcing CoC, kicking out spammers, other daily work), drop me a message. * Privacy policy of Wikimedia Cloud applies: https://w.wiki/aQW * As a result, all messages older than 90 days get automatically deleted. * As a Wikimedia Cloud project, all of discussions, private and public are covered by Code of conduct in technical spaces: https://w.wiki/AK$ Hope that would be useful for you, if you encounter any technical issues, file a bug in the phabricator. [1] https://meta.wikimedia.org/wiki/Wikimedia_Social_Suite [2] https://meta.wikimedia.org/wiki/Wikimedia_Meet Best -- Amir (he/him)

9 14

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 August 2020