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.
I was reading http://stateofjs.com/2016/introduction/#sections and
could not avoid noticing that the frameworks or technologies we use
are not among the most popular or most liked among the participants of
this survey.
Examples:
* Frontend frameworks: We use jQuery and OOjs UI. The latter does not
appear at all in the list, jQuery is not in the top ten. This question
might be biased though on what people perceive as a framework.
* Testing framework: We mostly use qUnit, Cucumber, Selenium. Of these
only Cucumber appears in the top 6 and it has very low satisfaction
(people who have used do not like it).
* CSS tools: We use plain CSS and Less. Less has considerable lower
satisfaction than SASS/SCSS and is less popular.
* Build tools: We don't use these in core to my knowledge, but many
extensions seem to use Grunt for running linting tools. Again, Grunt
has very low satisfaction compared to other tools.
It is natural, that as large and complex project we do not jump to the
latest cool thing. I am not advocating to change tools that work well
for us, but I don't remember seeing a public discussion whether they
work well or not. Though, I am seeing some changes, for example
jscs+jshint being replaced with eslint.
We could possibly go faster or write better software with better tools
(of course this would need a careful evaluation). And while doing that
we could perhaps lower the barrier for new developers by using
something they already know. The topic of how to attract new
developers to our movement has been popular lately (for example [1]).
[1] https://phabricator.wikimedia.org/T148911
----
For me one pain point is automated testing of JavaScript code. It
seems that testing frameworks, development practices and the way code
is written could all be improved to make automated testing easier.
Would there be interest in sharing comments how you do this and does
what you do work well for you?
-Niklas