Wikitech-l June 2015

110 participants
102 discussions

[wikitech-l] No easy tags
by wp mirror 25 Jun '15

25 Jun '15

Dear Smriti, Thanks for raising the point about easy tags. I am guilty as charged. Once a year I (wpmirrordev) file a large number of tasks. Most of them involve changing file permissions. I have now marked these tasks as easy. These tasks are appropriate for a first-time contributor. They would give you a reason to wander through the directory tree of core/, skins/, and extensions/ and learn where everything lives. Sincerely Yours, Kent > Thank you so much Andre and Tony! :D > As for what I am interested in, as long as it is not python and does not > have the design tag, I would love to work on it. With the links now though, > bugs that interest me will be much easier to find :) > Thank you for addressing this. Seeing more easy tags makes it easier for > new developers like myself to contribute actively :) > -Smriti (Galorefitz)

1 0

Re: [Wikitech-l] [Engineering] Modernizing our content platform: Kick-off meeting on Tuesday
by Adam Baso 25 Jun '15

25 Jun '15

Updated URLs, we're in R37 on air stream: http://youtu.be/RcE2kecrsIk Max of 15 users: https://plus.google.com/hangouts/_/hoaevent/AP36tYdub-Rs4mI_4UjTEzTgU7GKBkg… On Tue, Jun 23, 2015 at 12:18 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote: > This sounds fairly dev centric with Front end/ UX implications. > Will the discussion be fairly technical? Let us know if Design should > attend. > > ---- > Vibha Bamba > Senior Designer | WMF Design > > > > > > > > On Tue, Jun 23, 2015 at 11:12 AM, Gabriel Wicke <gwicke(a)wikimedia.org> > wrote: > >> Reminder: This is today! >> >> When: *Tuesday, June 23rd, 13:00 - 14:30 PT* [3] >> Where: >> * *https://plus.google.com/hangouts/_/wikimedia.org/contentplatform >> <https://plus.google.com/hangouts/_/wikimedia.org/contentplatform>* >> * *room 37* in the office >> >> On Fri, Jun 19, 2015 at 12:00 PM, Gabriel Wicke <gwicke(a)wikimedia.org> >> wrote: >> >>> 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+… >>> >> >> >> >> -- >> Gabriel Wicke >> Principal Engineer, Wikimedia Foundation >> >> _______________________________________________ >> Engineering mailing list >> Engineering(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/engineering >> >> > > _______________________________________________ > Engineering mailing list > Engineering(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering > >

5 4

Re: [Wikitech-l] Wikitech-l Digest, Vol 143, Issue 48
by Lora Porter 25 Jun '15

25 Jun '15

