Hey folks,
I'd to modestly propose that we talk about managing/announcing breaking
changes to core MediaWiki architecture.
I want to have this chat because I spent an hour or two yesterday trying to
figure out why changing default configuration options for an extension in
MyExtension.php wasn't working. Apparently, now, you also have to change it
in extension.json for it to work on Vagrant.
I understand that this was a change that was announced on wikitech-l, but I
don't think that I'm the only one who thinks that reading wikitech-l isn't
a good use of time, compared to, say, doing my job (irony upon ironies, I
know). If you want to change the way that things have worked for 11 years,
then making engineers understand what they need to do differently is your
responsibility, not mine.
So, besides huffing and puffing, I have two small proposals:
1. We should have a low-volume list/RSS feed/twitter account/something
where we announce major breaking changes like this, that doesn't involve
reading 20 emails per day of other stuff that doesn't affect the way I do
my job.
2. If we make breaking changes, the change should be really obvious so that
I can't spend hours trying to find out what changed.
For example, when we did the i18n JSON migration (everybody seems to love
JSON these days), and I went to change/add a message, I found that the
message file was a completely different format, and I was clued in straight
away to the fact that something was different.
By contrast, in this case, the way I'd done things for years suddenly
stopped working. I've heard it justified in this particular case that this
is just a transition period; but it's not just a transition period for
code, it's a transition period for practices, and therefore it's the time
when it should be the LEAST confusing for engineers who don't care about
your refactoring, not the MOST confusing.
— Andrew Garrett
As promised in the meeting, here is are the minutes for the VisualEditor
weekly triage meeting on 2015-02-11.
*Item 1 – Release criteria*
The release criteria at
https://phabricator.wikimedia.org/tag/%C2%A7_visualeditor_q3_blockers/ were
considered. After a brief discussion, no changes were proposed.
*Item 2 – Review of nominated tickets*
Nominated tickets accepted:
… as corruption & stability issues:
- https://phabricator.wikimedia.org/T76998 – Random removal of
categories when using Safari
- https://phabricator.wikimedia.org/T74048 – [Regression] VE corruption
issue(?) moving pre-existing categories to the middle of the page
- https://phabricator.wikimedia.org/T89025 – Using keyboard shortcuts
(in multiple browsers) or the "Open menu" (in Firefox only) to copy a
paragraph and a reference together causes selected content to be deleted
(not cut) instead
- https://phabricator.wikimedia.org/T88148 – class="wikitable wikitable"
corrupted to class="wikitable"
- https://phabricator.wikimedia.org/T74579 – Deleting from a
paragraph-terminating node to a paragraph-terminating node (?) is throwing
"Unbalanced set of replace operations found"
- https://phabricator.wikimedia.org/T76715 – Same Category get added
multiple times ,for every change in “Sort this page by default as” value
- https://phabricator.wikimedia.org/T72375 – Deleting from an empty
paragraph to the end of an inline node throws an exception
- https://phabricator.wikimedia.org/T70537 – In production, sometimes
page scrolling is not working and in the console Getting Error: offset was
inside a handlesOwnChildren node in Firefox
… as performance issues:
- https://phabricator.wikimedia.org/T88386 – ~50ms spent
a.oo-ui-buttonElement-button
- https://phabricator.wikimedia.org/T76523 – Show the VisualEditor
toolbar/editor chrome immediately after the user clicks "edit", rather than
blocking on waiting for the content to load
- https://phabricator.wikimedia.org/T88650 – Support data-mw.body.id for
reference contents
- https://phabricator.wikimedia.org/T88623 – VisualEditor should load
data-mw from a separate API call alongside the body content
- https://phabricator.wikimedia.org/T87553 – API requests to
action=visualeditor&paction=parse more than four times slower than requests
directly to parsoid-lb
… as testing issues:
- https://phabricator.wikimedia.org/T74398 – Actually run tests for
MWHeadingNode / MWPreformattedNode
… as feature issues:
- https://phabricator.wikimedia.org/T78202 – Wordbreak detection is
faulty for selection starting just down-page of a single character
- https://phabricator.wikimedia.org/T88337 – Tools should be able to
specify a label for their appearance in the context menu
- https://phabricator.wikimedia.org/T76398 – External link interface for
link dialogue
… as dependencies:
- https://phabricator.wikimedia.org/T66171 – Log Parsoid server-side
save performance
… for investigation and re-triage:
- https://phabricator.wikimedia.org/T74929 – Using browser native
interactive spell-check when the changed word in the only item in the
paragraph causes endless insertions in Firefox
- https://phabricator.wikimedia.org/T65462 – Using browser native
interactive spell-check tool causing repeated automatic deletion in Chrome
Nominated tickets rejected:
- https://phabricator.wikimedia.org/T72665 – Tab/Shift-Tab behaviour in
contexts other than lists (like tables)
This is a nice-to-have feature but it isn't critical to any of the
common edit workflows for the user groups targeted right now.
- https://phabricator.wikimedia.org/T67589 – Up/down keys in table when
you've selected a cell move left/right instead
This is a nice-to-have feature but it isn't critical to any of the
common edit workflows for the user groups targeted right now.
- https://phabricator.wikimedia.org/T52616 – Improve VisualEditor's
loading performance in Firefox
This is really a tracker bug more than a specific call-to-action.
- https://phabricator.wikimedia.org/T55825 – Reduce VisualEditor's
memory usage
This is a high-level tracker bug rather than a blocker; it needs child
bugs with more specifics to be nominated as blockers.
- https://phabricator.wikimedia.org/T53798 – There should be help links
in every context - dialog boxes, inspectors, etc.
We disagree with the premise; instead, there should only be help links
where they are useful to explain the complexity of a control to the user.
Most of this is already done, and the focus areas for this release don't
have this level of complexity required.
- https://phabricator.wikimedia.org/T88316 – Preview interface for link
dialogue
As a product decision, we decided to remove this as a blocker to the
release, and instead focus on the citation improvements first before taking
this on.
- https://phabricator.wikimedia.org/T86693 – Alter the toolbar and
dropdown menu design
As a product decision, we decided to remove this as a blocker to the
release; instead, this potentially will be part of our polish effort
instead.
*Item 3 – Other business*
The process was very briefly discussed, without suggestion of changes.
Hope this is of interest. Next week's meeting will be at 16:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150218T08&p1=224…>
(08:00 PST) on Wednesday 18 February; hope to see many of you there.
Joining instructions are on mw:Talk:VisualEditor/Portal
<https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri…>
for
those who didn't make it this week.
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hello,
The timeline and flame graph features of Chrome's DevTools have been very
useful for us as we work to understand and improve the performance of
VisualEditor. Someone asked me today about how we use these tools, so I
recorded a short (3-minute) screencast. It unfortunately cut off near the
end, but only the last sentence or so got clipped.
https://commons.wikimedia.org/wiki/File:Demonstration_of_Chromium%27s_timel…
T88590 is a good example of a bug we caught using this feature:
https://phabricator.wikimedia.org/T88590
Hope it's useful,
Ori
I recently hit the exact same issue. It's a useful widget but has no demos
(see https://phabricator.wikimedia.org/T85467)
Luckily after a week of fiddling Florian and I have two demos that are
working. The code in the following patches should help you work out.
I understand that Andrew Garret is setting up a demo site. I wonder if
during the dev summit we could get s demo for this done and on it?
https://gerrit.wikimedia.org/r/181225https://gerrit.wikimedia.org/r/180880
On 10 Jan 2015 04:37, "Ricordisamoa" <ricordisamoa(a)openmailbox.org> wrote:
Thanks. I eventually managed to use ProcessDialog and several widgets in a
script of mine <https://it.wikipedia.org/wiki/Utente:Ricordisamoa/PDC.js>.
I just couldn't make LookupInputWidget work (phab:T85467 <
https://phabricator.wikimedia.org/T85467>, mw:Talk:OOjs
UI#OO.ui.LookupInputWidget vs jQuery autocomplete <
https://www.mediawiki.org/wiki/Talk:OOjs_UI#OO.ui.
LookupInputWidget_vs_jQuery_autocomplete>), and had to fall back to jQuery
UI's autocomplete. The 'solution' I've come up with is, more or less:
var widget= new OO.ui.TextInputWidget();
widget
.$input
.autocomplete( {
source: function ( request, response) {
response( [
request.term + 'test 1',
request.term + 'test 2',
request.term + 'test 3'
] );
}
} );
Very few examples can be found of LookupInputWidget. Does anyone have any
hints about it?
Il 19/10/2014 17:49, Bartosz Dziewoński ha scritto:
OOUI is reasonably stable and can be used in gadgets, if you wish to.
> There is some high-level documentation and several examples at
> https://www.mediawiki.org/wiki/OOjs_UI and complete API reference at
> https://doc.wikimedia.org/oojs-ui/master/ .
>
> Breaking changes still can sometimes happen and when they do, they are not
> being announced very widely (they're just committed with "BREAKING CHANGE"
> in the subject line). If you start using OOUI and something that used to
> work suddenly breaks, please complain at #mediawiki-visualeditor.
>
> _______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi
Some of you who use JS and Python were probably excited about
deployment of new RCStream (1) and some of you who use .Net were
probably disapointed how complex it is to get it, JSON and
websockets.IO running on .Net in order to get it working.
Here I made a super simple C# library that utilizes a XmlRcs (2) proxy
to RCStream using only native .Net libraries that are provided by
microsoft and mono. That means this library is working out of the box
anywhere. You can get it here:
https://github.com/huggle/XMLRCS/tree/master/clients/c%23/XmlRcs
This library makes it extremely simple for anyone to connect to
wikimedia recent changes stream for any WMF project and hook event to
any change made to wiki. This would be probably very useful for .Net
bots and tools.
Let me know if you needed any help or improvements, or just use that
github tracker! Have fun
1 http://wikitech.wikimedia.org/RCStream
2 http://wikitech.wikimedia.org/XmlRcs
[X-posted announcement]
Hello,
The next monthly IRC office hour of the WMF Language Engineering team will
be on February 18, 2015 (Wednesday) at 1300 UTC on #wikimedia-office.
Please note that for this instance the session has been set to a much
earlier hour.
We will be taking questions and discussing about our ongoing projects,
particularly the recent activation of Content Translation as a beta feature
on several Wikipedias[1]. We’d love to hear comments, suggestions and any
feedback that will help us make this tool better.
Please see below to check local time and event details. Logs from our
earlier office hours are available at:
https://meta.wikimedia.org/wiki/Category:Language_Engineering
Thanks
Runa
[1] http://blog.wikimedia.org/2015/01/20/try-content-translation/
Monthly IRC Office Hour:
==================
# Date: February 18, 2015 (Wednesday)
# Time: 1300 UTC (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150218T1300)
# IRC channel: #wikimedia-office
# Agenda:
1. Ongoing projects - Content Translation beta feature
2. Q & A (Questions can be sent to me ahead of the event)
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hi does vendor have an api like the extension api which tells you name of the extension and version. Because I have ask for WikiApriary to support vendor in there tracking wiki site and they are asking for the api.
*tl;dr: Mobile Apps will, in partnership with the Services, investigate
building a content service for the Mobile Apps.*
The Mobile Apps Team currently has quite a few pain points with the way we
fetch article content currently:
- We have to make a lot of API requests to load an article: article
HTML, lead image, read more recommendations, and more
- We send the user HTML that we then discard, needlessly increasing data
usage
- We do transforms to the HTML in JavaScript on the client side, which
causes code duplication across the apps and degrades user-perceived
performance
- Trivial changes to the API (e.g. renaming a parameter) can break the
app which is problematic since apps can't be hotfixed easily
To address these challenges, we are considering performing some or all of
these tasks in a service developed by the Mobile Apps Team with help from
Services. This service will hit the APIs we currently hit on the client,
aggregate the content we need on the server side, perform transforms we're
currently doing on the client on the server instead, and serve the full
response to the user via RESTBase. In addition to providing a public API
end point, RESTBase would help with common tasks like monitoring, caching
and authorisation.
So the Mobile Apps Team is going to spend a bit of time investigating
whether using RESTBase with Node.js is an option for building a content
service for the Wikipedia app to replace our current method of retrieving
article content. Our initial scope for this is feature parity with our
current content retrieval method.
Our action items are as follows:
- Wait for RESTBase to be deployed.
- Timescale: Weeks
- Owner: All of us :-)
- Figure out what information the service should serve for the first
iteration (i.e. for feature parity) and what APIs it needs to hit to do that
- Timescale: Wed 4th Feb
- Owner: Dan Garry
- Start implementing the service and see whether it meets our needs
- Timescale: Planning a spike for next apps sprint (16th Feb - 27th Feb)
to perform initial investigation
- Owner: Currently undecided engineer from Mobile Apps, with Services
engineers serving as consultants
As always, feel free to ask if there are any questions.
Dan