Hello colleagues,
This is a reminder that this month's Wikimedia Café will start
approximately 48 hours from now.
--
Hello colleagues,
The February 2020 Wikimedia Café meetup will occur on 15 February 2020
at 8:30 AM PST / 11:30 AM EST / 4:30 PM UTC / 10 PM IST. The date is
earlier than usual in the month due to scheduling constraints.
This month's meetup will focus on the 2030 strategy recommendations,
and will be divided into two discussions of one hour each.
More information regarding the agenda and links to strategy documents
are available at https://meta.wikimedia.org/wiki/Wikimedia_Café.
As usual, the meeting style for the Café will emphasize discussion
rather than presentation. People are welcome to participate as
listeners only if they prefer.
Please see the page on Meta for more information about the Café.
Please watch the page for any updates, particularly to the schedule or
the agenda. Signing up for the meeting is optional, but is helpful to
the organizers so that we can estimate how many people will attend.
Signing up for the meeting also informs us who we should notify
individually if there are significant changes.
If there are any problems with connecting to the meeting or if you
have any questions or comments then please write on the Meta talk
page.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
Hi all,
I am working on a custom ResourceLoader module whose style contents are compiled from Sass stylesheets. These Sass stylesheets take as input user-defined theme variables that affect the output.
I am looking for a way to invalidate ResourceLoader URLs that include such style modules, when these variables change as a result of an user action—primarily so that the user can see their own changes.
ResourceLoader will cache such style URLs for 5 minutes on the CDN and in the user’s browser cache, so by default the user would have to wait until their cached copy of styles expire before they would receive the updated version. Accordingly, I have tried to explore if following the document steps to empty one’s browser cache[1] after making changes would cause the browser to fetch the updated resource from the backend. Unfortunately, both Chrome and Firefox appear to send a “Cache-Control: no-cache” request header for the style URL if the page is hard refreshed, which seems to cause most CDNs (including WMF’s) to act as the source of truth and serve the asset from cache if it is already there, without triggering a backend fetch or conditional revalidation. In the case of a simple refresh, Chromium and derivatives will not trigger a conditional revalidation of resources including on a page since 2017,[2] so they just continue to use the asset that was already in the browser’s cache. Thus, the standard instructions for emptying one’s cache do not seem to be sufficient to allow the user to see the effect of their styling changes.
Given the above, the only option I see that would allow the user to see the updated styles after modifying input variables would be to append a version hash to the style URL included in the page HTML—something which ResourceLoader does not
currently do.
Do you know of a better approach to this problem? Are there any examples in MediaWiki core or extensions that accomplish something similar? I have consulted the code for ResourceLoaderSiteStylesModule, but it does not seem to have any specific invalidation behaviour, nor does it use a version hash in style URLs in the page HTML, so it seems that any updates to it take 5 minutes to propagate.
Thanks in advance!
—
[1] https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=505048
Cheers,
Máté Szabó
SOFTWARE ENGINEER
+36 30 947 5903
Fandom Poland sp. z o.o. z siedzibą w Poznaniu, ul. Abp. A. Baraniaka 6
Sąd Rejonowy Poznań – Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000254365
NIP: 5252358778
Kapitał zakładowy: 50.000,00 złotych
Well it's not Tuesday, but better late than never.
I'd like to think volutneer DannyS712 [1] who has frankly done a humongous
amount of work over the last couple of weeks. DannyS712 has been going
through many technical-debt and code cleanup tasks, splitting them and
tackling them each one extension at a time, all while working at the same
time on their Global watchlist userscript [2] and many other technical
tasks on en.wp at the same time. Absolutely impressive.
I also want to join [3] VolkerE in thanking MattFitzpatrick,
PerfektesChaos and heydonworks for highlighting and persisting on
indicating a simple accessibility improvement [4] of the Table of Contents
for screenreader users, that will soon be deployed.
[1] https://phabricator.wikimedia.org/p/DannyS712
[2] https://meta.wikimedia.org/wiki/User:DannyS712/Global_watchlist.js
[3] https://twitter.com/Volker_E/status/1227261008059592704
[4] T139221: Make generated table of contents a navigation region
<https://phabricator.wikimedia.org/T139221>
*(feel free to forward the message as is to your friends, family members &
colleagues)*
Hello folks,
We would like to invite you to apply to the Outreachy and Google Summer of
Code program with the Wikimedia Foundation (a non-profit organization
behind Wikipedia)!
*About the Outreachy program*
Wikimedia will be mentoring ~7 projects in the Outreachy program in the May
to August 2020 round. The initial applications are due February 25th at 4
pm UTC.
Apply today: https://www.outreachy.org/apply/
Outreachy offers three-month internships to work remotely in Free and Open
Source Software (FOSS) projects with experienced mentors. The internships
may include programming, user experience, documentation, illustration and
graphic design, or data science.
Outreachy internships run twice a year – from May to August and December to
March. Interns are paid a stipend of $5,500 USD for the three months of
work. They also have a $500 USD stipend to travel to conferences and
events. Interns often find employment after their internship with Outreachy
sponsors or in jobs that use the skills they learned during their
internship.
Outreachy is open to both students and non-students. Outreachy expressly
invites the following people to apply:
* Women (both cis and trans), trans men, and genderqueer people.
* Anyone who faces under-representation, systematic bias, or discrimination
in the technology industry in their country or residence is invited to
apply.
* Residents and nationals of the United States of any gender who are
Black/African American, Hispanic/Latin@, Native American/American Indian,
Alaska Native, Native Hawaiian, or Pacific Islander.
*About the Google Summer of Code program*
Wikimedia is planning to mentor 8-10 projects in 2020’s Google Summer of
Code (GSoC) program. Beginning February 20th, pending Wikimedia’s
acceptance as a mentoring organization, applicants can begin discussing
ideas with the mentors!
The student application will be due on March 31st 18:00 UTC:
https://summerofcode.withgoogle.com/
Google Summer of Code now in its 16th year, is Google's summer program for
university students who want to get involved in open source software. Over
15,960 students from 109 countries have already participated. Google Summer
of Code is a unique program that pairs students with mentors who introduce
them to the open-source community and provide guidance while they work on
real-world open-source projects during their summer break from university.
Projects cover a wide range of fields including: Cloud, Operating Systems,
Graphics, Medicine, Programming Languages, Robotics, Science, Security and
many more. It's a highly competitive program (and this year is expected to
be even bigger than last year), so don't wait until the last minute to
prepare!
*About the Wikimedia Foundation*
The Wikimedia Foundation <https://wikimediafoundation.org/> is the
nonprofit organization that hosts and operates Wikipedia and the other
Wikimedia
free knowledge projects
<https://wikimediafoundation.org/our-work/wikimedia-projects/>. Our vision
is a world in which every single human can freely share in the sum of all
knowledge. We believe that everyone has the potential to contribute
something to our shared knowledge, and that everyone should be able to
access that knowledge, free of interference. We host the Wikimedia
projects, build software experiences for reading, contributing, and sharing
Wikimedia content, support the volunteer communities and partners who make
Wikimedia possible, and advocate for policies that enable Wikimedia and
free knowledge to thrive.
*Resources*
* Browse through the participants’ guides, to learn more about the
application process steps:
https://www.mediawiki.org/wiki/Outreachy/Participantshttps://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants
* All the projects will be showcased here:
https://www.outreachy.org/communities/cfp/wikimedia/https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020
We hope you will help us spread the word about Wikimedia’s participation in
these programs: https://twitter.com/mediawiki/status/1224790357361098752
(by retweeting the post in the link or by sharing this email)
Looking forward to your participation!
Cheers,
Srishti & Pavithra (Wikimedia organization administrators for GSoC &
Outreachy)
*Srishti Sethi*
Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hey everyone!
I'm Yasas Ekanayaka From Sri Lanka. I'm a University student. I'm following
a degree in computer science. I'm good at C/C++, Python, HTML, JavaScript,
AngularJS, PHP languages and frameworks. I like to contribute your open
source projects.
Thank you
What about log_search, which is intended for permanent storage of data; could your extension generate a log event and then use that log_id as the ls_log_id? https://www.mediawiki.org/wiki/Manual:Log_search_table
Maybe there could be a new type of log_type/log_action introduced, e.g. storedata/myextension, if your extension is called MyExtension. Each extension that stores data in this way would have its own log_action, and would generate one or more log events as needed to reserve a log_id(s) for data storage.
When deploying MediaWiki 1.35.0-wmf.18 to Group 2 wikis on Thursday, there
was a serious incident which took down all wikis for several minutes and
resulted in a rollback to wmf.16.
My current understanding is that attempting to deploy wmf.18 again is
likely to cause another severe outage. The train remains blocked until the
root cause of the outage is identified.
Investigation is ongoing. Details and further updates will be posted on the
status tracking task for wmf.18[1] and some background on the investigation
has been documented in the incident report[2].
[1] https://phabricator.wikimedia.org/T233866
[2]
https://wikitech.wikimedia.org/wiki/Incident_documentation/20200206-mediawi…