[Wikitech-l] Technical leadership in Wikimedia

2014-05-18 Thread ENWP Pine
Hi all, your thoughts would be appreciated on this. It would be great to get some input from tech-focused contributors. I started the thread only on Wikimedia-l to keep the discussion consolidated in one place. http://lists.wikimedia.org/pipermail/wikimedia-l/2014-May/071811.html Thanks, Pin

[Wikitech-l] Bugzilla Weekly Report

2014-05-18 Thread reporter
MediaWiki Bugzilla Report for May 12, 2014 - May 19, 2014 Status changes this week Reports changed/set to UNCONFIRMED: 6 Reports changed/set to NEW: 12 Reports changed/set to ASSIGNED : 27 Reports ch

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Legoktm
On 5/18/14, 7:36 AM, Yuvi Panda wrote: Hello everyone! I just merged a change into the new wikibugs that will help reduce botspam on #wikimedia-dev. wikibugs will no longer report bugs on #wikimedia-dev that have been reported in other channels, thus reducing duplication. The previous behavior w

[Wikitech-l] GSoC and OPW Q&A at the ECT meeting

2014-05-18 Thread Quim Gil
Four acronyms in an email subject! My grandma would be proud of me. :) After a month of community onboarding, Google Summer of Code and FOSS Outreach Program for Women interns will start their work officially tomorrow, Monday 19. The Engineering Community team will devote its monthly IRC meeting

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread K. Peachey
tbh -dev (or somewhere else) should be the master channel for bz output. On 19 May 2014 00:36, Yuvi Panda wrote: > Hello everyone! > > I just merged a change into the new wikibugs that will help reduce > botspam on #wikimedia-dev. wikibugs will no longer report bugs on > #wikimedia-dev that hav

Re: [Wikitech-l] Deployments of new, radically different default features

2014-05-18 Thread Rainer Rillke
Sun May 18 00:20:10 UTC 2014 Brian Wolff bawolff at gmail.com wrote: > I do think there are probably better ways to handle notification of > new features. Perhaps a pop up the first time new feature is activated > explaining the feature and how to disable it. I'm not really sure. Yeah, that woul

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Yuvi Panda
I also see that there is room for more cleanup. The Growth and Analytics teams should move out of -dev :D Perhaps ops too? -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailm

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Merlijn van Deen
On 18 May 2014 19:58, Nick Wilson (Quiddity) wrote: > Current setup details are at > https://github.com/valhallasw/pywikibugs/blob/master/channels.py > docs are linked at > https://www.mediawiki.org/wiki/wikibugs > > Recently I moved the repo to Gerrit, but I forgot to update the documentation. T

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Nick Wilson (Quiddity)
On Sun, May 18, 2014 at 7:36 AM, Yuvi Panda wrote: > Hello everyone! > > I just merged a change into the new wikibugs that will help reduce > botspam on #wikimedia-dev. wikibugs will no longer report bugs on > #wikimedia-dev that have been reported in other channels, thus > reducing duplication.

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Prateek Saxena
Thanks Yuvi! I was just about to put it on ignore :\ —prtksxna ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Yuvi Panda
Hello everyone! I just merged a change into the new wikibugs that will help reduce botspam on #wikimedia-dev. wikibugs will no longer report bugs on #wikimedia-dev that have been reported in other channels, thus reducing duplication. The previous behavior was that wikibugs will ping multiple chann

Re: [Wikitech-l] Transcluding non-text content as HTML on wikitext pages

2014-05-18 Thread Gabriel Wicke
On 05/18/2014 02:28 AM, Subramanya Sastry wrote: > However, in his previous message, Gabriel indicated that > a property in the JSON/XML response structure might work better for > multi-part responses. The difference between wrapper and property is actually that using inline wrappers in the return