Wikitech-l June 2015

wikitech-l@lists.wikimedia.org

110 participants
99 discussions

"Architecture meeting 2015" summary
by Matthew Flaschen 25 Jun '15

25 Jun '15

Today's RFC meeting was regarding general priorities for the coming months (https://www.mediawiki.org/wiki/Architecture_focus_2015). One of the key issues discussed was the idea of widgets, which is a new approach to representing and editing bundles of content (such as an infobox or a graph). We also talked about canonical formats, and whether content should be stored in wikitext and extracted out (like a more sophisticated version of https://www.mediawiki.org/wiki/Extension:TextExtracts), or stored elsewhere (e.g. Wikidata) and assembled. Gabriel Wicke noted the importance of minimizing disruption for existing editors and tools, and Bryan Davis suggested this could limit the flexibility editors now have. This led us to discuss further what areas likely made sense to be generated. I.E. graphs and data tables, probably not prose (but Daniel Kinzler suggested possibly auto-generating prose if there was no human-written prose). We talked about some approaches to backend storage. Timo Tijhof suggested allowing a page to be built from multiple blobs that reference each other. We talked about some approaches to widgets like infoboxes and inline editing of templates more generally. We also talked about testing coverage and code architecture guidelines. Daniel Kinzler plans to update the document in response to feedback. Matt Flaschen --- Minutes at https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20… Log at https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…

2 1

No easy tags
by Smriti Singh 24 Jun '15

24 Jun '15

Hey!! The "Easy" tag is becoming rarer and rarer as new tasks are coming in. This would make it pretty difficult for new developers like myself to sort through tasks to look for ones we can do. Could the community come up with something for this? It would be great if people could start adding an "Easy" tag if they think a task they come across is in fact an easy one :) -Smriti (Galorefitz)

3 3

2015-06-24 Scrum of Scrums notes
by Grace Gellerman 24 Jun '15

24 Jun '15

https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-06-24

1 0

Labs NFS outage - 2015-06-17 report
by Marc A. Pelletier 24 Jun '15

24 Jun '15

After a long and painful recovery process, here is the incident report for the June 17 outage of Labs NFS: https://wikitech.wikimedia.org/wiki/Incident_documentation/20150617-LabsNFS… -- Marc

1 0

Problem when +2 change on metrolook on gerrit
by Thomas Mulhall 24 Jun '15

24 Jun '15

Hi when I try to +2 changes for example at https://gerrit.wikimedia.org/r/#/c/220458/ it isent working I have to do V+2 and C+2 for it to merge into git. Please could I have some help.

1 0

RFC meeting this week
by Tim Starling 24 Jun '15

24 Jun '15

In the next RFC meeting, we will discuss MediaWiki architectural focus areas and strategic priorities: https://www.mediawiki.org/wiki/Architecture_focus_2015 The architecture committee has developed this draft document, and we'd like to know what people think of it. The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00 -- Tim Starling

1 0

interesting read: testing@LinkedIn
by Brian Gerstle 24 Jun '15

24 Jun '15

Short "case study" at LinkedIn [0] <http://engineering.linkedin.com/developer-happiness/getting-code-production…> 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… 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

3 2

Main themes for Wikimania's hackathon?
by Quim Gil 23 Jun '15

23 Jun '15

Hi, we have tried the idea of having main themes at the MediaWiki Developer Summit and Ther Wikimedia Hackathon. Wikimania's hackathon is approaching fast, and we need to decide * whether main themes will be useful for this event * if so, which main themes we want to promote. Your feedback is welcome at https://phabricator.wikimedia.org/T94031 PS: sneak preview https://wikimania2015.wikimedia.org/wiki/Hackathon#Schedule -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 1

Timo Tijhof joining the performance team
by Ori Livneh 23 Jun '15

23 Jun '15

Hi all, I am delighted to announce that Timo Tijhof (Krinkle) is joining the Wikimedia Foundation's performance team. Over the past several years, Timo has made many important contributions to MediaWiki performance. Though he has been highly active across the stack, his impact on front-end performance has been especially pronounced. Timo is one of the architects of ResourceLoader, the set of JavaScript and PHP software components that collectively implement the loading of JavaScript and CSS. A role on the performance team will allow Timo to spend time on modernizing ResourceLoader to leverage recent changes in browser networking stacks and performance-related web APIs. Timo has also been exemplary in his interactions with browser vendors and other upstream software vendors, by reporting bugs, submitting patches, providing feedback on proposals, and polling external subject-matter experts for input on proposed changes to Wikimedia's stack. I expect Timo to continue to play a leading role in evaluating new APIs and identifying opportunities to utilize them to improve user experience. Finally, Timo's history of working closely with the VisualEditor team make him a natural point-person for cross-team performance work on VisualEditor, which continues to be a priority for us. Welcome, Timo -- we're super excited and proud to have you. Ori

3 2

Modernizing our content platform: Kick-off meeting on Tuesday
by Gabriel Wicke 23 Jun '15

23 Jun '15

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+…

1 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 June 2015