Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
149 discussions

Deployment Highlights - Week of October 7th
by Greg Grossmeier 04 Oct '13

04 Oct '13

Hello! You know the drill. Full schedule: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_October_7th == Monday == * VisualEditor turned on by default for the following 26 wikis for all users: Bulgarian (bg), Catalan (ca), Cebuano (ceb), Czech (cs), Danish (da), Estonian (et), Basque (eu), Finnish (fi), Galician (gl), Croatian (hr), Hungarian (hu), Indonesian (id), Latvian (lv), Malay (ms), Norwegian - Nynorsk (nn), Norwegian - Bokmål (no), Simple English (simple), Slovak (sk), Slovenian (sl), Turkish (tr), Ukrainian (uk), Volapük (vo), Waray-Waray (war), Modern Greek (el), Neopolitan (nap), Venetian (vec), Sicilian (scn) * GettingStarted/GuidedTour bug fix == MediaWiki Train == * Normal MediaWiki 'train' of upgrades. 1.22wmf20 to non-Wikipedia sites (Commons, Wiktionaries, etc) on Monday. 1.22wmf20 to all Wikipedias on Thursday. 1.22wmf21 branched and deployed to test wikis on Thursday. See: https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl… Note: Yes, there isn't a whole lot of non-standard deploys next week, hence only the call out of Monday's deploys. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Re: [Wikitech-l] Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)
by Terry Chay 04 Oct '13

04 Oct '13

