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
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! :)
// apologies for cross-posting
Hello!
A new type of preview will soon be part of the MediaWiki software:
Reference Previews.[1] This feature shows you a reference in a small pop-up
when you hover over the reference number in square brackets. This way, you
can look up a reference without jumping down to the bottom of the page.
What’s more is that Reference Previews can offer a quicker way to evaluate
the trustworthiness of the cited source by displaying the reference type
(book, web, news, journal, note) in the pop-up’s header. Thus, they can
help increase trust in the article itself. These types can be applied by
using citation templates, or by manually entering a class into the ref tag.
Reference Previews will be combined with Page Previews[2], a feature
showing previews for linked articles. Both perform essentially the same
function: previewing content before deciding to dig deeper, and easily
providing more information while reading. Because of their similarities in
design and behavior, both Page Previews and Reference Previews will be
controlled by a single user setting. This means, all users who currently
have Page Previews activated, will also get Reference Previews. Also, all
readers, anonymous contributors and new users will see Reference Previews
per default if they haven’t disabled Page Previews.
On several wikis, the Navigation-Popups gadget and the Reference Tooltips
gadget already offer previews for references. If you want to use them
instead, you can: If you have one of these gadgets enabled, you’ll see them
instead of Reference Previews. Although these gadgets exist, this feature
was built into a MediaWiki extension in order to make it available for all
Wikipedias, just as Page Previews is.
The original request for this came from the Technical Wishes survey on
German Wikipedia in 2017, where it was the number 1 wish. The Technical
Wishes team from Wikimedia Germany has been working on it in cooperation
with the WMF’s Reading Web team. Reference Previews have been a beta
feature for several months on all Wikipedias and some other wikis, with
more than 830,000 beta testers. During the beta phase, lots of feedback was
collected, and several changes were made as a result.[3] Now, we plan to
deploy it to a first group of wikis as a default feature on March 17. We’re
still looking for wikis who want to have the default feature early, so if
you’re interested, please let us know! [4] [5]
More information about this feature, including frequently asked questions,
can be found on its project page on Meta. [1] A big thanks to everyone who
contributed to this development, by voting, testing, giving feedback or
else. Comments and questions are welcome on this talk page. [4]
Best,
Johanna
[1] Reference Previews:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews
[2] Page Previews: https://www.mediawiki.org/wiki/Page_Previews
[3] Changes during the beta phase:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews#Bet…
[4] talk page:
https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/ReferencePreviews
[5] Phab: https://phabricator.wikimedia.org/T271206
--
Johanna Strodt
Project manager community communications Technical Wishes
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
======
Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.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.
Hi,
We're currently in the process of upgrading the MediaWiki servers to
Debian Buster and expect a performance regression to come with it.
The cause appears to be better Spectre[1] mitigations in the Buster 4.19
kernel, which we can't disable. Most of the effect is seen in code that
ends up invoking syscalls like filemtime, file_get_contents, etc.
I posted some numbers and charts on the Phabricator investigation
ticket[2]. For normal requests it looks like ~5% worse for p50/p75 and
around ~13% for p95/p99. API requests look much worse, at 10% for p50
22% for p75.
What now? We're going to continue with the upgrade as planned, but we
also need help to try and make some performance improvements to reduce
the impact of the regression.
The PHP profiling flamegraphs[3] are a great tool to use to identify
potentially slow spots. We now also have flamegraphs that only contain
Buster requests. I created a set of differential flamegraphs[4] that
compare Stretch vs Buster so you can see what specific areas slowed down.
You can also use WikimediaDebug/XHGui[5] to profile a specific request.
mwdebug1001/mwdebug1002 are Stretch and mwdebug1003 is Buster.
If you have questions or suggestions please ask or let us know. Thanks
to everyone who helped with the investigation and those who've started
working on improvements already.
[1] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
[2] https://phabricator.wikimedia.org/T273312#6802330
[3] https://performance.wikimedia.org/php-profiling/
[4]
https://people.wikimedia.org/~legoktm/T273312/data/clean/images/flamegraphs/
[5] https://wikitech.wikimedia.org/wiki/WikimediaDebug#Request_profiling
-- Kunal
Hi there,
I am investigating a breakage in my extension that has occurred in MW 1.34
but which didn't seem to be a problem on MW 1.29. (I have not tested
interim versions to see where the issue first arises.)
One of the parser hooks in the extension needs to perform variable
expansion. What is happening is a lot more complicated than this example,
but effectively
<my_hook Foo="What the foo!">{{{Foo}}}</my_hook>
should end up generating the following output, using variable expansion:
What the foo!
The semantics of variable handling need to follow the MW semantics,
including default values (possibly nested), parser functions, etc. therefore
it needs to use the MW parser to perform the expansion.
Assuming the arguments that MW passes into the parser hook are named $Text,
$Vars, $Parser and $Frame, the relevant code looks something like this
(again, a bit more complicated in practice):
$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
array(), $Vars, $Frame->title);
return $Parser->replaceVariables($Text, $NewFrame);
(I have included a more detailed listing of the code that I am using for
doing the parse at the end of this message.)
My code was working fine on MW 1.29 and earlier, but when I upgrade to 1.34
I am finding that I get a fatal exception thrown when my tag is encountered:
/index.php?title=Main_Page MWException
from line 373 of ~\includes\parser\PPFrame_DOM.php:
PPFrame_DOM::expand: Invalid parameter type
I have generated a backtrace and the top of the stack is as follows:
#0 ~\includes\parser\Parser.php(3330): PPFrame_DOM->expand(PPNode_Hash_Tree,
integer)
#1 MyExtension.php (434): Parser->replaceVariables(string,
PPTemplateFrame_DOM)
#2 ~\includes\parser\Parser.php(4293): MyExtensionParserHook(string, array,
Parser, PPTemplateFrame_Hash)
(The subsequent call stack entries are the parent functions you would expect
to see in that situation.)
Can anyone see why the above code would no longer work as it did on previous
versions? What is the current recommended method for manually expanding
template variables from within a parser hook?
Kind regards,
- Mark Clements (HappyDog)
----------------------------------
Full example (with extension-specific code omitted):
----------------------------------
function MyExtensionParserHook($Text, $Vars, $Parser, $Frame) {
// 1) Manipulate $Text and $Vars
// (omitted)
// 2) Expand variables in the resulting text.
// Set up a new frame which mirrors the existing one but which also has
the
// field values as arguments.
// If we are already in a template frame, merge the field arguments with
the
// existing template arguments first.
if ($Frame instanceof PPTemplateFrame_DOM) {
$NumberedArgs = $Frame->numberedArgs;
$NamedArgs = array_merge($Frame->namedArgs, $Vars);
}
else {
$NumberedArgs = array();
$NamedArgs = $Vars;
}
$NewFrame = new PPTemplateFrame_DOM($Frame->preprocessor, $Frame,
$NumberedArgs, $NamedArgs,
$Frame->title);
// Perform a recursive parse on the input, using our newly created
frame.
return $Parser->replaceVariables($Text, $NewFrame);
}
Hello,
After more than one year of design, discussion, vote, iteration, and months
of legal work, I’m happy to announce that the logo of MediaWiki has been
officially changed. This applies to both the software and logo of
https://mediawiki.org.
The old logo of MediaWiki was adopted slightly more than fifteen years ago.
This logo was featuring the nice concept of a sunflower representing
diversity, constant growth and also wilderness.
However, with years, the logo became outdated and we realized that it had
several problems, including but not limited to:
- It was a bitmap picture so it’s unusable in large sizes
- Its high details (“too realistic”) made it unusable in small sizes
- Its fixed and realistic style made it hard to have variations or
adaptations
Most, virtually all, software products use a simpler and more abstract form
following basic logo design guidelines and best-practices to avoid above
(and more) issues. For example, docker, kubernetes, Ubuntu, Vue.js, React,
Apache Kafka and many more.
You can find the discussion of changing the logo in
https://www.mediawiki.org/wiki/Project:Proposal_for_changing_logo_of_MediaW…
. As you can see on this page, a lot of interesting practical and
theoretical exchanges happened, leading to the final vote and decision.
The new logo represents a collection of projects built on our engine: each
petal is one of the many wikis that we support, and the lack of an explicit
core shows that we are part of these projects, as well as and they are part
of MediaWiki. The new logo also reflects the fact that evolution never
stops, and like the petals of a flower, the development of each project,
the growth of each community built on our engine allows everyone else to
grow.
The designer of the new logo is [[User:Serhio Magpie]]. With the nice
abstraction baked-in, you can use it in large or small sizes or you can
adapt it for different usecases (there’s one already for mediawiki on
docker: https://phabricator.wikimedia.org/T274678). There is a logo
guideline for MediaWiki now:
https://www.mediawiki.org/wiki/Manual:MediaWiki_logo_guidelines
We already deployed changes to mediawiki.org and landed related patches on
master, meaning from 1.36 release onwards, it’ll come with the new logo.
You can follow the work of rolling it out in
https://phabricator.wikimedia.org/T268230.
I humbly ask Wikimedians to update their wikis, for example usages on the
main pages, Wikipedia articles, templates, and more. You can use the logos
in this category on Commons. The files are already protected against upload
vandalism. https://commons.wikimedia.org/wiki/Category:MediaWiki_logo_(2020)
A big thank you to all who helped this project to finish. From designers,
community members, people who voted and discussed it intensively for
months, Wikimedia Legal for doing all the necessary work for transferring
the rights, clearing it and filing it for trademark. And many many more
people.
Best
--
Amir (he/him)
https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-03-31
= 2021-03-31 =
== Callouts ==
* RelEng: 1.36.0-wmf.37 blockers:
** [https://phabricator.wikimedia.org/T278376 Constructing RevisionRecord
for a page that can't exist]
** [https://phabricator.wikimedia.org/T278904 new edits are being marked as
quality instead of "accepted"]
* RelEng: Dev satisfaction survey closes TODAY!!
== Gerrit patches or GitHub Pull Requests for reviews or feedback ==
*
=== No updates ===
Language, Library,
=== '''No notes provided''' ===
Editing, Product Infrastructure, Parsing, Inuka, Cloud Services, FR Tech,
Platform, Quality & Test, Search PF, Security,
== Product ==
=== Community Tech ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates:
** We'll be announcing today the end of our work on WS-Export and
officially marking the wish/project as completed
=== Anti-Harassment Tools ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates:
** Wrapping up known work on SecurePoll. May have further things to do here
which will take priority over other tasks.
** New Engineering Manager joined, completing the team. Hurrah!
=== Growth ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates:
** Continuing work on Add Link https://wikitech.wikimedia.org/wiki/Add_Link
** Continuing to work on on-wiki configuration
** Continuing design of mentor dashboard
https://www.mediawiki.org/wiki/Growth/Mentor_dashboard
=== iOS native app ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates: Putting finishing touches on next major release of app
(including drastically better support for Chinese language variants),
should be in beta within the week.
=== Android native app ===
* Blocked by:
* Blocking:
* Thank yous: PET for all their collaboration.
* Updates: Working w/ PET on image recommendation API.
=== Web ===
* Blocked by:
* Blocking:
* Thank yous:
** Timo Tijhof for his work on the (currently Vector-specific) "pref diff"
instrument: https://phabricator.wikimedia.org/T261842
* Updates:
** Onboarding new hires!
** Virtual offsite 29th March through 1st April
** The WVUI search treatment A/B test is complete. All users opted in to
Vector V2 will now get the treatment
** Clarifying feature responsibilities in ResourceLoaderSkinModule:
https://phabricator.wikimedia.org/T269877
=== Structured Data ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates:
** On April 1st, Special:MediaSearch will become the default search UI on
Wikimedia Commons for anonymous users
=== Abstract Wikipedia ===
* Blocked by:
** None.
* Blocking:
** None.
* Thank yous:
** Margeigh and the whole Design team for their flexibility!
* Updates:
** Closing on end of Phase γ:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases
=== Language ===
* Blocked by:
** None
* Blocking:
** None
* Thank yous:
* Updates:
** No major updates this week.
=== Vue.js ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates:
** WVUI: updating Storybook to use the new controls add-on instead of knobs
** Design inventory (https://phabricator.wikimedia.org/T277047 )
** Beginning the technical desicion-making process for adding an automated
build step for front-end assets
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Thank yous:
** SRE ServiceOps for https://phabricator.wikimedia.org/T274262
* Updates:
=== Engineering Productivity ===
==== Performance ====
* Blocked by:
* Blocking:
* Thank yous:
** DC Ops for looking into device lab hosting feasibility
** ITS for doing the same
* Updates:
==== Release Engineering ====
* Blocked by:
** See wmf.37 train blockers.
* Blocking:
** ???
* Thank yous
** Legoktm for all kinds of assistance, on mw-on-k8s
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** Train Health
*** Last week: 1.36.0-wmf.36 [[phab:T274940]] <!--
https://phabricator.wikimedia.org/T274940 -->
*** This week: 1.36.0-wmf.37 [[phab:T278343]] <!--
https://phabricator.wikimedia.org/T278343 -->
*** This week: 1.36.0-wmf.38 [[phab:T278344]] <!--
https://phabricator.wikimedia.org/T278344 -->
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Thank yous:
* Updates:
** No updates
=== WMDE Technical Wishes ===
* Blocked by:
* Blocking:
* Thank yous:
* Updates:
** Kartographer exploration led to a straightforward, potential solution
for fixing the incompatibility with FlaggedRevs wikis.
** Beginning user research interviews for next year’s Geoinformation focus.
** Curious whether anyone else sees a need for mw-core anonymous user
“settings” management, currently done differently in many extensions.
== Cross-cutting ==
* Blocked by:
** [long term] Search Platform: PHP 8.0 work is long-term blocked on the
migration to ElasticSearch 7.0 https://phabricator.wikimedia.org/T263142
(or at least 6.7)
* Blocking:
* None.
* Thank yous:
* Updates:
** PHP 8.0 work
*** Upstream libraries: Elastica-related PHP code is theoretically the last
one.
*** Core: Some unit and integration tests still fail; tank you to everyone
working on fixing them.
** Next release of mediawiki-codesniffer likely soon.
** CI tools' upgrade status:
https://libraryupgrader2.wmcloud.org/status?branch=master
Hello All,
Many of us were hopeful that we would be able to organise an onsite
hackathon and meet in person in 2021. While this is sadly not the case, we
still wanted to offer the opportunity for the technical community to get
together virtually, work together on various projects, and discuss new
ideas.
This is why we’re happy to invite you all to join the ‘21 Wikimedia remote
hackathon on May 22/23
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2021> - save the date,
and bring your projects & ideas!
Building on last year’s edition, this event is organized in a light mode,
offering a lot of space for spontaneity, experimentation, and all kinds of
projects. The ‘21 Wikimedia remote hackathon is built by and for its
participants, and coordinated by a team of volunteers and staff - Amir,
Birgit, Joaquin, Léa, Mohammed, Neslihan, Pavritha.
On this page <https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2021> you
will find all the relevant information. The planned framework consists of
one main track of sessions that participants can follow, open rooms for
informal discussions, workshops and social events, and to work together on
projects.
We will send out more information on how to schedule a session in the
program soon! You can also add yourself to the participants list
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2021/Participants>, and
mention if you would like to help with tasks such as facilitation, or
welcoming newcomers.
We hope that this event can be a moment of fun, reconnecting with
long-time-no-see Wikimedians as well as onboarding new people into the
technical community.
If you have any questions, feel free to reach out to us on the
communication channels of the event
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2021/Discussions>.
Hope to see you there!
The ‘21 remote hack coordination team
--
Birgit Müller (she/her)
Director of Technical Engagement
Wikimedia Foundation <https://wikimediafoundation.org/>
tl;dr: The deployment calendar format will change in 2 weeks (2021-04-05)
to make it easier to edit with visual editor https://w.wiki/a3b
I updated the deployment calendar for the week of 2021-04-05[0] to use a
different format than in the past (compare to next week[1]). My hope is
that this new format will make it much easier to schedule deployment
windows and to schedule patches for backports using Visual Editor.
Also, selfishly, less squinting at Wikitext for me :)
All credit for the new format goes to Timo Tijhof. Thank you Timo!
Thanks all!
-- Tyler
[0]: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_April_05>
[1]: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_29>
Hello,
tl;dr: https://lists-next.wikimedia.org is running mailman3. Please help us
test the software before we upgrade the real mailing list server.
Kunal and I have been working on deploying the new mailman (version 3) to
replace mailman2 serving https://lists.wikimedia.org and powering all of
our mailing lists.
Mailman2 is a dinosaur that should have gone extinct years ago. Pretty old
user interface (especially for admins and moderators), storing passwords in
plain text, lack of any database (everything is file on disk), pretty old
code, lack of ability to search in archives or send email from web
interface, running on EOL python (python2), encoding issues with non-Latin
languages, hard to redact archives, and the list goes on and on.
The new version has been developed/puppetized/tested in the Cloud and is
now ready for proper testing! Give it a try:
https://lists-next.wikimedia.org. We have created some mailing lists you
can join and can test. If you want to test the experience as a list
administrator/moderator, we can give those permissions out as well.
WARNING: All data on the lists-next server will be deleted after the test
period is over.
We will also need help updating documentation on wikis and elsewhere.
If you find any bugs/issues (yay!), please file a ticket in the
“Wikimedia-Mailing-lists” Phabricator project and we’ll check it out.
In the coming days/weeks will also import some public mailing lists from
the old version to the new version to check archive size, search index
size, and other aspects. There are other TODOs left as well like
monitoring, logging, anti-abuse, etc.
Slowly and after testing (hopefully soon), we expect to deploy this on
lists.wikimedia.org and mailing lists one by one or in batches can be
upgraded to the 21st century.
The overall task tracking this project is T52864
<https://phabricator.wikimedia.org/T52864> and a big thank you people who
are helping this move forward.
Regards,
Kunal and Amir