Hi Multimedia enthusiasts, Commonists, and Wikitechers,
The Multimedia team has been hard at work building a new extension for
editing images on-wiki, and we believe we now have a workable demo
running on Labs! You can find it on our Multimedia Alpha Wiki[0], where
there are also instructions for testing.
Note that we have a list of known bugs and failings on that wiki, and we
are working on getting those fixed before we push the extension into any
kind of deployment - our next steps will likely be to put it on
test2wiki, then to push a BetaFeature to Commons if all goes well. We
will keep you updated with the status of the project as we progress.
If you find more bugs, or have concerns about this extension, you can
share them on the Village Pump[1]. You can also file a Phabricator task
against ImageTweaks[2] if you prefer to be in more direct contact with
the team about a technical issue.
Thanks for helping us test new stuff, and I look forward to getting this
great tool out to you soon!
[0] http://multimedia-alpha.wmflabs.org/wiki/index.php/Main_Page
[1]
https://commons.wikimedia.org/wiki/Commons:Village_pump#ImageTweaks_extensi…
[2]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=ImageTwea…
--
Mark Holmquist
Lead Engineer
Multimedia Team
Wikimedia Foundation
http://marktraceur.info
I've been doing a lot of thinking about products that have been built in
the past years, discussions that we are having about current developments
and about future projects.
And I noticed that I really needed to put some of that down somewhere
public. So I have created the following:
https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Analysis
A place to analyse things we have right now, both in software, content and
process. To figure out why they are how they are, what they mean, break
them down into parts. Knowing things like this will help us build better
products.
https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Concepts
A place where I want to log some product ideas that I have been considering
for a while.
These places are meant to inspire discussion, strategy, design, as well as
document.
Additionally, I would like to point out that Risker has been writing down a
checklist for products from her perspective, which I think is a great idea
and welcome more people to do. Hopefully, such checklists can be
consolidated into a more 'formalized' standard (a bit like we also have
code conventions) eventually to be used for the WMF product development
process <https://www.mediawiki.org/wiki/WMF_product_development_process>.
https://en.wikipedia.org/wiki/User:Risker/Risker%27s_checklist_for_content-…
DJ
(cross-posting)
Reminder that these lightning talks are happening tomorrow, Tuesday
February 16, at 1900 UTC / 11:00 AM Pacific. Because there are 3 presenters
and a 1-hour block of time, each presenter has about 15 minutes including
time for questions. We might finish early.
On the agenda:
* Pine: "LearnWIki" Instructional video series on Wikipedia mechanics
(Including VE and citoid) and community practices
<https://meta.wikimedia.org/wiki/Grants:IEG/Motivational_and_educational_vid…>
* Madhu Viswanathan: "Counting unique devices accessing Wikipedia projects
using Last access method"
* Rosemary Rein: "Program Capacity and Learning-Building a Roadmap Together"
<https://commons.wikimedia.org/wiki/File:Program_Capacity_and_Learning_Roadm…>
Hope to see you there!
Pine
On Tue, Feb 2, 2016 at 5:47 PM, Kevin Leduc <kevin(a)wikimedia.org> wrote:
> Thanks for forwarding Pine! I welcome any 10 minute talks from GLAM and
> Education as well. If you add your name to the list [1], email me as well
> so I can contact you and forward notes for Lightning Talk speakers.
>
> [1] https://www.mediawiki.org/wiki/Lightning_Talks#February_2016
>
> On Tue, Feb 2, 2016 at 4:59 PM, Pine W <wiki.pine(a)gmail.com> wrote:
>
>> Boldly forwarding* in case others would like to view or present a
>> lightning talk. I plan to give a lightning talk about the video series
>> <https://meta.wikimedia.org/wiki/Grants:IEG/Motivational_and_educational_vid…>
>> which I'm in the process of producing with the support of an individual
>> engagement grant.
>>
>> Although these talks can be about technical topics like video formats, I
>> think that there are education and GLAM activities that could fit under the
>> umbrella as well, especially if they have technical or research aspects.
>> For example, I'll probably focus much of my presentation on my background
>> research and project design process.
>>
>> Hope to see you there!
>> Pine
>>
>> * To boldly forward where no one has forwarded before
>>
>> ---------- Forwarded message ----------
>> From: Kevin Leduc <kevin(a)wikimedia.org>
>> Date: Tue, Feb 2, 2016 at 4:23 PM
>> Subject: [Wikitech-l] Fwd: February 2016 Lightning Talks
>> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>>
>>
>> ---------- Forwarded message ----------
>> From: Kevin Leduc <kevin(a)wikimedia.org>
>> Date: Tue, Feb 2, 2016 at 4:22 PM
>> Subject: February 2016 Lightning Talks
>> To: "Staff (All)" <wmfall(a)lists.wikimedia.org>
>>
>>
>> Hi All,
>>
>>
>> The next Lightning Talks are scheduled for February 16th (two weeks from
>> today). We hope at least 4 people will sign up for the talks by Friday
>> February 12th otherwise we will postpone them another month. Lightning
>> Talks are an opportunity for teams @ WMF & in the Community to showcase
>> something they have achieved: a quarterly goal, milestone, release, or
>> anything of significance to the rest of the foundation and the movement as
>> a whole.
>>
>>
>> Each presentation will be 10 minutes or less including time for questions.
>>
>> Sign up here:
>> https://www.mediawiki.org/wiki/Lightning_Talks#February_2016
>>
>>
>> Next round of Lightning Talks:
>>
>> When: Tuesday February 16, 1900 UTC
>> <
>> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks&is…
>> >,
>> 11am PST (We have added this Lightning Talk to the WMF Engineering, Fun &
>> Learning, and Staff calendars)
>>
>> Where: 5th Floor
>>
>> Remotees: On-Air google hangout will be provided just before the meeting
>>
>> IRC: #wikimedia-tech
>>
>> YouTube stream: http://www.youtube.com/watch?v=D3fyCgBWvFc
>>
>>
>> Thanks!
>>
>> Kevin Leduc, Megan Neisler, Brendan Campbell
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>
Puppet has been disabled on iridium (The server hosting
phabricator.wikimedia.org) for some time now due to broken deployment
configuration.
We (Myself and Ariel) are going to attempt to re-enable puppet today at
20:00 UTC (Noon, Pacific), taking advantage of the lower than normal level
of activity on Phabricator due to the US Holiday. There shouldn't be any
noticeable downtime, however, phabricator might respond with 5xx errors or
become unresponsive for a short time around 20:10. Maintenance should be
finished before 20:30.
I apologize for the short notice, this should have been sent out on Friday.
Although I do not expect this to cause any issues, please do let me know if
you notice any new issues after the maintenance is complete.
Hi, we need to define our ask for WMF developer events in the next fiscal
year. This includes the future of the Wikimedia Developer Summit.
If you are interested in this topic, please check
https://phabricator.wikimedia.org/T126972
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
To enable Single Sign-On to a MediaWiki hosted on IIS in a Windows Domain, the best MediaWiki extension I could find was NTLMActiveDirectory.
https://www.mediawiki.org/wiki/Extension:NTLMActiveDirectory
However, I had two peeves with this extension:
1) Its name; I'm not doing NTLM, but Negotiate and Kerberos; and
2) Its use of LDAP; feels too much like a wart on Windows!
See, I'm sitting on an IIS box on a Windows domain with Integrated Windows Authentication enabled. By the time the MW extension gets hit, IIS has already authenticated the user, so why not just leverage that instead?
I therefore used NTLMActiveDirectory as a starting point, but threw out all the LDAP stuff and replaced it with a simple Web call to an IIS-hosted handler to get the AD group membership for the already authenticated user. Of NTLMActiveDirectory, I kept the AD / MW group mapping configuration required for authorization.
Personally, I find this solution much simpler and intuitive for AD integration when hosting MW on a Windows/IIS box.
Does this make sense to others in the community?
Do others feel there was a need for a better AD integration extension?
Would others in the community benefit from such an extension?
If so, I would be happy to share my work, following instructions found here:
https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment
Regards,
François
Executive summary:
CI tests won't run for a while tomorrow. Also you won't be able to
log into Wikitech. This will begin at 16:00 UTC (8:00 AM in California)
and may take a couple of hours.
Full story:
As part of a long-overdue tech-debt payment[0], I'll be migrating
all of the Labs project, membership and role data from ldap into
mysql[1]. Keystone (the Labs Openstack authentication layer) will be
shut off briefly, and subsequently will have incomplete data while
things are gradually copied over from Ldap.
At the same time, Alex will be rolling out a bunch of
OpenStackManager patches[2] to cope with the new reality. I've tested
these quite a lot, but no doubt there will be unexpected issues with
such a big refactor.
Existing, running labs and tools sessions should not be affected.
New instance creation will be disabled for part of the window, which
will prevent CI from starting new tests. Wikitech login will be
disabled, and users will have to login afresh after logins are restored.
There is, unfortunately, no user-facing improvement associated with
this update. If all goes perfectly, Wikitech will be restored to its
original state but be slightly slower. If, after the update, anyone
encounters new Wikitech issues (and I emphasize the NEW), please open a
phab ticket and inform me immediately.
As always, in the worst case scenario you can refer to our doc site
of last resort, https://wikitech-static.wikimedia.org
-Andrew
[0] https://phabricator.wikimedia.org/T115029
[1] https://wikitech.wikimedia.org/wiki/Labs_keystone_roles
[2] The patchset begins with https://gerrit.wikimedia.org/r/#/c/252615/
Hi,
I plan to try and use a big (~67K entries) table as a "database" in a
LUA script, with a basic lookup function. One call of the module would
be well within the time and memory limits, but I'm worried for pages
that might invoke the module several hundred times, so I did an
experiment with only a single entry in the table and the results are
encouraging:
1 call:
Lua time usage 0.006/10.000 seconds
Lua memory usage 513 KB/50 MB
10 calls:
Lua time usage 0.010/10.000 seconds
Lua memory usage 873 KB/50 MB
100 calls:
Lua time usage 0.074/10.000 seconds
Lua memory usage 1,35 MB/50 MB
There are obviously some optimizations there and I would be curious
what they are? Do you use some CoW or other trick to prevent loading
that table 100 times? Do you have the loading/parsing process
documented somewhere?
Thanks,
Strainu
Hi!
In order to make prefix search better, and to bring all variants of
prefix search under one roof, we did some refactoring in the search
engine implementation, so that various prefix searches now use the same
code path and all use the SearchEngine class.
The changes are as follows:
SearchEngine gets the following new API functions:
* public function completionSearch( $search ) - implements prefix
completion search, returns SearchSuggestionSet
* public function completionSearchWithVariants( $search ) - implements
prefix completion search including variants handling, returns
SearchSuggestionSet.
* public function defaultPrefixSearch( $search ) - basic prefix search
without fuzzy matching, etc., to be used in scenarios like special pages
search, etc. Returns Title[].
The implementation does not have to implement all three methods
differently, they can all use the same code if needed.
The default implementation still supports the PrefixSearchBackend hook
but we plan to deprecate it, and the CirrusSearch implementation does
not use it anymore. Instead, there is a private function, protected
function completionSearchBackend( $search ), which implementations
(including CirrusSearch) should implement to provide search results.
SearchEngine implementations can make use of services provided by the
base SearchEngine including:
- namespace resolution and normalization. The
PrefixSearchExtractNamespace hook is still supported for engines wishing
to implement namespace lookup not featured in the standard implementation.
- fetching titles for result sets (the implementing engine does not have
to fetch titles from DB for suggestions)
- result reordering to ensure exact matches are on top
- basic prefix search implementation using the database
- Special: namespace search implementation
== Deprecations ==
We plan to deprecate the PrefixSearchBackend hook and classes
TitlePrefixSearch and StringPrefixSearch. We will keep those classes
around for basic search fallback implementation and for old extensions,
but no new code should be using these classes, instead they should use
SearchEngine APIs described above. Mediawiki code has already been fixed
to do that. Extensions implementing search engines should also extend
SearchEngine and override the APIs above. CirrusSearch is the example of
how to do it.
== Show me the code ==
The patches implementing the refactoring are linked from:
https://phabricator.wikimedia.org/T121430
Pretty version of the same:
https://www.mediawiki.org/wiki/User:Smalyshev_(WMF)/Suggester
If you have questions on this, please contact the Discovery team:
https://www.mediawiki.org/wiki/Wikimedia_Discovery#Communications
--
Stas Malyshev
smalyshev(a)wikimedia.org