(reposting: held in moderation because of recipient list) I am posting this to wikitech-l, ee-l, and will cross-post this to https://bugzilla.wikimedia.org/show_bug.cgi?id=35306 because it's important to keep frank discussions in the open. When I use to loaded words like "back-dooring" etc, I believe that no malice was intended and the discussions so far have been in good faith from all parties. I think people have a valid concern and want it addressed and are wondering honestly how decisions have been made. In particular, my decision to not allow the MassMessage Extension to roll out onto MediaWiki last week, since that occurred during a meeting that didn't even involve or derive have consultation (except ex-post-facto) with any product manager or engineer here. Here is why I am inijating this thread: 1) https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=83188&old… 2) On Sep 30, 2013, at 4:25 PM, MZMcBride <z(a)mzmcbride.com> wrote: > Hi Fabrice, Terry, and Howie, > > https://bugzilla.wikimedia.org/show_bug.cgi?id=35306#c19 is awaiting feedback (if you have any). > > MZ 3) https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=84903&old… … We have two separate but related bugs here: https://bugzilla.wikimedia.org/show_bug.cgi?id=35306 https://bugzilla.wikimedia.org/show_bug.cgi?id=52723 bug 35306 is an tracking bug MZMcBride posted for a solution to deal with EdwardsBot. I believe it dates to around the time I was first employed almost two years ago. bug 52723 is a recent bug to deploy Legoktm's MassMessage extension as a solution to bug 35306, it is less than a month old there has been little public discussion, and until it appeared on the deploy calendar last week, I wasn't even aware of its existence. The problem with moving on bug 52723 as a solution to bug 35306 is it commits Features Engineering to maintaining an extension that is a stop gap solution with no or very little discussion in a manner that doesn't serve a broad strategic goal about how messages, notifications, etc. should be handled on the wikis. To the first, maybe there is something wrong with my e-mail client, but I have yet to find this discussion on wikitech-l or anywhere outside the bug. Because of the above, my view is that this solution is being back-doored in and just moves the "technical debt" from one sheet (the community and tool labs) to another that has even less capability. I am biased against that because the latter sheet (WMF Features Engineering) is my responsibility. This is just my view, I'm open for us coming to consensus on a solution for this bug, but what I have seen is not consensus. It is along these lines that, I asked to remove MassMessage from the deploy calendar when it was added to the deploy calendar without discussion from Features, Design, or Product last week. After discussion during that Friday meeting among the EPMs, I compromised to let it to go out on two test wikis, but not on mediawiki. Nobody made the case that it should go out on mediawiki. I demurred because no person at the WMF, including me as Director of Features Engineering, should fiat a decision when unaware of the status of discussions involved. But let frank: if this had been a WMF employee writing this extension, it wouldn't have made it to even the test wikis by a country mile. In fact, a lot of extensions have been written by employees and either have extensive discussion, review, and buy-in (e.g. GuidedTours), or have not been deployed (e.g. Etherpad, the org chart, BetaFeatures) even though much more work has been done on them. I also don't like that WMF resources in Platform and Design are being spent to review something that has had no adequate discussion over in the annual plan, in anyone's 20% time, in any cross-team discussion, or public discussion on wikitech-l (There was a last minute thread in the Design list, I am not on the design list, nor should I be, and the Creative Director is new and the team is just trying to get their sea legs and some consideration to that needs to be done here). Furthermore, after further discussion, nearly all of Product felt I should not have compromised earlier because the following situation might occur: Having gotten it onto "the cluster" people would then move to back-door it into deployment on the basis that it's already on the cluster. Their prediction is occurring right now. This is a bogus argument because nobody agreed this should be on the cluster, it's just that nobody has reviewed it in a thorough enough manner to shout "NO!" If necessary, I'm going to shout "NO!" at this moment. Having said that, there is the larger issue of bug 35306 which has been sitting there unsolved for a while as well as the smaller issue of the month's work Legoktm and MZMcBride have already put into Bug 52723 and [[mw:Extension:MassMessage]] possibly going to waste if I keep blocking it. Besides, MZ is sitting there trying to hold everything up on his own shoulders with EdwardsBot, and we all know it. … Let me address the functionality overlap with Echo: LanguageEngineering built their own parallel message/notification system before Echo that lives on Meta today. They commit to supporting their own parallel message/notification system, and I'm okay with it living outside Echo (where it currently does), but there is an understanding that they've basically committed to that work with no support from Features for the duration that it does live outside Echo. In those lines, I'm glad that Platform has helped out here, but unless Platform is committing to support MassMessage indefinitely into the future and not just provide one-time security and deploy assistance, I'm not okay with them adding to Features work even though they've been super helpful to MZMcBride and Legoktm. If Dan Garry is willing to commit Platform to support MassMessage, I'll think the same precedent we've done with LE applies here. Furthermore, before *in-echo, outside-echo, use-echo) for a solution to be bug 35306, it needs to actually exhibit product discipline. The WMF gets panned for having a "agile processes" but not actually doing so, but we do have some process and we need to at least apply the same product discipline that we apply everywhere else to this bug. For example, features in MassMessage and EdwardsBot need to be addressed in a Must-Have, Should-Have, Could-Have, Won't-Have (MoSCoW) framework. Features like "mass delivery from a list" are probably a Must-Have; features like "cross-wiki notification" are probably a should-have, other features like "public over private notifications", "page-centric over user-centric" or "longer stream notifications" are either not a must-have or could have or are should-haves to be done outside Echo by a different service (bot) using the Echo API or some extension thereof. All that is a product issue, and I nor anyone in my team is in product. Those decisions should be done in discussion with the Product team and they should not be disintermediated from it, which they have been. I understand that many people would like to see a solution to Bug 35306 would be great to have. I'd like to see a better Signpost notification system and a more generalized solution for newsletter delivery also! I'd also like a pony. But we have already committed resources and continue to commit resources without discussion from the people (Product Design, not Features Engineering) who have been tasked with this responsibility and are very good at these sort of thing. I hope everyone participating on this bug can see that dropping this bomb on a newly hired associate product manager is simply not cool on so many levels. … Here is my suggestion: (This is thinking, not a directive so don't think of this as definitive or final, I'm seeking consensus here.) First, bug 35306 is a long-standing request. I think it's important we get headway on this, but I hope others will be understanding if it doesn't happen immediately, so long as there is a commitment for this to happen. (For perspective, Flow was first proposed years ago, and was added to the annual plan almost two years ago before their first actual development sprint was completed (end of this week!). Echo was first deployed almost 8 months ago and is still not out on all the wikis. BetaFeatures has been in discussion for months and is still not deployed, nor is the commitment to maintain inside Features and that has caused a lot of issues. Fixing things right right takes time because consensus takes time and open discussion.) There is an RfP for student developer time for legoktm for things like this (Finding a solution for Bug 35306 but not [[mw:Extension:MassMessage]] because MassMessage would not be deployed if it was my own engineer). Benny Situ has been spending all his time supporting [[mw:Extension:Echo]] when he should balancing [[mw:Flow]] development time into Echo bug fixes and needs to spend at least one sprint (two weeks) solely getting up to speed on Flow before doing enhancements for [[wm:Echo]]. Furthermore, Echo is not deployed everywhere yet and is still rolling out (though I've been pushing up the timetable on this as I feel we're too slow here), so it can't reach the places that EdwardsBot cat. After the above happen, I'd like Benny and Kunal to work together to add some of the functionality of EdwardsBot into Echo for mass message delivery. Because of this, I'm moving bug 35306 into Echo as an enhancement and raising it's priority. In the meantime I'll be OK with leaving MassMessage on test and test2 wikis because the alternative would be to remove it from the cluster entirely. The experiences and code Kunal derives by that can inform the enhancement to Echo, as well as things it already does that find themselves outside Echo (Echo does not and should not post to talk pages). So I figure two stages: 1) wait for some things to happen: legoktm to get an RfP, Echo to be on all wikis, and Benny to do an entire Flow only sprint and balancing his time more effectively wrt Echo. 2) MoSCoW other features of MassMessage/EdwardsBot for integration into Echo 3) Enhance and deploy a first pass to Echo to allow some sort of mass notification from a wiki list 4) Some sort of cross wiki notification enhancement (requires a design pass) 5) Discuss how to implement must-have or should-have features of EdwardsBot that can't live in Echo (permanent log of events)? 6) Add those to plan and be done. The above can occur independently or in parallel to the above. If Product thinks it cool to commit Platform's constrained engineering resources to deploying and supporting MassMessage Extension forever and use it to take advantage of Echo when the features roll out in some undefined future, consider this thinking moot or at least orthogonal to MassMessage. IMO, it is bad enough that something important like BetaFeatures is without a home, but my answer from Features is "No" for MassMessage. If this was my own engineer, I'd raise hell with them for this and yell at their Product Manager for not being a good steward of Platform's time. Take care, terry terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tchay(a)wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay

