Dear Ambassadors,
I'm looking for volunteer wikis to try out the new search that Chad and
I've been working on called CirrusSearch.
<sales pitch>Be a part of the second wave of wikis and influence new search
features!</sales pitch>
Reality:
* We're reasonably sure CirrusSearch's language support is better than the
current search. [1]
* CirrusSearch indexes expanded templates.
* CirrusSearch indexes articles within a few seconds of when they are
changed. Articles that contain a changed template take longer but they are
also updated.
* Most of the special search syntax is the same. You can read the syntax
here: https://www.mediawiki.org/wiki/Search/CirrusSearchFeatures
What it means to volunteer:
If you volunteer your wiki we'll turn CirrusSearch on in "secondary" mode
where it'll keep itself up to date but all queries will still go through
the old search. You'll be able to get search results from the new search
engine for comparison by adding a url parameter to the search results
page. If you and the community that you represent aren't immediately blown
away by how much better it works we'll work with you to make it awesome.
At some point, shortly after the new search has been deemed awesome, we'll
switch CirrusSearch to "primary" mode and all queries will go through it.
You'll be able to get at the old search results with a url parameter
similar to the one that you used to test CirrusSearch. If anything goes
wrong we'll switch you back to the old search. We'll keep that option open
for a few months.
So who is ready to help make search better?
Nik Everett
[1]: Some languages (20ish) will see a huge improvement because
CirrusSearch understands their grammar and old search doesn't. Many other
languages will see an improvement because CirrusSearch is happy to search
all kinds of character sets while the current search isn't. Esperanto is
very well supported by the old search so would get worse. eo wikis should
probably wait until we've improved support.
We have merged a couple changes so that jQuery UI is not loaded by code
that doesn't need it. See
https://bugzilla.wikimedia.org/show_bug.cgi?id=55550 for details.
That means gadgets and user scripts that use jQuery UI should explicitly
load the appropriate module.
https://www.mediawiki.org/wiki/Extension:Gadgets has info on adding
gadget dependencies.
User scripts can use mw.loader.using
(https://www.mediawiki.org/wiki/RL/DM#mw.loader.using).
A list of jquery.ui modules is at
https://www.mediawiki.org/wiki/RL/DM#jQuery_UI .
There is one remaining issue that may affect a few wikis. If your wiki
uses jquery.ui buttons in wikitext, the styles will not be loaded unless
something explicitly loads or depends on jquery.ui.
If you notice styles missing from your wiki, you can add:
// Load jquery.ui.button so button styles work in wikitext
mw.loader.using( 'jquery.ui.button' );
to the site Common.js
Don't do this unless it's actually needed, since this does have a
performance impact (although it is not loading all of jquery.ui). If
you do add it, please include the comment so people know why it's being
loaded.
This will roll out to the test wikis, plus MW.org, 2013-10-31, the
remaining non-Wikipedia wikis the 4th, and the Wikipedias, the 7th.
Matt Flaschen
TL;DR: We're starting to remove long-deprecated methods. First, they'll be wrapped in mw.log.deprecate (possibly replaced with dummy values) which will produce a stacktrace to the console when used. Example: http://cl.ly/image/3W0o131K0D3j
Pre-amble:
* As of MediaWiki 1.17 we started actively developing new javascript features.
* Any code from before that point has been tagged "legacy" and deprecated as of v1.17.0 back in 2011.
Problems:
* There is no easy way to see whether a page is using any of these deprecated interfaces.
* We still haven't removed any of the legacy code.
* Though we've added new things (jQuery, jQuery UI, mw.Title, mw.Uri etc.). We've been reluctant to iterate further on these "new" things and haven't been able to really refactor or improve them.
We've upgraded jQuery and jQuery UI a few times. But only because there were no major changes in backwards compatibility. This changed in 1.9 and that's why we're still on 1.8.
It would seem we're in a fixed position – unable to move up, only sideways. On the server-side of MediaWiki, deprecation has been a natural process enforced socially (plugins not maintained for several release cycles will simply have to be disabled). We introduce the new, we migrate uses of the old, we deprecate the old, we support both for uses for a while to allow others to migrate their stuff, then we remove the old.
In the front-end we never completed such a cycle. But, we're getting close to the completion of our first first cycle now. The legacy scripts deprecated as of v1.17.0 have all been removed or wrapped in mw.log.deprecate.
Please go to your favourite wiki in debug=true mode with a modern browser (recent Chrome, Firefox or Opera) and look at the console. Look for any uncaught exceptions, deprecation notices or other messages and try to address them soon (or report it to the maintainers of the gadgets triggering them).
-- Krinkle
[1] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.log-method-dep…
On Tue, Oct 29, 2013 at 1:22 PM, Konstantinos Stampoulis
<geraki(a)geraki.gr> wrote:
> 2013/10/29 Dan Garry <dgarry(a)wikimedia.org>
>>
>> How would you suggest we tackle this problem?
>>
>
> Echo can be a good alternative.
> Imagine a new notification for every user, a "global notice" (not a talk
> page message)
> This can be sent to registered users, with its own icon, a notification
> message with text simillar to what it would be included in a banner, and
> linking to the relevant page (instead of own talk page etc).
> So, every user will get it only once, but he can go back to it by clicking
> the notifications icon.
>
> mockup: https://commons.wikimedia.org/wiki/File:Echo-centralnotice.png
>
Yes, that could be a great idea, in particular when combined with some
kind of topic-specific opt-in and opt-out.
There has been quite a bit of thinking about technical solutions to
this kind of problem, including hope that Echo and/or Flow could play
a role in them. See e.g. the material at
https://www.mediawiki.org/wiki/Movement_broadcasting , in particular
the linked Wikimania presentations from this year (by Andrew Gray) and
last year (by myself).
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
On 29 October 2013 16:26, Dan Garry <dgarry(a)wikimedia.org> wrote:
> On the one hand, the WMF often gets accused of failing to communicate
> properly and consistently with the Wikimedia community. On the other hand,
> when consistent communication is attempted though things like these
> notices, some people can get frustrated and tune out.
Since 2008 I recommend better communication from WMF towards communities as local communities feel not being informed well enough. I personally think it is very good that WMF tries to communicate, but seeing how local users more and more start to react on the banners we should consider using other ways of communication towards the local communities, otherwise the communication works against WMF.
Seeing how the local users react on all the notices they get, I think that we should limit the number of notices and use other methods. Local users expect that the banners are only used as exception.
> How would you suggest we tackle this problem? Simply not using these
> notices any more would lead to reducing our communication with the
> community, so without a better solution, we can't really disable the
> notices.
Using more notices will lead to reducing the communication as more and more users will block the CentralNotice, or even whole wikis will block all CentralNotices. (Today in the discussion the negative comments named the banner(s) as unwanted spam. I have seen how discussions in the past can get out of control with users getting more and more annoyed resulting in blocking messages for everyone, I tried to reply as damage control on the Dutch Wikipedia.)
At this moment it is difficult or impossible to have a solution ready tomorrow, but we should try to have better ways in the near future. Perhaps the best way is to have a (product?) team or something like that working on it. I am happy to help with that and give feedback. Perhaps a special team that tries to improve the communication inside the Wikimedia movement.
I see currently two ways of receiving information by communities on their wikis:
1. CentralNotice: too many notices will result in banner blindness and blocking notices as they are very disturbing often on every page.
2. Posting in central discussion/notifications page on a wiki: a lot of users will see that notice but also many users do not see them.
To me there is a gap between CentralNotice messages on one side and on the other hand the postings in central discussion/notifications page. I think we should get a way to notify every user targeted just as with the CentralNotice: if needed geo specific, translated, etc but isn't shown as big banner on every page.
In September I supported the implementation of the Notifications system (Echo) by announcing and explaining to the local community what was going to change and how it works, and even while that system has minor issues it is considered very much as a success by the community of nl-wiki.
I think a nice way to tackle the problem is by having the Notifications tool expanded with the ability to receive there notices like with the FDC.
Romaine
(tech ambassador for nl Wikipedia)
On the Dutch Wikipedia users have indicated that they perceive the number of Global Notices too much and the more that happens the more users will start to add code to their preferences to fully block every notice as they are so tired of them.
The current load of negative feedback about the banners is currently coming up after the especially the FDC banners
Every week a new notice is considered too much.
I already noticed earlier that there is also some kind of banner blindness for many users: they get a banner on pages but do not look at them any more just as it are adds.
This time several users got a notice in English what was perceived disturbing.
Also they experience getting banners as not interesting for Wikipedia.
As bonus I personally and other users have experienced that clicking away a banner made the banner appear again within the hour visiting other pages. I had that at least four times on a project, on several projects. Re-appeasring after being clicked away is useless and disturbing.
Also it is annoying that I need to click the same banners away on each project I visit, many users visit Wikipedia, but also work on Commons, Wikidata, etc.
I think the the CentralNotice should be redesigned or the CentralNotice will loose it effectiveness. Something is really going wrong.
Romaine
(tech ambassador for nl Wikipedia)
Your help promoting the Free and Open Source Outreach Program for Women
is welcome. We are looking for candidates to become full-time interns in
a Wikimedia tech project between December and March. We are also looking
for mentors and projects. See the details below.
Thank you!
-------- Original Message --------
Subject: FOSS Outreach Program for Women: call for candidates, projects,
and mentors
Date: Thu, 24 Oct 2013 15:02:37 -0700
From: Quim Gil <qgil(a)wikimedia.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
PLEASE FORWARD TO WHOEVER MIGHT BE INTERESTED
Wikimedia will participate in the FOSS Outreach Program for Women -
Round 7. Interns of this program work full time in an open source
project during 3.
https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women
Candidates interested are encouraged to add themselves to the table at
https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7#Candidates
- even if you are still preparing your proposal.
We are actually running late (my fault). The application process is open
until November 11. The internship period goes from December 10 to March
10, 2014.
The Wikimedia Foundation is planning to fund up to 8 interns. This is a
great opportunity for Wikimedia / MediaWiki related projects. Our
process is quite simple: define a project, find the mentors and go for it!
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projectshttps://www.mediawiki.org/wiki/Mentorship_programs/Possible_mentors
The previous featured projects and confirmed mentors have been moved
respectively to the Raw and Bench sections. If you want to participate
in this OPW round move the entries back to the featured sections.
New projects and mentors are welcome too, of course!
If you have any questions please ask.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello Nik,
About a week ago I explained the nl-wikipedia community on the central discussion page about your message and asked them the question.
The result of the short poll is 19 users say yes to test, 4 say no, 2 say neutral.
In general they experience the current search limited and would like to see it improved. 2 of who say no have no problems with the current search and say that something does not need to be fixed if it isn't broken, while the visual editor should be fixed first as that one is broken much more on nl-wiki (yes the VE is a huge problem with messing up pages, but that is another subject). Apparently those two do not have the experience that the search is limited. Two others say no as they have had worse experiences with the visual editor (just as everyone else on nl-wiki: we had a poll on VE which clearly stated that the VE was absolutely working worse and hit a big gap in the trust in the developers), and would like to be assured that the new search isn't having too big bugs that disrupt searching normally.
In general saying there is a large majority for testing. Certainly for secondary testing at first, if it is stable enough also for testing in primary modus.
Romaine
---
tech ambassador for nl-wiki
[Wikitech-ambassadors] Would any other wikis like to try out a new search?
Nikolas Everett neverett at wikimedia.org
Thu Oct 17 19:49:08 UTC 2013
Dear Ambassadors,
I'm looking for volunteer wikis to try out the new search that Chad and
I've been working on called CirrusSearch.
<sales pitch>Be a part of the second wave of wikis and influence new search
features!</sales pitch>
Reality:
* We're reasonably sure CirrusSearch's language support is better than the
current search. [1]
* CirrusSearch indexes expanded templates.
* CirrusSearch indexes articles within a few seconds of when they are
changed. Articles that contain a changed template take longer but they are
also updated.
* Most of the special search syntax is the same. You can read the syntax
here: https://www.mediawiki.org/wiki/Search/CirrusSearchFeatures
What it means to volunteer:
If you volunteer your wiki we'll turn CirrusSearch on in "secondary" mode
where it'll keep itself up to date but all queries will still go through
the old search. You'll be able to get search results from the new search
engine for comparison by adding a url parameter to the search results
page. If you and the community that you represent aren't immediately blown
away by how much better it works we'll work with you to make it awesome.
At some point, shortly after the new search has been deemed awesome, we'll
switch CirrusSearch to "primary" mode and all queries will go through it.
You'll be able to get at the old search results with a url parameter
similar to the one that you used to test CirrusSearch. If anything goes
wrong we'll switch you back to the old search. We'll keep that option open
for a few months.
So who is ready to help make search better?
Nik Everett
[1]: Some languages (20ish) will see a huge improvement because
CirrusSearch understands their grammar and old search doesn't. Many other
languages will see an improvement because CirrusSearch is happy to search
all kinds of character sets while the current search isn't. Esperanto is
very well supported by the old search so would get worse. eo wikis should
probably wait until we've improved support.
FYI.
Here's the latest edition of the deploy highlights for next week.
Let me know if something isn't clear.
Greg
----- Forwarded message from Greg Grossmeier <greg(a)wikimedia.org> -----
> Date: Fri, 25 Oct 2013 16:18:22 -0700
> From: Greg Grossmeier <greg(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Development and Operations engineers <engineering(a)lists.wikimedia.org>
> Subject: Deployment highlights - week of October 28th
>
> Hello and welcome to the latest edition of the WMF deployment
> highlights.
>
> The full list of planned deployments can be found here:
> https://wikitech.wikimedia.org/wiki/Deployments#Next_Week
>
> And for a look of what is on the horizon, see:
> https://wikitech.wikimedia.org/wiki/Deployments#Next_Month
>
>
> Here are the highlights:
>
>
> == Sometime early week ==
>
> * We'll begin serving Oceania traffic for Wikipedias from the newly
> deployed San Francisco caching datacenter. There should not be any
> downtime but please let us know if you live in the region commonly
> referred to as Oceania (https://en.wikipedia.org/wiki/Oceania) and
> experience any issues.
>
>
> == Monday ==
>
> * Deploy of the Redis-based Federated JobQueue
> https://bugzilla.wikimedia.org/show_bug.cgi?id=49788
>
> * MediaWiki 1.23wmf1 to all non-Wikipedia sites
> https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_depl…
>
>
> == Tuesday ==
> * CirrusSearch will be enabled on Wikidata as the secondary/non-default
> search engine.
> https://www.mediawiki.org/wiki/Extension:CirrusSearch
> https://www.mediawiki.org/wiki/Search#Timeline
>
>
> == Thursday ==
> * MediaWiki 1.23wmf1 to all Wikipedias
> * MediaWiki 1.23wmf2 to all testwikis
> https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap#Schedule_for_the_depl…
>
>
> As always, please let me know if you have any questions.
>
> Greg
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
