Hi everyone,
I have been talking to some third-party users trying to learn more about what they would like to see happening in MediaWiki in the near future. Here is a list of the things on the wish list, with the ones on top being more popular.
Please let me know if you know of an existing extension or another solution for these problems, if you are currently working on something similar or would be interested to, or if you have any general comments/feedback you would like to share. I did some searching and included what I found but I have no experience with the mentioned extensions so I am not sure how relevant/stable they are.
1. WYSIWYG editor - VisualEditor is in progress !
2. Integrated access control: ability to hide some pages from the groups of users. Fine grained read access in the wiki. Some extensions that I found addressing the problem. Extension:AccessControl http://www.mediawiki.org/wiki/Extension:AccessControl- has a security disclaimer Extension:Access_Control_Panel http://www.mediawiki.org/wiki/Extension:Access_Control_Panel- an old beta Extension:Access_Control_List http://www.mediawiki.org/wiki/Extension:Access_Control_List- developers site down
3. More modern skins included in MediaWiki or at least easier extension development and maintenance. Are there any skin suits you know of and would recommend? Any good skinning resources ? e.g. http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/ 4. The implementation of Semantic MediaWiki on mediawiki.org website in order to manage easily extensions pages.
5. Wiki-markup editor for template gurus - with autocompletion, syntax highlight, template parameters suggestions: more like markup IDE.
6. An easy way to share wiki content on social media services. Extension:AddThis http://www.mediawiki.org/wiki/Extension:AddThis - seems like a solution, any opinions? Also: Extension:Facebook http://www.mediawiki.org/wiki/Extension:Facebook - just Facebook Extension:WikiShare http://www.mediawiki.org/wiki/Extension:WikiShare - unstable version, seems like it's not worked on any more
7. Built in support for Google Analytics Extension:Google_Analytics_Integrationhttp://www.mediawiki.org/wiki/Extension:Google_Analytics_Integration(latest version 2009) http://karenfreemansmith.com/2011/02/10/adding-google-analytics-mediawiki/
8. Built in support for XML Sitemaps without using command line Extension:GoogleNewsSitemaphttps://www.mediawiki.org/wiki/Extension:GoogleNewsSitemap
9. Built in support for Google Adsense in popular layout positions Extension:Google_AdSense_2http://www.mediawiki.org/wiki/Extension:Google_AdSense_2
10. Easy way of gracefully retiring old tags (e.g. Google Maps extension is no longer supported, replaced with Maps which has different tags)
11. Update to the documentation about creating a simple extension that is XSS safe.
12. Mobile version for website that turns with MediaWiki - this is in progress http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
13. MediaWiki Core API. "Not the HTTP-API but the set of PHP classes in the core that are less likely to change in the next version. Core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler."
Sorry for the long email and thank you if you made it here. The alternative was to send many emails and I thought that would be too spammy :) More to come soon !
Mariya
Am Montag, 28. Januar 2013, 14:07:45 schrieb Maria Miteva:
Hi everyone,
I have been talking to some third-party users trying to learn more about what they would like to see happening in MediaWiki in the near future. Here is a list of the things on the wish list, with the ones on top being more popular.
<snip>
- Easy way of gracefully retiring old tags (e.g. Google Maps extension is
no longer supported, replaced with Maps which has different tags)
Just to have it mentioned, the replace text extension (https://www.mediawiki.org/wiki/Extension:Replace_Text ) makes it a sharm for admins to bunch-replace outdated tags with new ones. We had that problem once with one of the syntaxhighlighting extensions and a switch to the new one.
- Update to the documentation about creating a simple extension that is
XSS safe.
- Mobile version for website that turns with MediaWiki - this is in
progress http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
- MediaWiki Core API.
"Not the HTTP-API but the set of PHP classes in the core that are less likely to change in the next version. Core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler."
Sorry for the long email and thank you if you made it here. The alternative was to send many emails and I thought that would be too spammy :) More to come soon !
Mariya
Cheerio, Ingo Malchow -- (neverendingo) KDE Community Working Group, KDE User Working Group KDE Community Forums Administrator New to KDE Software? - get help from http://userbase.kde.org or ask questions on http://forum.kde.org
Hi Maria! Let me clarify the situation about access control. There are several dozens of ways (!) to get the information of a wiki page - and that's only in the core! And what's about extensions? Each of them is responsible for access control by itself, therefore each of them provides another couple of ways to access any content you want. I'm pretty sure that now it's impossible to create a reliable (the one you can store your credit card number) Access Control extension without hacking and patching the core - and aftyer that some ways to get the data still remains. The WMF position here is the following: "if you need access control, if you want to hide some stuff from some groups of users - get out of here and choose another wiki engine." If you're asking us about our problems - here is one of the most depressing problem of all.
So when the 3rd parties ask about supporting the access control restrictions they basically ask WMF to think again about this dogma that "MediaWiki was born to be open and this openness will remain forever". We want to store personal and sensitive data in wikis, create systems with premium accounts, we want to restrict the read access to some articles and we want to be sure that it's impossible to get access to these data neither from client code, nor from extensions. I think I've expressed everyone's thoughts, correct me if I'm wrong.
Very truly yours, Yury Katkov, WikiVote! 28.01.2013 16:19 пользователь "Ingo Malchow" imalchow@kde.org написал:
Am Montag, 28. Januar 2013, 14:07:45 schrieb Maria Miteva:
Hi everyone,
I have been talking to some third-party users trying to learn more about what they would like to see happening in MediaWiki in the near future.
Here
is a list of the things on the wish list, with the ones on top being more popular.
<snip> > 10. Easy way of gracefully retiring old tags (e.g. Google Maps extension is > no longer supported, replaced with Maps which has different tags)
Just to have it mentioned, the replace text extension (https://www.mediawiki.org/wiki/Extension:Replace_Text ) makes it a sharm for admins to bunch-replace outdated tags with new ones. We had that problem once with one of the syntaxhighlighting extensions and a switch to the new one.
- Update to the documentation about creating a simple extension that is
XSS safe.
- Mobile version for website that turns with MediaWiki - this is in
progress http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
- MediaWiki Core API.
"Not the HTTP-API but the set of PHP classes in the core that are less likely to change in the next version. Core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with
slow
deprecation. A role model for that is Python compiler."
Sorry for the long email and thank you if you made it here. The
alternative
was to send many emails and I thought that would be too spammy :) More
to
come soon !
Mariya
Cheerio, Ingo Malchow -- (neverendingo) KDE Community Working Group, KDE User Working Group KDE Community Forums Administrator New to KDE Software? - get help from http://userbase.kde.org or ask questions on http://forum.kde.org
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 01/28/2013 11:26 AM, Yury Katkov wrote:
The WMF position here is the following: "if you need access control, if you want to hide some stuff from some groups of users - get out of here and choose another wiki engine." If you're asking us about our problems - here is one of the most depressing problem of all.
Despite this, MediaWiki has grown far beyond the WMF. For instance, Semantic MediaWiki -- which the Foundation does not use -- is at the point where it could be considered a fork of MW.
There are enough non-WMF-but-core MW developers that enhancements to make our favorite Wiki software into software that supports robust access control are feasible.
It would take some committed effort, probably require subsidizing the development from the funds collected from interested people, but it is certainly something that is possible to implement without WMF support.
Would something like KickStarter work here?
On 01/28/2013 08:56 AM, Mark A. Hershberger wrote:
Would something like KickStarter work here?
... and would a MediaWiki Group 3rd Parties (choose your better name) also work? To coordinate interests, use the Wikimedia movement tools (e.g. grants) and make sure your voice is heard within the community.
Maria, I found your list to be very helpful. Thanks for putting that together!
On Mon, Jan 28, 2013 at 8:26 AM, Yury Katkov katkov.juriy@gmail.com wrote:
Hi Maria! Let me clarify the situation about access control. There are several dozens of ways (!) to get the information of a wiki page - and that's only in the core! And what's about extensions? Each of them is responsible for access control by itself, therefore each of them provides another couple of ways to access any content you want. I'm pretty sure that now it's impossible to create a reliable (the one you can store your credit card number) Access Control extension without hacking and patching the core
- and aftyer that some ways to get the data still remains. The WMF position
here is the following: "if you need access control, if you want to hide some stuff from some groups of users - get out of here and choose another wiki engine." If you're asking us about our problems - here is one of the most depressing problem of all.
From my personal perspective (not speaking as a WMF representative), I
don't think it would be too much work to support some level of access control in core-- at least standardizing how read access is checked, and then making sure it's checked for each read. Defining the granularity, making sure there's community consensus on it, and auditing extensions for compliance (and somehow marking those extensions as compliant) would take some work. But we already essentially do this for edit access ("blocked users should not be able to edit" is one of our access control policies, and we do a pretty good job of enforcing it throughout the code). Also, auditing access to make sure that policy is being followed would take some work, but is probably not insurmountable as an option in core or an extension.
However, making sure that all core and extension developers are on board with the same idea of what policy should be followed so that code from now on complies with whatever policy is chosen is going to take a lot of training, persuasion, and could even prevent new developers from getting involved if it's treated as more valuable than their contributions.
So I think it's totally possible, but it's not (in my mind at least) so much of a code or feature task as it is a culture and consensus of policy problem. Which I think is a much more difficult problem to solve, but I do hope I'm wrong about that.
- Update to the documentation about creating a simple extension that is
XSS safe.
This, however, I think I can make happen :)
Chris, in what way was the list helpful? I am asking because it might give me a better idea of whom to share it with/ how to move on with it.
About access control I see the problem is not technical but rather cultural. Is this something that is under discussion in WMF or is it absolutely set that it's against WMF policy? Can it be brought up to discuss? If it's not for the "dogma" against access control I imagine some consensus can be reached with conversation.
*>> > 11. Update to the documentation about creating a simple extension that is
XSS safe.
* *This, however, I think I can make happen :)*
Make happen sounds great:) Do you need help? Anything I can do? ( I can't really help with the documentation itself but maybe I can help with something organizational).
Mariya
On Mon, Jan 28, 2013 at 8:15 PM, Chris Steipp csteipp@wikimedia.org wrote:
Maria, I found your list to be very helpful. Thanks for putting that together!
On Mon, Jan 28, 2013 at 8:26 AM, Yury Katkov katkov.juriy@gmail.com wrote:
Hi Maria! Let me clarify the situation about access control. There are several dozens of ways (!) to get the information of a wiki page - and that's only in the core! And what's about extensions? Each of them is responsible for access control by itself, therefore each of them provides another couple of ways to access any content you want. I'm pretty sure
that
now it's impossible to create a reliable (the one you can store your
credit
card number) Access Control extension without hacking and patching the
core
- and aftyer that some ways to get the data still remains. The WMF
position
here is the following: "if you need access control, if you want to hide some stuff from some groups of users - get out of here and choose another wiki engine." If you're asking us about our problems - here is one of the most depressing problem of all.
From my personal perspective (not speaking as a WMF representative), I don't think it would be too much work to support some level of access control in core-- at least standardizing how read access is checked, and then making sure it's checked for each read. Defining the granularity, making sure there's community consensus on it, and auditing extensions for compliance (and somehow marking those extensions as compliant) would take some work. But we already essentially do this for edit access ("blocked users should not be able to edit" is one of our access control policies, and we do a pretty good job of enforcing it throughout the code). Also, auditing access to make sure that policy is being followed would take some work, but is probably not insurmountable as an option in core or an extension.
However, making sure that all core and extension developers are on board with the same idea of what policy should be followed so that code from now on complies with whatever policy is chosen is going to take a lot of training, persuasion, and could even prevent new developers from getting involved if it's treated as more valuable than their contributions.
So I think it's totally possible, but it's not (in my mind at least) so much of a code or feature task as it is a culture and consensus of policy problem. Which I think is a much more difficult problem to solve, but I do hope I'm wrong about that.
- Update to the documentation about creating a simple extension
that is
XSS safe.
This, however, I think I can make happen :)
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Wed, Jan 30, 2013 at 4:06 AM, Mariya Nedelcheva Miteva mariya.miteva@gmail.com wrote:
Chris, in what way was the list helpful? I am asking because it might give me a better idea of whom to share it with/ how to move on with it.
As a WMF employee, it's helpful to hear what our other users want from MediaWiki. I think at the foundation, the internal demands are the ones I hear most about, followed by when I hear from someone in the WMF community who is very passionate about their one issue getting addressed. So having one list from many voices I think helps to see the broader picture.
About access control I see the problem is not technical but rather cultural. Is this something that is under discussion in WMF or is it absolutely set that it's against WMF policy? Can it be brought up to discuss? If it's not for the "dogma" against access control I imagine some consensus can be reached with conversation.
I'm not aware of any conversations in the WMF about it, nor do I think it's a policy. I think it's more just how we've done it in the past, and some fresh conversation (preferably with some numbers, like how many other sites with how many visitors/mo who want certain features) would be welcome.
*>> > 11. Update to the documentation about creating a simple extension that is
XSS safe.
*This, however, I think I can make happen :)*
Make happen sounds great:) Do you need help? Anything I can do? ( I can't really help with the documentation itself but maybe I can help with something organizational).
Any more details from the people who made the request would be nice-- like is this for an extension with a special page vs parser functions?
Mariya
On Mon, Jan 28, 2013 at 8:15 PM, Chris Steipp csteipp@wikimedia.org wrote:
Maria, I found your list to be very helpful. Thanks for putting that together!
On Mon, Jan 28, 2013 at 8:26 AM, Yury Katkov katkov.juriy@gmail.com wrote:
Hi Maria! Let me clarify the situation about access control. There are several dozens of ways (!) to get the information of a wiki page - and that's only in the core! And what's about extensions? Each of them is responsible for access control by itself, therefore each of them provides another couple of ways to access any content you want. I'm pretty sure
that
now it's impossible to create a reliable (the one you can store your
credit
card number) Access Control extension without hacking and patching the
core
- and aftyer that some ways to get the data still remains. The WMF
position
here is the following: "if you need access control, if you want to hide some stuff from some groups of users - get out of here and choose another wiki engine." If you're asking us about our problems - here is one of the most depressing problem of all.
From my personal perspective (not speaking as a WMF representative), I don't think it would be too much work to support some level of access control in core-- at least standardizing how read access is checked, and then making sure it's checked for each read. Defining the granularity, making sure there's community consensus on it, and auditing extensions for compliance (and somehow marking those extensions as compliant) would take some work. But we already essentially do this for edit access ("blocked users should not be able to edit" is one of our access control policies, and we do a pretty good job of enforcing it throughout the code). Also, auditing access to make sure that policy is being followed would take some work, but is probably not insurmountable as an option in core or an extension.
However, making sure that all core and extension developers are on board with the same idea of what policy should be followed so that code from now on complies with whatever policy is chosen is going to take a lot of training, persuasion, and could even prevent new developers from getting involved if it's treated as more valuable than their contributions.
So I think it's totally possible, but it's not (in my mind at least) so much of a code or feature task as it is a culture and consensus of policy problem. Which I think is a much more difficult problem to solve, but I do hope I'm wrong about that.
- Update to the documentation about creating a simple extension
that is
XSS safe.
This, however, I think I can make happen :)
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
This is a wontfix according to https://bugzilla.wikimedia.org/show_bug.cgi?id=8390#c24
Alex
On 28/01/13 12:07, Maria Miteva wrote:
- The implementation of Semantic MediaWiki on mediawiki.org website in
order to manage easily extensions pages.
Is a wontfix final? It seems that mw.org itself might be a different case from the other WMF project websites.
Mariya
On Mon, Jan 28, 2013 at 6:09 PM, Krenair krenair@gmail.com wrote:
This is a wontfix according to https://bugzilla.wikimedia.** org/show_bug.cgi?id=8390#c24https://bugzilla.wikimedia.org/show_bug.cgi?id=8390#c24
Alex
On 28/01/13 12:07, Maria Miteva wrote:
- The implementation of Semantic MediaWiki on mediawiki.org website in
order to manage easily extensions pages.
______________________________**_________________
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.**org MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/mediawiki-lhttps://lists.wikimedia.org/mailman/listinfo/mediawiki-l
3.) I like the erudite skin.
________________________________ From: Maria Miteva mariya.miteva@gmail.com To: MediaWiki announcements and site admin list mediawiki-l@lists.wikimedia.org Sent: Monday, January 28, 2013 5:07 AM Subject: [MediaWiki-l] Third-Party Users Wish List - Does Anyone Know of Existing/Experimental Solutions?
Hi everyone,
I have been talking to some third-party users trying to learn more about what they would like to see happening in MediaWiki in the near future. Here is a list of the things on the wish list, with the ones on top being more popular.
Please let me know if you know of an existing extension or another solution for these problems, if you are currently working on something similar or would be interested to, or if you have any general comments/feedback you would like to share. I did some searching and included what I found but I have no experience with the mentioned extensions so I am not sure how relevant/stable they are.
1. WYSIWYG editor - VisualEditor is in progress !
2. Integrated access control: ability to hide some pages from the groups of users. Fine grained read access in the wiki. Some extensions that I found addressing the problem. Extension:AccessControl http://www.mediawiki.org/wiki/Extension:AccessControl- has a security disclaimer Extension:Access_Control_Panel http://www.mediawiki.org/wiki/Extension:Access_Control_Panel- an old beta Extension:Access_Control_List http://www.mediawiki.org/wiki/Extension:Access_Control_List- developers site down
3. More modern skins included in MediaWiki or at least easier extension development and maintenance. Are there any skin suits you know of and would recommend? Any good skinning resources ? e.g. http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/ 4. The implementation of Semantic MediaWiki on mediawiki.org website in order to manage easily extensions pages.
5. Wiki-markup editor for template gurus - with autocompletion, syntax highlight, template parameters suggestions: more like markup IDE.
6. An easy way to share wiki content on social media services. Extension:AddThis http://www.mediawiki.org/wiki/Extension:AddThis - seems like a solution, any opinions? Also: Extension:Facebook http://www.mediawiki.org/wiki/Extension:Facebook - just Facebook Extension:WikiShare http://www.mediawiki.org/wiki/Extension:WikiShare - unstable version, seems like it's not worked on any more
7. Built in support for Google Analytics Extension:Google_Analytics_Integrationhttp://www.mediawiki.org/wiki/Extension:Google_Analytics_Integration(latest version 2009) http://karenfreemansmith.com/2011/02/10/adding-google-analytics-mediawiki/
8. Built in support for XML Sitemaps without using command line Extension:GoogleNewsSitemaphttps://www.mediawiki.org/wiki/Extension:GoogleNewsSitemap
9. Built in support for Google Adsense in popular layout positions Extension:Google_AdSense_2http://www.mediawiki.org/wiki/Extension:Google_AdSense_2
10. Easy way of gracefully retiring old tags (e.g. Google Maps extension is no longer supported, replaced with Maps which has different tags)
11. Update to the documentation about creating a simple extension that is XSS safe.
12. Mobile version for website that turns with MediaWiki - this is in progress http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
13. MediaWiki Core API. "Not the HTTP-API but the set of PHP classes in the core that are less likely to change in the next version. Core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler."
Sorry for the long email and thank you if you made it here. The alternative was to send many emails and I thought that would be too spammy :) More to come soon !
Mariya _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi Al,
What do you like about it? I guess not just the looks of it but also something about the implementation? Are there any best practices that can be learned from it?
Mariya
On Mon, Jan 28, 2013 at 9:07 PM, Al Johnson alj62888@yahoo.com wrote:
3.) I like the erudite skin.
From: Maria Miteva mariya.miteva@gmail.com To: MediaWiki announcements and site admin list < mediawiki-l@lists.wikimedia.org> Sent: Monday, January 28, 2013 5:07 AM Subject: [MediaWiki-l] Third-Party Users Wish List - Does Anyone Know of Existing/Experimental Solutions?
Hi everyone,
I have been talking to some third-party users trying to learn more about what they would like to see happening in MediaWiki in the near future. Here is a list of the things on the wish list, with the ones on top being more popular.
Please let me know if you know of an existing extension or another solution for these problems, if you are currently working on something similar or would be interested to, or if you have any general comments/feedback you would like to share. I did some searching and included what I found but I have no experience with the mentioned extensions so I am not sure how relevant/stable they are.
WYSIWYG editor - VisualEditor is in progress !
Integrated access control: ability to hide some pages from the groups of
users. Fine grained read access in the wiki. Some extensions that I found addressing the problem. Extension:AccessControl http://www.mediawiki.org/wiki/Extension:AccessControl- has a security disclaimer Extension:Access_Control_Panel http://www.mediawiki.org/wiki/Extension:Access_Control_Panel- an old beta Extension:Access_Control_List http://www.mediawiki.org/wiki/Extension:Access_Control_List- developers site down
- More modern skins included in MediaWiki or at least easier extension
development and maintenance. Are there any skin suits you know of and would recommend? Any good skinning resources ? e.g. http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/ 4. The implementation of Semantic MediaWiki on mediawiki.org website in order to manage easily extensions pages.
- Wiki-markup editor for template gurus - with autocompletion, syntax
highlight, template parameters suggestions: more like markup IDE.
- An easy way to share wiki content on social media services.
Extension:AddThis http://www.mediawiki.org/wiki/Extension:AddThis - seems like a solution, any opinions? Also: Extension:Facebook http://www.mediawiki.org/wiki/Extension:Facebook - just Facebook Extension:WikiShare http://www.mediawiki.org/wiki/Extension:WikiShare - unstable version, seems like it's not worked on any more
- Built in support for Google Analytics
Extension:Google_Analytics_Integration< http://www.mediawiki.org/wiki/Extension:Google_Analytics_Integration
(latest
version 2009) http://karenfreemansmith.com/2011/02/10/adding-google-analytics-mediawiki/
- Built in support for XML Sitemaps without using command line
Extension:GoogleNewsSitemap< https://www.mediawiki.org/wiki/Extension:GoogleNewsSitemap%3E
- Built in support for Google Adsense in popular layout positions
Extension:Google_AdSense_2< http://www.mediawiki.org/wiki/Extension:Google_AdSense_2%3E
- Easy way of gracefully retiring old tags (e.g. Google Maps extension is
no longer supported, replaced with Maps which has different tags)
- Update to the documentation about creating a simple extension that is
XSS safe.
- Mobile version for website that turns with MediaWiki - this is in
progress http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
- MediaWiki Core API.
"Not the HTTP-API but the set of PHP classes in the core that are less likely to change in the next version. Core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler."
Sorry for the long email and thank you if you made it here. The alternative was to send many emails and I thought that would be too spammy :) More to come soon !
Mariya _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org