7 7

GSoC 2013 Summary - Language Coverage Matrix Dashboard
by Harsh Kothari 04 Oct '13

04 Oct '13

Hi Everyone *Four months of constant coding and excitement comes to an end - I still can’t believe I am saying this. While I am really really happy with how these times went - how fast, how satisfying, how perfectly awesome it went. It is just still hard to believe that it has ended - time flies, literally! Here goes my wrap-up blogpost for all these months of tireless programming. Here’s to a summer full of code! :-) * Blog Post : http://kothariharsh.wordpress.com/2013/10/04/a-summer-full-of-code/ Demo Instance: http://tools.wmflabs.org/lcm-dashboard/lcmd/ Thanks Harsh -- Harsh Kothari Intern at Google Summer of Code, Wikimedia Foundation Follow Me : harshkothari410 <https://twitter.com/harshkothari410/>

1 0

File cache + HTTPS question
by Jeroen De Dauw 04 Oct '13

04 Oct '13

Hey, I have a wiki that is accessible both via HTTP and HTTPS which has the file cache enabled. When someone loads a page over HTTP and it gets cached, it will have HTTP resource URLs in it. When someone then loads it over HTTPS and gets this cached page, they'll end up with mixed content, which causes the resources to not be loaded on recent FF versions. Is there a way to split the cache based on protocol used? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

24 65

importImages.php on symlinked windows wikis
by James Montalvo 04 Oct '13

04 Oct '13

I have several wikis all symlinked to a single prime wiki. Only the "images", "cache", and "mw-config" directories and LocalSettings.php file are unique for each wiki. Normally for maintenance scripts I just add "--conf C:/path/to/LocalSettings.php" to perform the maintenance script on a particular wiki but for importImages.php that does not entirely work. If I use it to upload to a particular wiki, the file-namespace pages get created on the correct wiki, but the actual files get put in the images directory of the prime wiki. Using "--conf C:/path/to/LocalSettings.php" does partially work. If I leave it off then the file-namespace pages get created in the prime wiki, instead of the intended wiki. So it appears --conf just isn't impacting file upload location. I've spent the last couple hours digging through the code, and at this point I'm at FileBackendStore->doOperationsInternal(), but can't figure out where the thing that looks like "mwstore://local-backend/local-public/e/ed/My_File_Name.png" (Zone Path?) gets converted into a file system path. At some point "mwstore://local-backend/local-public/" must get stripped off and replaced by "C:/path/to/wiki/images/". Any assistance would be greatly appreciated. I'm fairly new to MW development, and this is my first post on the mailing list. My config: MW 1.21, PHP 5.4, Windows 7 Thanks, James

