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.
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
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
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
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+…
The Blueprint skin uses data['title'], which doesn't work well [1] if a
page uses
{{DISPLAYTITLE:<span style="blah blah">{{FULLPAGENAME}}</span>}}
to hide its title as suggested [2].
Manual:Skinning [3] doesn't explain where data['*somekey*'] comes from or
what the keys are. No problem, in a skin if you var_dump( $this->data )
there are a dozen other title-like keys to choose from. But how do skin
developers know which one to use? titletxt, titletext, titleprefixeddbkey,
thispage, ... Some are set(), some are setRef(), is that significant?
It seems the best you can do is read the source code of
includes/skins/SkinTemplate.php and work back through its getOutput(),
getTitle(), and getRelevantTitle() to OutputPage and the maze of title
class methods to figure out which one does what you want. Too hard for me.
Thanks for any suggestions, I'll try to improve the documentation.
[1] https://phabricator.wikimedia.org/T103454
[2]
https://www.mediawiki.org/wiki/Manual:FAQ#How_do_I_hide_the_main_page_title…
[3] https://www.mediawiki.org/wiki/Manual:Skinning
--
=S Page WMF Tech writer
Hey all,
This thread is much in line with the "wfRunHooks deprecation" one from
January. Rather than turning global functions into static functions, this
time it's about namespacing global functions.
All extensions calling wfSuppressWarnings now are supposed to change this
to MediaWiki\suppressWarnings, for no obvious gain. Important to keep in
mind here is that this is not a simple search and replace, since that'd
make extensions incompatible with anything before MediaWiki 1.26 alpha.
Either we need to ignore the deprecations (which is not something you want
people to learn as good practice), or we need to add some kind of wrapper
in each extension.
There also is the question of consistency. Nearly all global functions are
still namespaced using the wf prefix. Will they all be changed? Or will
just a few functions be migrated?
I'd really prefer this kind of busywork for extension maintainers not to be
created without very good reason. There are enough breaking changes to keep
up with as it is.
Cheers
--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Developer at Wikimedia Germany
~=[,,_,,]:3
