Hi,
With the release of MediaWiki 1.28, the lifetime of MediaWiki version
1.26.x has come to an end.
Users still using MediaWiki 1.26.x are advised to upgrade to version
1.28.0, the latest stable version.
-Chad
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Hi all!
For this week's RFC discussion [1], let's talk about per-language URLs for
multilingual wiki pages[2]. The basic idea is to encode the uselang parameter
the the url path so it doesn't break caching. This raises some questions about
purging, and about rendering links.
The meeting will be the usual time (Wednesday 21 UTC, 14 PDT, 23 CEST)
and place (#wikimedia-office).
A brief synopsis of the RFC:
* Need: we want anon visitors to browse multilingual wikis in their language
* Problem: Serving different renderings for the same URL messes with web caches.
* Solution: Encode uselang in the URL path, generate links to the same URL path.
Discussion points:
* Is the proposed solution viable and useful?
* Can we use varnish's xkey feature to purge all language versions of a page?
* What should the path scheme look like? /wiki-fr/Foo or /fr/Foo or...
* On which wiki shall we try this first?
* How do we make a wiki-link to a specific language version of a page?
If you are interested, please comment on the ticket[2] and join the meeting[1].
[1] https://phabricator.wikimedia.org/E384
[2] https://phabricator.wikimedia.org/T114662
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Hi everyone,
The voting has started on the 2016 Community Wishlist Survey, and all
Wikimedia contributors are invited to come and vote on the projects that
WMF's Community Tech team will work on next year:
https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey
There are 267 proposals this year, on a wide range of subjects that I'm
pretty sure you have an opinion about.
You've got two weeks to vote, from now through December 12th. You can vote
for as many proposals as you like, by adding a {{support}} tag under the
proposals that you think are worthwhile.
Once the voting's over, we'll have a ranked list of projects for the
Community Tech team to work on, as well as other developers and volunteers
who want to build features and make changes that the core contributors
really want.
This is an opportunity for you to help set the agenda for a WMF product
team, so I hope everybody comes and participates!
Danny Horn
WMF Product Manager
Community Tech
Hello,
Hovercards, currently a beta feature, is nearing release. [0] We'd like to
encourage communities to adopt Hovercards as a default option for
logged-out readers. [1] Hovercards provide a preview of any linked article,
giving readers a quick understanding of a related article without leaving
the current page. The Reading web team recently completed a series of A/B
tests to gather information on how Hovercards are used.
* April 2015 - Catalan and Greek A/B test results [2]
* Summer/Fall 2016 Hungarian, Italian, and Russian Wikipedia A/B test
results [3]
* 2016 Reading team UX research [4]
As you can see the results of the tests were generally positive. A few key
highlights:
* During the Catalan and Greek A/B test, 79% of respondents either Agreed
or Strongly Agreed that Hovercards were easy to use, 76% of respondents
either Agreed or Strongly Agreed that Hovercards were useful for their
needs.
* Users are viewing approximately 0.99 hovercards per session, and
interacting with approximately 31% more pages each session. [5]
* The disable rate was very low: the rate of clicking the settings cog for
Hovercards was 0.02% for Hungarian, 0.034% for Italian, and 0.016% for
Russian Wikipedia. The rates for disabling the feature were even lower.
* In our qualitative tests, 13 out of 15 questionnaire participants
reported positive experiences with Hovercards.
== Rollout plan ==
The next step for Hovercards is to develop a plan for rolling the feature
out to all projects. We have created a draft proposal for which projects to
discuss Hovercards with and approximate timeline for deployments. [6]
The Reading Web team will be reaching out to the communities in the order
listed above to discuss how to implement the feature. We want to enable the
feature by default for logged-out users and we will respect the current
beta feature preferences for logged-in users.
Questions and feedback welcome at Beta Features/Hovercards. [7]
Thank you for your time.
[0] https://www.mediawiki.org/wiki/Beta_Features/Hovercards
[1] Logged-out users would see Hovercards by default on wikis that opt-in.
Logged-out users may turn Hovercards off via the cog-icon displayed at the
bottom of each Hovercard. Logged-in users see Hovercards if they have
enabled the feature. New accounts created after the launch of Hovercards
would have it on by default (mimicking the default for logged-out users)
with the option to disable in Special:Preferences.
[2] https://www.mediawiki.org/wiki/Beta_Features/Hovercards/GreekCatalanTest
[3] https://www.mediawiki.org/wiki/Beta_Features/Hovercards/2016_A/B_Tests
[4]
https://www.mediawiki.org/wiki/Wikimedia_Research/Design_Research/Reading_T…
[5] With page interactions defined as the sum of average hovercards viewed
per session and average pages viewed per session
[6] https://www.mediawiki.org/wiki/Beta_Features/Hovercards#Rollout_Plan
[7] https://www.mediawiki.org/wiki/Talk:Beta_Features/Hovercards
Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
Hey,
With merge of 320328 [1] and 320341, two major changes will come to ORES
review tool:
1- You will see one more option in ORES sensitivity called "Lowest". It
means if you choose it, it only flags edit that are very likely to be
vandalism.
2- Coloring of rows will be completely different. You will see several
colors instead of one and as confidence of ORES grows, the colors will tend
to be more noticeable. It goes without saying that you can change these
colors in your own css. I put a screenshot in [3] and you can test it in
https://en.wikipedia.beta.wmflabs.org or https://mw-revscoring.wmflabs.org
Feedback is always welcome
[1]: https://gerrit.wikimedia.org/r/#/c/320328/
[2]: https://gerrit.wikimedia.org/r/#/c/320341/
[3]: https://phabricator.wikimedia.org/T144922#2824696
Best
--
Amir Sarabadani Tafreshi
Software Engineer (contractor)
-------------------------------------
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
http://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/681/51985.
Hi all,
Gerrit decided to crap itself this morning while doing garbage collection
on the repositories. As a result, you may have some issues when fetching
the latest objects from the repo. Right now MediaWiki core seems to be the
only repo noticeably affected, but I'm currently checking into the status
for all repositories.
Fresh clones are not affected. If you end up hitting a problem in fetching,
the following workaround should get you back in shape:
cp .git/config .git/config.backup
git remote remove origin
mv .git/config.backup .git/config
git fetch
Investigation is ongoing. If you hit any other repos than MW that seem to
be having issues, please chime in on
https://phabricator.wikimedia.org/T151676
Have a good weekend!
-Chad
Hi all!
I thought I'd resume the practice of sending a summary of the Architecture
Committee meeting to this list.
The minutes of Wedensday's meeting can be fond at
<https://www.mediawiki.org/wiki/Architecture_committee/2016-11-23>.
See also the ArchCom status page at
<https://www.mediawiki.org/wiki/Architecture_committee/Status> and the RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
Here are the minutes, for your convenience:
* ArchCom soon to meet Victoria (perhaps Dec 7)
* Robla resigns from ArchCom in the wake of leaving WMF. Daniel is doing the
chairing for now.
* Ongoing activity:
** Brion: mobile video
** Gabriel: thumbnail API (Gabriel), ServiceWorkers for the discovery portal
** Tim: replacing tidy
** Timo: oldime table refactoring
** Daniel: experimenting with the Interwiki overhaul, thinking about db schema
optimization
* Talking with Faidon about ArchCom scope, progess, and impact. Some key points
that came up:
** ArchCom should be more arcive in providing visions and guideleines, such as
high level architecture documents.
** ArchCom should be involved in more of the ongoing developemnt at WMF. People
tend to ask ArchCom only if they have to.
** ArchCom should not only get active when asked. ArchCom scruteny should not be
limited to RFC discussions.
** For RFC discussions, we too often focus on easy-to-decide topics with limited
impact
** Lack of ops perspective in ArchCom
** A clearer scope / charter would be helpful
** Role of ArchCom needs to be discussed with our new CTO
** ArchCom has no clear connection to WMF org chart, and no power in resourcing.
Platforms (mostly MediaWiki itself) are not well represented in the org chart.
* Up for next week’s IRC discussion: ''Per-language URLs for multilingual wiki
pages'' (T114662).
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Please comment on whether to approve the "Conflict of interest" section
of the draft Code of conduct for technical spaces. This section did not
reach not reach consensus earlier, but changes were made seeking to
address the previous concerns.
You can find the section at
https://www.mediawiki.org/w/index.php?title=Code_of_Conduct/Draft&oldid=229…
You can comment at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_new_vers…
.
A position and brief comment is fine.
You can also send private feedback to conduct-discussion(a)wikimedia.org .
I really appreciate your participation.
Thanks again,
Matt Flaschen
Hi all,
I would like to propose that we separate the bot right into bot and
boteditinterface, where the bot right only allows you to mark edits as
bot edits for non-mediawiki namespace edits and you would need the
boteditinterface right to mark any mediawiki namespace edits as a bot
edit. Furthermore, I would propose that nobody on Wikimedia wikis ever
get the boteditinterface right (But if I end up having to cave on that
requirement, at least we could restrict it to people who really need
it)
The idea being that any potential edit to site javascript should be
highly scrutinized and shown on the RC by default. Additionally, most
bots do not make edits to the MediaWiki namespace so this should not
cause an undue burden. Those that do make edits, do not make a super
large number. This proposal does not include edits made by
centralnotice extension, which will continue to be marked bot.
If you think this is a horrible idea, please object now :) For more
information see https://phabricator.wikimedia.org/T151408 . If there
are no major objections from the wikitech-l community, I also plan to
notify the owners of bots who make edits to mediawiki namespace.
Thanks,
Brian.