2 2

GSoC 2013 Summary: Pronunciation Recording Tool
by Rahul Maliakkal 03 Oct '13

03 Oct '13

Hello everyone, I was given the privilege of working with Wikimedia Foundation as a part of my GSoC internship and it definitely was a very well spent summer. I was working this summer on building a "Pronunciation Recording Tool" for WMF under the mentorship of Michael Dale and Matthew Flaschen. The "Pronunciation Recording Tool" can be tested at : http://pronunciationrecording.instance-proxy.wmflabs.org/wiki/Special:Pronu… Use the latest "dev" and "beta" version of Chrome to test. The project is definitely not complete but I have written a wrap-up blog post summarizing my summer experience : http://21freebird.blogspot.in/2013/10/gsoc-2013-wrap-up.html Regards, Rahul Maliakkal

1 0

IRC office hour for Extension:BetaFeatures
by Mark Holmquist 03 Oct '13

03 Oct '13

Hi all, Due partly to the recent sparseness of traffic in #wikimedia-office, I've scheduled an office hour [0] for the new BetaFeatures extension, which the WMF is hoping to use for launching new features for beta testing. This will primarily be a technical discussion focused on people who may want to use the framework, or people who may want to help work on the extension. Possible topics include: * How do I use it? * What features are under development in this framework right now? * How does it work? * Can I have feature X? If you have any questions, or want to hear me wax on about what I've done with the extension thus far, drop on by and have a chat. I'll be in #wikimedia-office on Thursday at 21:00 UTC (14:00 PDT). [0] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours Happy hacking, -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur(a)member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist

1 1

Getting birthday from the sidebar of a wiki page and showing in the home page
by Shrinivasan T 03 Oct '13

03 Oct '13

The side bar of any famous person in Tamil wikipedia has the birthday of the person. Example: https://ta.wikipedia.org/s/im6 https://en.wikipedia.org/wiki/Nagesh Is there any way to notify this in the front/home page of the Tamil wikipedia ? Just like a "Today in history" etc. Thanks. -- Regards, T.Shrinivasan My Life with GNU/Linux : http://goinggnu.wordpress.com Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com Get CollabNet Subversion Edge : http://www.collab.net/svnedge

6 8

Summary of GSoC project: Refactoring of ProofreadPage extension
by Aarti K. Dwivedi 03 Oct '13

03 Oct '13

Hello everyone, I was working on the project "Refactoring of ProofreadPage extension". here is a recap<http://aartindi.blogspot.in/2013/10/in-case-you-missed-my-previous-posts-i.…>of what has been done in the project: 1. The handling of Index and Page pages have been separated. 2. The editing system has been separated from the reading system. 3. The setup of editing system has been removed from Javascript and shifted to PHP. 4. The image on the read page which was being rendered using Javascript was also shifted to PHP. 5. The process of getting data from the database was separated from the processing of data itself. 6. The Javascript was almost completely rewritten. A lot of Javascript was rendered redundant when a few things were moved to PHP. Also, we started using a new zooming library <https://github.com/benlumley/jQuery-PanZoom> for the zooming functionality in the extension. The future plans for the extension are to integrate it with VisualEditor, fix more bugs, and provide a nice user-friendly interface to add page ranges from DjVu files. It was absolutely fun to work with such a helpful community. Thanks a ton to Thomas PT and Thibaut for making this project a success! Cheers, Aarti K. Dwivedi( Rtdwivedi )

1 0

CentralNotice Proxy RfC
by Matthew Walker 02 Oct '13

02 Oct '13

I updated the CentralNotice banner proxy RfC [1] to reflect what was discussed last night. If it all looks good, I've attempted to evaluate some of the pros / cons of using Node vs Varnish as the banner server -- and I'd like some feedback on what technology I should use. [1] https://www.mediawiki.org/wiki/Requests_for_comment/Caching_Overhaul_-_Fron… ~Matt Walker Wikimedia Foundation Fundraising Technology Team

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l October 2013