[Wikitech-l] MediaWiki-Codesniffer 0.3.0 released
Hello! MediaWiki-Codesniffer 0.3.0 is now available for use in your MediaWiki extensions and other projects. Here are the notable changes since the last release (0.2.0): * Don't require wf prefix on functions that are namespaced (Kunal Mehta) * Simplify PHPUnit boostrap, require usage of composer for running tests (Kunal Mehta) * SpaceyParenthesis: Check for space before opening parenthesis (Vivek Ghaisas) * SpaceyParenthesesSniff: Search for extra/unnecessary space (Vivek Ghaisas) * CharacterBeforePHPOpeningTagSniff: Support T_HASHBANG for HHVM =3.5,3.7 (Kunal Mehta) I have submitted patches which bump the depdencies for extensions https://gerrit.wikimedia.org/r/#/q/status:open+topic:bump-dev-deps,n,z, however some are failing due to the new sniffs. Please amend the patches to make them pass and I can review them :) -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] global cleanup of nowiki
On Fri, 19 Jun 2015 10:38:01 +0200, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: * '''nowiki/''' - this doesn't do anything at all. I couldn't reproduce it in any way, so it's probably a bug that was fixed. This sounds very much like https://phabricator.wikimedia.org/T95730 which was fixed recently. It would be easy to write bots to fix such easy common cases, but they would have to run on every project. Would it make sense to write them as maintenance scripts that update them everywhere when people upgrade VE? It should be easier to both write and run these as on-wiki bots, and I doubt anyone other than Wikimedia has used VisualEditor enough to need such cleanup. I doubt that you'd have problems just running the bot on all projects, as very few of them seek out and ban helpful automated editors who do not jump through the necessary hoops; English Wikipedia, sadly, is one of these. You could always get a global bot flag: https://meta.wikimedia.org/wiki/Steward_requests/Bot_status https://en.wikipedia.org/w/index.php?title=Special%3ASearchsearch=insource%3A%2F%5C%3Cnowiki%5C%3E+%5C%3C%5C%2Fnowiki%5C%3E%2F Just be careful with the replacements, as Dan and Jack raise good points about weird syntax sometimes being intentional. Happy botting! -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: Labs (almost fully!) back up
FYI -- Forwarded message -- From: Yuvi Panda yuvipa...@gmail.com Date: Fri, Jun 19, 2015 at 11:33 PM Subject: Labs (almost fully!) back up To: labs-annou...@lists.wikimedia.org Hello everyone! All projects (except maps and mwoffliner) are fully back up. Theyshould be up now (including tools) - restored from a backup taken on June 9. Some have had NFS disabled - but those mostly have had no significant NFS usage or have had members of the project confirm NFS is unused. This increases their reliability significantly. If your project has something missing, please file a bug or respond on list. We have a fsck in progress on the old corrupted file system, and will update if / when we can recover specific files. https://wikitech.wikimedia.org/wiki/Incident_documentation/20150617-LabsNFSOutage has updates coming as well. Thank you. -- Yuvi Panda T http://yuvi.in/blog -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [Wikimedia-l] What is the wikipedia http API address now?
This list seems more appropriate for this type of discussion. -- Revi https://www.revi.pe.kr -- Sent from Android -- -- 전달된 메일 -- 보낸사람: Yuri y...@rawbw.com 날짜: 2015. 6. 20. 오후 2:52 제목: [Wikimedia-l] What is the wikipedia http API address now? 받는사람: wikimedi...@lists.wikimedia.org 참조: Now all previously http URLs redirect to https. https://www.mediawiki.org/wiki/API:Main_page also still mentions the old http address that now redirects. What is the new purely http API address? I need to know the hit of https on various processes. Yuri ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] interesting read: what makes great PMs
Thought some people would find this stream of tweets from Charlie Kindel [0] http://ceklog.kindel.com/2015/06/18/what-it-means-to-be-great-product-manager/ interesting. I'd also recommend perusing his other posts about leadership engineering culture. Here's my take on a few snippets, curious to hear your thoughts as well: *the only work that truly matters is that of the engineers* While engineers might be responsible for actually building things, Charlie himself admits that the quality (and relevance) of our work is highly dependent on multiple factors leading up to the first engineer's keystroke. *left to their own devices, engineers will do two things: 1) the most complicated thing, 2) the thing they think is fun* Guilty as charged, but I think engineers who are sold on the teams' mission are capable of making good decisions about what to work on. Our current situation in the Readership vertical is a live experiment on this subject. Finally, I wholeheartedly agree that I do my best work when it's crystal clear *who the customer is, where the customer is, why the customer cares, why it’s important for the business, and when it’s relevant.* Happy reading! Brian 0: http://ceklog.kindel.com/2015/06/18/what-it-means-to-be-great-product-manager/ -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] interesting read: testing@LinkedIn
Short case study at LinkedIn [0] http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality about how they cut release latencies by 80-90% by reversing the ice cream cone of death [1] http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png: There's one particular snippet that strongly resonates with what I've experienced at multiple jobs (emphasis mine): *Team ownership of quality* Quality is the responsibility of the *whole team*. Quality control is most efficiently achieved if software quality is considered at *every step in the development cycle*. A software quality process will benefit from an appropriate distribution of test automation ownership between teams cooperating in a software development effort. In other words: QA aren't the only ones responsible for tests. I would go a step (or several) further and explicitly suggest that testing needs to be considered at—or an integral part of—the design planning processes. Rich Hickey goes even further in his talk about Hammock Driven Development https://www.youtube.com/watch?v=f84n5oFoZBc (highly recommended: TL;DR; people start work before fully understanding the problem space). Things seem to be trending up at WMF, especially w/ the Web engineers' big strides in end-to-end testing. However, as the article suggests, you need to attack the quality problem from both ends—perhaps even emphasizing unit tests (shortest feedback, cheapest, least fragile). 0: http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality 1: http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png, thanks to Zeljko for introducing me to that fun term, much better than upside-down pyramid -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] global cleanup of nowiki
Hi, In the last few days I've been looking for reasons for the appearance of unnecessary nowiki tags. This mostly happens because of various VisualEditor and Parsoid issues. The developers have been very good at fixing them, and now it happens very rarely, but there are still lots of these useless tags lurking in pages. Two examples are: * '''nowiki/''' - this doesn't do anything at all. I couldn't reproduce it in any way, so it's probably a bug that was fixed. * nowiki /nowiki in the beginning of a paragraph. This was added in the past to avoid putting the paragraph in pre, but it's entirely useless, because the spaces are trimmed. Now they are pre-trimmed, so this is also a fixed bug, but a lot of pages still have it. There may be more - I'm still looking for these. It would be easy to write bots to fix such easy common cases, but they would have to run on every project. Would it make sense to write them as maintenance scripts that update them everywhere when people upgrade VE? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
On Fri, Jun 19, 2015 at 5:42 AM, John Mark Vandenberg jay...@gmail.com wrote: Why doesnt formatversion=2 assume continue= and utf8= ? It does assume utf8= (there's an ascii= to request the old mode in combination with formatversion=2). It doesn't assume continue= because that belongs to ApiQuery, not ApiFormatJson or ApiFormatPhp. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WebM/Ogg playback: testing energy usage on iOS
One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster. I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta: https://brionv.com/log/2015/06/19/webm-and-ogg-energy-usage-on-ios-9-beta-with-ogvkit/ The good news is that playback of buffered data at my target resolutions (360p for 32-bit, 720p for 64-bit) is barely under the Low mark on the energy drain meter! :D The bad news is that H.264 playback with the native widget reports post-buffer-download energy drain even lower, at the Zero mark... if you can believe that! (In both cases, reported drain is significantly higher during network download, at least on my fast wifi.) But Low sounds pretty good... If folks would like to see more concrete measures, I can rig up my test to run continuously until the battery runs out and time it. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
Before playing around with api serious bugs should be fixed... I see xxXx unresolved bugs on pahricator. It is frustrating Date: Thu, 18 Jun 2015 14:56:25 -0700 From: sp...@wikimedia.org To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month On Thu, Jun 18, 2015 at 9:26 AM, Brian Gerstle bgers...@wikimedia.org wrote: I guess it comes down to is this: if we're going to continue supporting old behavior, they should be accessible via the same old requests. *This removes the need for existing clients to be updated in the first place*. If we eventually want to delete the old code keeping the old behavior separated from the new will make it clear explicit what's being dropped and what to use instead. ... Lastly, changing the default behavior to make things sane for new developers is, IMO, a bad trade-off That seems the crux of it. Because the MediaWiki API isn't versioned (and there are good reasons for it), the recommended best practices form of an API request evolves, something like api.php?continue= formatversion=2 utf8= *your_actual_params* and over time the best practices boilerplate at the front gets longer unless we change a default and break old clients. Examples and documentation should show best practices; T103015 is to use formatversion=2 and https in all example API requests. (We should have used continue= in examples for the last year, it's too late now.) The above is actually a real URL and shows three different approaches: 1. As the e-mail subject says we're going to make continue= the default in a few weeks so you won't need to add it (but clients MUST add rawcontinue= to get the old behavior). 2. formatversion=2 is the future but won't be the default for a while. 3. If you request formatversion=2 then results default to utf8, so you don't need to specify utf8. (Note formatversion=2 only applies to format=json or php.) Which approach to take is a judgement call, I'm interject-opinion-reluctant :) because they'll eventually get tripped by us pulling the rug out from under their feet by *breaking backwards compatibility stable APIs*. Or, over time the best practices boilerplate endlessly expands: responselayout=clean reporterrors=schema facebookoverlordmode= ... Does that make our API user-hostile? IMO it just makes it wordy. Those sorts of changes should be reserved for experimental or even beta APIs. Continuing queries seems like a stable—and pervasive—part of the API. Cheers, -- =S Page WMF Tech writer ___ 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] global cleanup of nowiki
Starting by replacing \nowiki\\s\nowiki\ would be safe enough imho. Vito 2015-06-19 10:38 GMT+02:00 Amir E. Aharoni amir.ahar...@mail.huji.ac.il: Hi, In the last few days I've been looking for reasons for the appearance of unnecessary nowiki tags. This mostly happens because of various VisualEditor and Parsoid issues. The developers have been very good at fixing them, and now it happens very rarely, but there are still lots of these useless tags lurking in pages. Two examples are: * '''nowiki/''' - this doesn't do anything at all. I couldn't reproduce it in any way, so it's probably a bug that was fixed. * nowiki /nowiki in the beginning of a paragraph. This was added in the past to avoid putting the paragraph in pre, but it's entirely useless, because the spaces are trimmed. Now they are pre-trimmed, so this is also a fixed bug, but a lot of pages still have it. There may be more - I'm still looking for these. It would be easy to write bots to fix such easy common cases, but they would have to run on every project. Would it make sense to write them as maintenance scripts that update them everywhere when people upgrade VE? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ 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] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
On Fri, Jun 19, 2015 at 7:56 AM, S Page sp...@wikimedia.org wrote: On Thu, Jun 18, 2015 at 9:26 AM, Brian Gerstle bgers...@wikimedia.org wrote: I guess it comes down to is this: if we're going to continue supporting old behavior, they should be accessible via the same old requests. *This removes the need for existing clients to be updated in the first place*. If we eventually want to delete the old code keeping the old behavior separated from the new will make it clear explicit what's being dropped and what to use instead. ... Lastly, changing the default behavior to make things sane for new developers is, IMO, a bad trade-off That seems the crux of it. Because the MediaWiki API isn't versioned (and there are good reasons for it), the recommended best practices form of an API request evolves, something like api.php?continue= formatversion=2 utf8= *your_actual_params* Why doesnt formatversion=2 assume continue= and utf8= ? -- John Vandenberg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] interesting read: what makes great PMs
On Friday, June 19, 2015, Brian Gerstle bgers...@wikimedia.org wrote: ...I think engineers who are sold on the teams' mission are capable of making good decisions about what to work on. Our current situation in the Readership vertical is a live experiment on this subject. Indeed. I'm looking forward to the good work our engineers will produce under the current federated engineer-led product owner approach. For those who don't know, historically the mobile teams subsumed into Reading had 3 product managers. Presently, there's 1 product manager in the vertical recruiting for backfills is in flight), and many common product owner responsibilities are federated to an engineer within each discipline. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] WebM/Ogg playback: testing energy usage on iOS
Any idea if your work would also support dynamic bitrate switching? On Fri, Jun 19, 2015 at 12:57 PM, James Forrester jforres...@wikimedia.org wrote: On 19 June 2015 at 02:08, Brion Vibber bvib...@wikimedia.org wrote: One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster. I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta: [Snip] This is really impressive to see, thank you Brion. And yes, let's not try to achieve zero. :-) J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] global cleanup of nowiki
On Fri, Jun 19, 2015 at 4:38 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: * '''nowiki/''' - this doesn't do anything at all. I couldn't reproduce it in any way, so it's probably a bug that was fixed. Beware that in some cases, nowiki/ is doing something important. For example, [nowiki/[[sic]]] produces a wikilink to sic inside of square brackets. Removing it there will break the link. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] WebM/Ogg playback: testing energy usage on iOS
On 19 June 2015 at 02:08, Brion Vibber bvib...@wikimedia.org wrote: One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster. I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta: [Snip] This is really impressive to see, thank you Brion. And yes, let's not try to achieve zero. :-) J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] interesting read: testing@LinkedIn
Thanks for sharing this, Brian! x-posting to teampractices On Fri, Jun 19, 2015 at 6:55 AM, Brian Gerstle bgers...@wikimedia.org wrote: Short case study at LinkedIn [0] http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality about how they cut release latencies by 80-90% by reversing the ice cream cone of death [1] http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png : There's one particular snippet that strongly resonates with what I've experienced at multiple jobs (emphasis mine): *Team ownership of quality* Quality is the responsibility of the *whole team*. Quality control is most efficiently achieved if software quality is considered at *every step in the development cycle*. A software quality process will benefit from an appropriate distribution of test automation ownership between teams cooperating in a software development effort. In other words: QA aren't the only ones responsible for tests. I would go a step (or several) further and explicitly suggest that testing needs to be considered at—or an integral part of—the design planning processes. Rich Hickey goes even further in his talk about Hammock Driven Development https://www.youtube.com/watch?v=f84n5oFoZBc (highly recommended: TL;DR; people start work before fully understanding the problem space). Things seem to be trending up at WMF, especially w/ the Web engineers' big strides in end-to-end testing. However, as the article suggests, you need to attack the quality problem from both ends—perhaps even emphasizing unit tests (shortest feedback, cheapest, least fragile). 0: http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality 1: http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png, thanks to Zeljko for introducing me to that fun term, much better than upside-down pyramid -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] global cleanup of nowiki
Here is another practical example where nowiki/ may be required: https://www.mediawiki.org/wiki/Extension:Arrays#Using_arrayprint DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] interesting read: what makes great PMs
Another good one Brian - x-posting to teampractices. On Fri, Jun 19, 2015 at 8:26 AM, Adam Baso ab...@wikimedia.org wrote: On Friday, June 19, 2015, Brian Gerstle bgers...@wikimedia.org wrote: ...I think engineers who are sold on the teams' mission are capable of making good decisions about what to work on. Our current situation in the Readership vertical is a live experiment on this subject. Indeed. I'm looking forward to the good work our engineers will produce under the current federated engineer-led product owner approach. For those who don't know, historically the mobile teams subsumed into Reading had 3 product managers. Presently, there's 1 product manager in the vertical recruiting for backfills is in flight), and many common product owner responsibilities are federated to an engineer within each discipline. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Save the Date: MediaWiki Developers Summit 2016
Hello wikitech-l! This year we will be holding the MediaWiki Developers Summit 2016 between *Monday* *January 4th and Wednesday January 6th* in San Francisco. Due to popular demand the WMDS 2016 will be scheduled for three days instead of two. The third day being a more relaxed/informal hacking day where people can work on projects, continue discussion from the previous two days and catch up with each-other. Registration is not even close to being open so no action needed besides blocking off your calendars. Looking forward to a great event - we are 7.5 months away! https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2016 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] WebM/Ogg playback: testing energy usage on iOS
On Fri, Jun 19, 2015 at 10:00 AM, Brian Gerstle bgers...@wikimedia.org wrote: Any idea if your work would also support dynamic bitrate switching? It should be easy to track the download rate and *downgrade* to a lower-bitrate source if we have playback discontinuities -- we have a pause anyway, so that's a chance to switch sources and seek back to the current position. There'll be a pause for 'buffering' at first, though. Fully seamless resolution/bitrate switching as with HLS or MPEG-DASH is trickier, but doable. There is a DASH profile for WebM (used for instance by YouTube), so the tooling exists to produce suitable manifest files. Mainly what would need to be done is figuring out how to handle the predictive timing for the switch and retooling the player to swap out decoders in mid-stream without discontinuities. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] interesting read: what makes great PMs
Thanks for the read. Forwarding. Pine On Jun 19, 2015 7:07 AM, Brian Gerstle bgers...@wikimedia.org wrote: Thought some people would find this stream of tweets from Charlie Kindel [0] http://ceklog.kindel.com/2015/06/18/what-it-means-to-be-great-product-manager/ interesting. I'd also recommend perusing his other posts about leadership engineering culture. Here's my take on a few snippets, curious to hear your thoughts as well: *the only work that truly matters is that of the engineers* While engineers might be responsible for actually building things, Charlie himself admits that the quality (and relevance) of our work is highly dependent on multiple factors leading up to the first engineer's keystroke. *left to their own devices, engineers will do two things: 1) the most complicated thing, 2) the thing they think is fun* Guilty as charged, but I think engineers who are sold on the teams' mission are capable of making good decisions about what to work on. Our current situation in the Readership vertical is a live experiment on this subject. Finally, I wholeheartedly agree that I do my best work when it's crystal clear *who the customer is, where the customer is, why the customer cares, why it’s important for the business, and when it’s relevant.* Happy reading! Brian 0: http://ceklog.kindel.com/2015/06/18/what-it-means-to-be-great-product-manager/ -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ 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] Modernizing our content platform: Kick-off meeting on Tuesday
Hi all, a few of us have recently collected and roughly prioritized some open architectural questions [1]. The area that stood out as needing most urgent attention is adapting our content platform to long-term changes in the way users interact with our site [2]. People are using a wider range of devices, from feature phones to multi-core desktops. Many users are looking for short factoids and definitions, while others prefer to immerse themselves in detailed articles with rich multimedia content. MediaWiki is currently not very optimized to support such a diverse set of use cases. To address this, we see a need to improve our platform in the following areas: - Storage: To better separate data from presentation, we need the ability to store multiple bits of content and metadata associated with each revision. This storage needs to integrate well with edits, history views, and other features, and should be exposed via a high-performance API. - Change propagation: Edits to small bits of data need to be reliably and efficiently propagated to all content depending on it. The machinery needed to track dependencies should be easy to use. - Content composition and caching: Separate data gives us the freedom to render infoboxes, graphs or multimedia elements dynamically, depending on use case and client. For performance and flexibility, it would be desirable to assemble at least some of these renders as late as possible, at the edge or on the client. We don't expect to tackle all of this at once, but are starting to look into several areas. If you are interested in helping, then we would like to invite you to join us for a kick-off meeting: *When: Tuesday, June 23rd, 13:00 - 14:30 PT [3]* *Where: *A *hangout* link will be posted here before the meeting; room 37 in the office. If you can't attend, then please have a look at our current notes and let us know what you think [2]. Gabriel Wicke, Daniel Kinzler, Brion Vibber, Tim Starling, Roan Kattouw, Ori Livneh [1]: https://phabricator.wikimedia.org/T96903 [2]: https://phabricator.wikimedia.org/T99088 [3]: http://www.timeanddate.com/worldclock/fixedtime.html?msg=MediaWiki+content+platform+kick-offiso=20150623T13p1=224ah=1am=30 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