remove my email I've requested this multiple times. lora On Jun 25, 2015 8:02 AM, <wikitech-l-request(a)lists.wikimedia.org> wrote: > > Send Wikitech-l mailing list submissions to > wikitech-l(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > or, via email, send a message with subject or body 'help' to > wikitech-l-request(a)lists.wikimedia.org > > You can reach the person managing the list at > wikitech-l-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Wikitech-l digest..." > > > Today's Topics: > > 1. "Architecture meeting 2015" summary (Matthew Flaschen) > 2. Barry the browser bot (Jon Robson) > 3. Re: [Engineering] Modernizing our content platform: Kick-off > meeting on Tuesday (S Page) > 4. Re: "Architecture meeting 2015" summary (MZMcBride) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Jun 2015 18:39:16 -0400 > From: Matthew Flaschen <mflaschen(a)wikimedia.org> > To: EE List <ee(a)lists.wikimedia.org>, Wikitech > <wikitech-l(a)lists.wikimedia.org> > Subject: [Wikitech-l] "Architecture meeting 2015" summary > Message-ID: <558B3194.7020302(a)wikimedia.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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… > > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Jun 2015 16:55:59 -0700 > From: Jon Robson <jrobson(a)wikimedia.org> > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Internal > communication for WMF Reading team < reading-wmf(a)lists.wikimedia.org>, > mobile-l <mobile-l(a)lists.wikimedia.org>, "QA (software quality > assurance) for Wikimedia projects." <qa(a)lists.wikimedia.org> > Subject: [Wikitech-l] Barry the browser bot > Message-ID: > <CALMndh=a-2PEAi+xENcNNCVG42yv4ZLPaCo0oDrt5qek8ww= tg(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Some of you may have noticed a bot [1] providing reviews for the > Mobilefrontend and Gather extensions. > > This is a grass routes experiment [2] to see if we can reduce > regressions by running browser tests against every single commit. It's > very crude, and we're going to have to maintain it but we see this as > a crude stop gap solution until we get gerrit-bot taking care of this > for us. > > Obviously we want to do this for all extensions but we wanted to get > something good enough that is not scaleable to start exploring this. > > So far it has caught various bugs for us and our browser test builds > are starting to finally becoming consistently green, a few beta labs > flakes aside [3]. > > Running tests on beta labs is still useful but now we can use it to > identify tests caused by other extensions. We were finding too often > our tests were failing due to us neglecting them. > > In case others are interested in how this is working and want to set > one up themselves I've documented this here: > https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot > > Please let me now if you have any questions and feel free to edit and > improve this page. If you want to jump into the code that's doing this > and know Python check out: > https://github.com/jdlrobson/Barry-the-Browser-Test-Bot > (Patches welcomed and apologies in advance for the code) > > [1] https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c… > [2] https://phabricator.wikimedia.org/T100293 > [3] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro… > > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Jun 2015 17:19:13 -0700 > From: S Page <spage(a)wikimedia.org> > To: Dan Garry <dgarry(a)wikimedia.org> > Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Development > and Operations Engineers <engineering(a)lists.wikimedia.org> > Subject: Re: [Wikitech-l] [Engineering] Modernizing our content > platform: Kick-off meeting on Tuesday > Message-ID: > <CAJg1jJVrs8BM5w-z=9+eQO6cwpNvXU= td6j0cZ2WFTvw0-7meA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Jun 23, 2015 at 10:01 PM, Dan Garry <dgarry(a)wikimedia.org> wrote: > > > My takeaway from this was that there are strong arguments both for and > > against keeping the representation of an article as a single blob of > > wikitext/HTML. > > > > In the Architecture focus discussion, Krinkle, tgr, and others expressed a > more optimistic idea, that the wikitext of an article is "a sea of prose > with isles of non-prose content, which could come from structured data" [1]. > > I wasn't properly aware that the <graph> [2] and <templatedata> [3] parser > tags are examples of this already. Their content is highly structured and > VisualEditor or dedicated code can provide a specialized editor for it. If > you edit source of a wiki page containing them and garble their content, > you get a syntax warning or fail. > > Wiki pages need more of these, <drumroll> Structure Content Blobs™ (or > sPage Components? anything but "widget"). Are they necessarily parser tags, > or is a parser function like {{#graph: *some parameters*}} equivalent? > > To be concrete, does this mean the way forward for specifying lead images > [5] is a parser tag > <leadimage>{ > "imagepage": "File:Einstein_1921_by_F_Schmutzer_-_restoration.jpg", > "focalarea": {"rect": [0.20, 0.20, 0.12, 0.12]} > } > </leadimage> > in wikitext, with a MediaWiki API to add this to a document and a WYSIWYG > property editor in VisualEditor for humans? > > AIUI, the *Architecture focus 2015* document discusses this under > "Generalized transclusion" [4] and comments: > Over the next months, the MediaWiki developer community and staff should > investigate how the different transclusion mechanism used with wikitext > content can be unified and extended to work with non-wikitext content. > > Exciting stuff. > > [1] > https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20… > starting at 21:21:05 > [2] e.g. https://www.mediawiki.org/wiki/Extension:Graph/Demo/Map?action=edit > [3] e.g. https://www.mediawiki.org/wiki/Template:Phabricator?action=edit > [4] > https://www.mediawiki.org/wiki/Architecture_focus_2015#General_architectura… > [5] https://phabricator.wikimedia.org/T91683 > > -- > =S Page WMF Tech writer > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Jun 2015 00:00:05 -0400 > From: MZMcBride <z(a)mzmcbride.com> > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Subject: Re: [Wikitech-l] "Architecture meeting 2015" summary > Message-ID: <D1B0F350.93021%z(a)mzmcbride.com> > Content-Type: text/plain; charset="UTF-8" > > Matthew Flaschen wrote: > >Today's RFC meeting was regarding general priorities for the coming > >months (https://www.mediawiki.org/wiki/Architecture_focus_2015). > > > >[...] > > > >Daniel Kinzler plans to update the document in response to feedback. > > I just wanted to say thank you to you and to Dan for these recent e-mails > summarizing larger technical discussions. :-) While I appreciate the > value of synchronous chats, supporting asynchronous communication is also > important and these notes are very helpful in understanding, at a high > level, what's being discussed and why. They also help ensure that everyone > is aligned and informed and they make jumping into the discussions easier. > > MZMcBride > > > > > > ------------------------------ > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > End of Wikitech-l Digest, Vol 143, Issue 48 > *******************************************

2 1

"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

← Newer
1
2
3
4
5
6
7
...
11
Older →

2025

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