Re: [Wikitech-l] Bikeshed 5: The Painter Strikes Back
On 16/06/13 05:43, Brian Wolff wrote: On 6/16/13, Tyler Romeo tylerro...@gmail.com wrote: It's 10 times slower than doing === null, which is a bit trivial in context, but nonetheless a fact, and it's also a bit easier to read, especially when doing the inverse (i.e., doing !is_null( ... ) versus !== null). Also, there's no functional difference between the two. Easier to read is debatable. !is_null( $foo ) reads directly like an english sentence Not is null. Ok, maybe an english sentence with bad grammar, but I hardly find it unclear. I'd say it's easier to read because ! is the same size and shape as i so !is_null() may easily be overlooked as is_null(), while !== sticks out from === ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bikeshed 5: The Painter Strikes Back
Hey, On the colour of the bikeshed: !== generally reads better then !is_null. $foo is not null vs is not null $foo. I however object against constructing this shed in the first place. Seems like a waste of good mental effort, on which some much nicer buildings can be constructed. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcing the Wikimedia technical search tool
No, DXR doesn't help the CSE. I also doubt it will help restoring full text search on our end, but we'll see. https://bugzilla.wikimedia.org/show_bug.cgi?id=49674 On the contrary, gitblit is more robust and faster than gitweb, so it allows crawling by search engines. It was crawled very quickly so I added the repos to the search tool on the 10th. https://www.mediawiki.org/w/index.php?title=Wikimedia_technical_searchdiff=708290oldid=663882 Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Deployment Highlights - Week of June 17th
I disagree with the last three messages: the visual editor is bound to be painful when enabled; if the team has established that they're in a stage where they are done with the knowns in some areas but need more testing on the field (and feedback) to discover more, they must be allowed to, otherwise they'll surely lose time, not working on important issues they couldn't predict. I'm not able to make such an assessment, but I read today a discussion on it.wiki where it was noted how only 132 edits were made with the visual editor. It's impossible, for the community (or anyone) on any given wiki, to gain any confidence in the tool as long as its usage is at such negligible levels. VE is useless for power users, so we can only try with newbies. I don't know if new accounts are the best choice, maybe it should be triggered only after the 10th edit (we know at this point the survival rate is much better); but this can be changed any time, I guess. Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Deployment Highlights - Week of June 17th
Federico Leva (Nemo) wrote:
I disagree with the last three messages: the visual editor is bound to
be painful when enabled; if the team has established that they're in a
stage where they are done with the knowns in some areas but need more
testing on the field (and feedback) to discover more, they must be
allowed to, otherwise they'll surely lose time, not working on important
issues they couldn't predict.
You seem to be mis-reading. :-) The issue isn't a dearth of known issues
in VisualEditor, it's the opposite: there are a lot of known issues in
VisualEditor that will easily trip up new editors.
I agree with you that once VisualEditor is in a place where there are
fewer known issues, further testing and trialling will certainly elicit
useful bug reports and actionable items.
However, just as an example, currently templates such as {{lowercase
title}} are trivial to destroy, as they have no output in VisualEditor, so
an extra press of the deletion key can easily remove them.
In addition, Parsoid has issues with template parameter and HTML attribute
normalization, sometimes resulting in dirty diffs. And there are
occasionally spurious nowiki tags inserted into the edit area.
VE is useless for power users, so we can only try with newbies. I don't
know if new accounts are the best choice, maybe it should be triggered
only after the 10th edit (we know at this point the survival rate is
much better); but this can be changed any time, I guess.
I wouldn't characterize VisualEditor as useless for power users. I've used
it occasionally and I imagine it'll become more popular in time. Have you
tried VisualEditor?
Can you explain how to set a user preference based on the number of edits
a new user has? Has the VisualEditor team set up a script to roll back
(i.e., undo) this change to the user preferences of new users if this
experiment doesn't work well? Personally, I think it would be a little
crazy to press forward with this experiment on June 19 as planned.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Deployment Highlights - Week of June 17th
Can you explain how to set a user preference based on the number of edits a new user has? Has the VisualEditor team set up a script to roll back (i.e., undo) this change to the user preferences of new users if this experiment doesn't work well? Personally, I think it would be a little crazy to press forward with this experiment on June 19 as planned. Based on what I have seen the few times I have fooled around in Visual Editor (not sure if I actually saved any edits or just said screw this and went with the regular editor), I also think that this is a bit premature. If we need additional feedback, rather than automatically enabling it for half of the new editors, or even half of the new editors with X number of edits, we could provide a notice to new editors with X number of edits that asks them if they would like to try Visual Editor. We could provide a notice at the top of Visual Editor to allow them to easily change the preference back as well. While this doesn't solve the template issue (and the clean-up that will inevitable come of that), it might work as a solution to the getting new users to test VE issue. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Deployment Highlights - Week of June 17th
The fact that there are known issues doesn't mean that finding new, unknown issues will slow down the work on the known; it's up to the team to decide what sort and what amount of feedback they'll be able/need to process (and to adjust if they were wrong). Gradually enabling a feature is not an experiment on some poor victims, it's a normal development strategy (as opposed to sudden revolutions/waterfalls on the wikis). I still don't see any indication of why it should raise the end net harm of the VE development on the wikis. I don't know how to enable the preference at some point of users' lifecycle; probably, in the same way you do it for half new users. A hook I assume, it was mentioned in some Echo and enotif bugs. Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deprecating use of the style attribute (part 1)
Thanks to Matt and Daniel for your input so far. I would really appreciate some more heads commenting/voting on this so it is possible to start building this... Thanks in advance! Jon https://mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates On Thu, Jun 13, 2013 at 2:05 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 06/13/2013 02:57 PM, Brian Wolff wrote: That's an important point you forgot to mention in your original proposal. I assumed you wanted this to be editable by everyone :) I think it should simply follow the permissions of the accompanying page. That way, people can develop templates in their userspace (it needs to provide for that if it's limited to certain namespaces). Little used templates are generally not protected, and the same should follow for the CSS. This does imply the sanitization needs to work. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Automating Main Page with Lua
Turning back to the automating thing and the Main Page. I've got tired updating the Other Wikipedias section (congratulations to the Swedish Wikipedia!), so I wrote some code to automate the job. There is a bot that updates different statistics per wiki. I decided to parse the data page and push it through a mediawiki message to avoid hard-coded pieces of text inside. Here we have to expensive parts: getContent() for a template with necessary data, and retrieving a message for the view. Is it OK to have expensives at the Main Page? The module is placed here: http://goo.gl/3V5St -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Automating Main Page with Lua
On 2013-06-17 4:20 PM, Paul Selitskas p.selits...@gmail.com wrote: Turning back to the automating thing and the Main Page. I've got tired updating the Other Wikipedias section (congratulations to the Swedish Wikipedia!), so I wrote some code to automate the job. There is a bot that updates different statistics per wiki. I decided to parse the data page and push it through a mediawiki message to avoid hard-coded pieces of text inside. Here we have to expensive parts: getContent() for a template with necessary data, and retrieving a message for the view. Is it OK to have expensives at the Main Page? The module is placed here: http://goo.gl/3V5St -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l [Just personal opinion. Not an official answer] - main page is cached like any other page. The expensive function is more a deterrent against someone putting 1000 such calls on a page. A single getContent should not be an issue, even on a widely viewed page. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WMF Engineering Roadmap Updates - 2013-06-14
See the full Roadmap at: http://www.mediawiki.org/wiki/Roadmap And the diff for this last update: http://www.mediawiki.org/w/index.php?title=Roadmapdiff=711356oldid=711338 Highlights: = Search = * With the new search engineer on board, Nik, working with Chad on search the current plan for rolling out the Solr-backed search engine is thus: ** June: prototype in Labs ** July: deployed to test2.wikipedia ** Aug: deployed to mediawiki.org ** Oct: deployed to English Wikipedia ** Dec: deployed to all wikis = Performance = * With other performance options still on the table, we are looking closely at HipHop and hope to have the ability to use it by August of this year. ** See also: https://www.mediawiki.org/wiki/Site_performance_and_architecture = Authentication Systems = * Complete CentralAuth/SUL revamp in June * In July do OAuth deployment, OpenID development, and limited OpenID provider deployment for use in Labs Best, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Search documentation
https://www.mediawiki.org/wiki/Requests_for_comment/CirrusSearch This made me realize I have a poor sense of the features in search, so I read the documentation. http://www.mediawiki.org/wiki/Help:Searching is bare-bones, and https://en.wikipedia.org/wiki/Help:Searching disagrees. Perhaps the former describes the default MediaWiki search features, while WMF has enabled more and different features on its wikis (such as intitle: and incategory: searches). * mw help doesn't mention the * suffix to search for partial matches, or the ~ prefix. Both work on my unmodified local wiki. * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I fixed mw search's explanation of the two-button search box (no longer the default) but I don't know the details on the above. -- =S Page software engineer on Editor Engagement Experiments ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search documentation
On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote: * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I did some research a few weeks ago on the current state of Search and there are a number of discrepancies between the documentation and actual behavior. Some of them have BZ tickets, like https://bugzilla.wikimedia.org/show_bug.cgi?id=44238 -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] migrating hooks doc to doxygen?
Le 04/06/13 18:00, Antoine Musso a écrit : Hello, Since we introduced hooks in MediaWiki, the documentation has been maintained in a flat file /docs/hooks.txt . Over the week-end I have converted the content of that file to let Doxygen recognize it. The patchset is: https://gerrit.wikimedia.org/r/#/c/66128/ snip After two weeks, it seems the single objection against converting the plain text to Doxygen format is the markup format when reading the flat file. On the other hands a few people like the HTML output and some people praised this change either over IRC or by private mail. Regardless of where we should maintain the doc, is there anything preventing the change to land in? Please cast your voice :) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search documentation
I'm not sure about http://www.mediawiki.org/wiki/Help:Searching but https://en.wikipedia.org/wiki/Help:Searching has lots of things we're going to have to add to our list. My guess is http://www.mediawiki.org/wiki/Help:Searching is simply out of date. Nik On Mon, Jun 17, 2013 at 4:33 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote: * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I did some research a few weeks ago on the current state of Search and there are a number of discrepancies between the documentation and actual behavior. Some of them have BZ tickets, like https://bugzilla.wikimedia.org/show_bug.cgi?id=44238 -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC coding starts officially today! (was Re: GSoC Mentor Summit)
On 06/13/2013 01:07 PM, Quim Gil wrote: Dear GSoC mentors: Here is a heads up about the GSoC Mentor Summit: https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_mentors#GSoC_Mentor_Summit Nobody signed up? I'm sure we can fill the 2 seats only with WMF employees based in San Francisco, but... Anyway, since today the GSoC bonding period is officially over and everybody should have started working on development tasks. Is this the case? With an implicit heads up for the completion of the community bonding period: https://www.mediawiki.org/wiki/Summer_of_Code_2013#Community_bonding_period So far Aarti, Molly, Moriel and Pragun have marked this first milestone as completed: https://www.mediawiki.org/wiki/Summer_of_Code_2013#Projects According to the GSoC table there are 8 out 20 students that haven't completed the bonding period yet. Is it just about updating the table or is there more? If you start letting things slip now it will be more difficult to catch up as weeks pass. We will have a GSoC/OPW IRC AllHands next week. Tentative: Wednesday, June 26, 2013 at 15:00 UTC (8:30pm IST, 8am PDT) http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130626T08p1=224ah=1 In addition to this, I will meet all the student/mentors teams one by one via videoconference. Happy coding! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search documentation
Just as a note, MediaWiki default (aka crappy) search is very different from the lucene stuff used by Wikimedia. Lucene search is rather difficult to set up, so most third party wikis do not use it. --bawolff On 6/17/13, Nikolas Everett never...@wikimedia.org wrote: I'm not sure about http://www.mediawiki.org/wiki/Help:Searching but https://en.wikipedia.org/wiki/Help:Searching has lots of things we're going to have to add to our list. My guess is http://www.mediawiki.org/wiki/Help:Searching is simply out of date. Nik On Mon, Jun 17, 2013 at 4:33 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote: * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I did some research a few weeks ago on the current state of Search and there are a number of discrepancies between the documentation and actual behavior. Some of them have BZ tickets, like https://bugzilla.wikimedia.org/show_bug.cgi?id=44238 -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search documentation
One of our goals while building this has been to make something reasonably easy to install by folks outside of WMF. I've added some notes about this to the page. I'd certainly love to hear ways that'd make it simpler to use. Nik On Mon, Jun 17, 2013 at 8:23 PM, Brian Wolff bawo...@gmail.com wrote: Just as a note, MediaWiki default (aka crappy) search is very different from the lucene stuff used by Wikimedia. Lucene search is rather difficult to set up, so most third party wikis do not use it. --bawolff On 6/17/13, Nikolas Everett never...@wikimedia.org wrote: I'm not sure about http://www.mediawiki.org/wiki/Help:Searching but https://en.wikipedia.org/wiki/Help:Searching has lots of things we're going to have to add to our list. My guess is http://www.mediawiki.org/wiki/Help:Searching is simply out of date. Nik On Mon, Jun 17, 2013 at 4:33 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote: * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I did some research a few weeks ago on the current state of Search and there are a number of discrepancies between the documentation and actual behavior. Some of them have BZ tickets, like https://bugzilla.wikimedia.org/show_bug.cgi?id=44238 -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Deployment Highlights - Week of June 17th
Hi, The interest of the VE team is not the only one to take into account I think... The impact on the new wikipedia editors should be a more important parameter in my opinion. I tried VE a few times, and clearly think it's not yet in a situation where it could be rolled out to unexperienced users : * VE is still very limited in what you can do with it (no templates, no references, ...). What will be the reaction of a new user when he sees that he can't edit some parts of the article ? * VE is still quite buggy (adding nowiki tags, deleting references, modifying templates, ...). While it's not a problem with users that opted-in for testing, it's quite different for users that don't even know what VE is. * Beta testers made a few suggestions for enhancements that would be quite helpful for editors (like being able to choose between VE and wikitext when editing a given section and not globally, ...) Why do you want to rush a forced test on new users when VE is not yet a stable, fully functional product ? You mentionned the low number of edits with VE currently. I think it's low because of the problems mentionned above, not because of a lack of testers. I saw several users do like me: try it, see that many editions can't be made or end up with side effects, report the problems, and use again the wikitext waiting for the problems to be solved in a next version. I do believe than once VE is stable and has more features, people will start to use it more widely. Has there been any analysis done to foresee the impact on new users that would have VE enabled by default ? Like taking a few hours or a day of modifications on enwiki, keeping only the modifications made by users registered in the last few days, and try to do the exact same modification with VE : * What percentage of modifications could be achieved with the current set of features available in VE ? * What percentage of modifications would have been done without undesired side effects ? That would give an idea on how many new users would run into problems with VE (for me, they are very low, but I'm not a new user). With the current version of VE, I believe both those percentages will be low, implying many new users will have problems. Nico On Mon, Jun 17, 2013 at 12:12 PM, Federico Leva (Nemo) nemow...@gmail.comwrote: The fact that there are known issues doesn't mean that finding new, unknown issues will slow down the work on the known; it's up to the team to decide what sort and what amount of feedback they'll be able/need to process (and to adjust if they were wrong). Gradually enabling a feature is not an experiment on some poor victims, it's a normal development strategy (as opposed to sudden revolutions/waterfalls on the wikis). I still don't see any indication of why it should raise the end net harm of the VE development on the wikis. I don't know how to enable the preference at some point of users' lifecycle; probably, in the same way you do it for half new users. A hook I assume, it was mentioned in some Echo and enotif bugs. Nemo __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search documentation
I think that from user perspective, such help pages are not very useful since most users don't read help pages. Some features (the important ones) should be hinted in the search form itself. In hewiki we modified the [[MediaWiki:Search-summary]][1] to include a small expandable table with hints for features (intitle/incategory e.g). Eran [1] http://he.wikipedia.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:Search-summary?uselang=en On Tue, Jun 18, 2013 at 3:40 AM, Nikolas Everett never...@wikimedia.orgwrote: One of our goals while building this has been to make something reasonably easy to install by folks outside of WMF. I've added some notes about this to the page. I'd certainly love to hear ways that'd make it simpler to use. Nik On Mon, Jun 17, 2013 at 8:23 PM, Brian Wolff bawo...@gmail.com wrote: Just as a note, MediaWiki default (aka crappy) search is very different from the lucene stuff used by Wikimedia. Lucene search is rather difficult to set up, so most third party wikis do not use it. --bawolff On 6/17/13, Nikolas Everett never...@wikimedia.org wrote: I'm not sure about http://www.mediawiki.org/wiki/Help:Searching but https://en.wikipedia.org/wiki/Help:Searching has lots of things we're going to have to add to our list. My guess is http://www.mediawiki.org/wiki/Help:Searching is simply out of date. Nik On Mon, Jun 17, 2013 at 4:33 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote: * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I did some research a few weeks ago on the current state of Search and there are a number of discrepancies between the documentation and actual behavior. Some of them have BZ tickets, like https://bugzilla.wikimedia.org/show_bug.cgi?id=44238 -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
