The RFC meeting today covered the multi-datacenter work
The basic summary is that there will be one datacenter used for all
POSTs, and that GETs will go to the closest data center.
This means GET should mutate state as little as possible (since
otherwise the far-off GET center will have to write to the main data
center in Virginia), delaying the user. There are special provisions
for avoiding this in the cases where writes are needed.
It's general practice that GET should never mutate state anyway, but
there exceptions to this in MediaWiki (though some, e.g. rollback, will
be fixed as part of this).
For example, when a GET needs to queue a job, it uses EnqueueJob, which
adds the job to a local job queue. It is then copied to the real job
queue without delaying the user.
I know they've already worked with us on how this affects Flow, and the
RFC commits to documenting the new patterns further.
Code review & updates. Put a number of Matthias' patches through.
A lot of things should be showing up in product review soon.
Today: Start on VE stuff.
Do we need more tickets in the sprint? It's running low, and we're only one
Working on mentions inspector for VE toolbar.
It now saves mentions properly.
You can also edit the mention within the new message.
Autocomplete is in progress. Also, trying to edit mention after saving
doesn't work yet.
There was feedback on handlebars refactoring -- sorted that out.
Worked on allow parallel conversions for LQT, it's in gerrit.
Tomorrow: Probably VE work.
Worked on Echo multiple target pages. Seems to work, up for review.
Doing code review on Matthias' templating fixes. About half reviewed.
Today: responding to code review.
Fri: Worked on LQT fix about reference tables.
Today: Working on
Working on the mentions inspector for toolbar. Made a lot of progress,
there's a WIP patch.
Reviewed small Echo patch, merged image links fix.
Reviewed template patches.
Today - finish up mentions inspector, then code review & email.
Thanks for volunteering. We already have a meetup scheduled for March 24,
so could we work on this at that time? In the meantime we can test
Also, does anyone have a copy of Premiere that we can borrow? I've tried
several open source video editors and all of them were buggy, slow, or
difficult to use.
On Mar 14, 2015 8:59 PM, "Raymond Leonard" <raymond.f.leonard.jr(a)gmail.com>
> Addendum: Maybe a Windoze screencasting is a possibility after all. After
> looking at Comparison of screencasting software
> <https://en.wikipedia.org/wiki/Comparison_of_screencasting_software>, I
> suggest we take a look at Freeseer
> <https://en.wikipedia.org/wiki/Freeseer>. It generates Ogg
> <https://en.wikipedia.org/wiki/Ogg>, is published by FOSSLC, has a GPL v3
> license, & works on Linux, OS X, & Windows.
> On Sat, Mar 14, 2015 at 9:22 PM, Raymond Leonard <
> raymond.f.leonard.jr(a)gmail.com> wrote:
>> I would like to help. I think that quiddity's suggestions are good.
>> Perhaps we should tackle individual segments of how to edit with VE rather
>> than the whole kit & caboodle. More of a just-in-time approach to VE help.
>> That said, I have no real experience with VE as I tend to work directly
>> with Wiki markup. Bringing a beginner's mind to VE might be a good thing.
>> I also do not have either a Chromebook or Linux systems that the tools
>> suggested at
>> use. Perhaps someone in the Seattle area who has a Linux PC can assist us.
>> Except for Saturday morning, I am available this coming weekend (although
>> on-call) to start.
>> On Sat, Mar 14, 2015 at 6:39 PM, quiddity <pandiculation(a)gmail.com>
>>> On Sat, Mar 14, 2015 at 3:53 PM, Jan Ainali <jan.ainali(a)wikimedia.se>
>>>> Just an idea, for the part on how to edit with VisualEditor, make
>>>> several short videos with distinct themes instead of one long video
>>>> covering it all. Not only will it be easier to record and edit, it will be
>>>> easier to reuse if you a question like question "How do I add a source with
>>>> VE?" and you can just point them to that video rather than handing them a
>>>> 30 minute video and trying to remember at what time that part starts.
>>> Strong +1. The shorter a video is, the more people will watch/listen to
>>> I'd recommend 30-90 seconds as the ideal target, with ~4 minutes as the
>>> second ideal target, and ~10 minutes as the maximum. Anything longer than
>>> that, could be broken up into chunks, and should be, Because:
>>> A) less "time-commitment" for viewers (it can kindle the enthusiasm of
>>> clicking "oh, just one more!", rather than "oh god, another entire
>>> B) it allows multiple shorter videos to be embedded in a page of text,*
>>> C) it has much more potential over the years ahead, for us (*all*) to
>>> update/improve/adapt/fork/subtitle/remix/etc each *segment* of it, in
>>> every wiki that it is wanted.
>>> The text of the accompanying page could be:
>>> * A concise version of the video(s), in bulletform list. I.e.
>>> "Slide-show presentation" style. With just keywords, and the clickable
>>> links to whatever the video is describing.
>>> * Or, a match of the video(s) content, for people without video-options
>>> * Or, a more elaborate/extensive/complete version of the video(s)
>>> content. E.g. our full Policy/Guideline/MoS/Essay/Help/etc pages themselves!
>>> (Re: screencasts, I replied to the earlier thread related to this, but
>>> didn't CC-all, sorry! See
>>> https://lists.wikimedia.org/pipermail/education/2015-March/001273.html )
>>> Wikimedia-Cascadia mailing list
> Wikimedia-Cascadia mailing list
As mentioned on the Education mailing list, some thematic organizations
have already, or will soon, produce training materials for VisualEditor in
a variety of languages. Cascadia Wikimedians needs at least a lesson plan
for our workshops in April, so I/we will produce materials in English,
probably in video form that includes two major sections: about Wikipedia
and its sister projects, and how to edit Wikipedia with VisualEditor. My
hope is to produce a 30 to 60 minute video that can get new editors to a
basic level of Wikipedia competence in one hour including competence with
talk pages, notability, copyright, plagarism, conflict of interest, and
deletion discussions. I also hope that new editors will feel excited to
participate in the community when they finish watching the video. Stay
tuned for further developments.
If other English speaking Wikimedians are interested in helping with the
production then please email me off list.
James or others,
Are there official ETAs for:
* Citoid in VE (I hear sometime in Q3)?
* Citoid in the traditional editing interface on ENWP?
* VE on mobile web?
* VE on mobile apps?
* Photo uploads through VE?
* Flow on ENWP?
Moved edit under dropdown menu (S7)
Suppressed user for LQT (S8)
5 LQT related patches in code review now.
Turned Flow on for two pages in Telugu WP
Working on S12, Flow notifications not marked as read
Reviewed and merged bad link targets (R2)
Fixed base href bug, want to deploy Mon
Found another Vagrant performance problem
Implemented S1 - Special:Enable -- in code review
Fixed some incorrect i18n messages
Now working on mentions inspector. (It's okay to punt on elements that make
it too hard for now.) Discussion about how to make the ping template
Rebased undo patch, figured out css issues.
Figured out patch for turning on edit for autoconfirmed.
Today: Finish up the LQT errors.
Fixed reply button issue on production.
Wrote onboarding doc for Stephane, and fixed some things on Mw.
Next: Review MW config patch.
Then S1: Special page to enable Flow.
Cherrypicked patch to bring back text for reply button, it was SWAT
Put up patch to dismantle Mantle. Erik replaced handlbars version with more
recent version, will review tomorrow.
Currently working on Unique index blocker for LQT. (S9)
Lot of code review, patches are ready to be merged.
Worked on asynch XMLHttp Requests (VE + Flow).
Split first patch into 5 different patches to help make code review easier.
Fixed exception in Jenkins that's blocking Krinkle.
Rebased and updated main VE patch.
Fixed VE toolbar issue, not aligned properly.
Still working on Vagrant issues.
Looked at Matthias' asynch work.
Cleanup on Growth team tasks.
Today: Onboarding for Stephane.
Erik at Scrum of Scrums.
Sprint S kickoff today...