I'm sorry for missing standup.
Yesterday, I:
* Reviewed and merged Erik's recovery patch, along with the follow ups
* Updated my fix to RevisionStorage->update to be much more
comprehensive. The earlier version of my fix just forbade content
changes. The new one allows them if the column configuration is set for
that. This is also tested (with tests for both column configurations).
* Put up a trivial patch to fix Echo event validation
(https://phabricator.wikimedia.org/T95169)
Matt
On 04/22/2015 04:41 AM, Tim Starling wrote:
> In the next RFC meeting, we will discuss the following RFC:
>
> * Business Layer Architecture on budget
> <https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architec…>
Minutes:
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
Log:
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
Summary of the discussion:
There was a fair amount of discussion about how the request/response
model of the MW API ("API" here meaning api.php modules) should map to
the proposed wfApi (or replacement). Tim was concerned that done wrong
it will not reflect the stateless nature of the API.
People generally agreed that not all code should do SQL.
There was consensus to rewrite the RFC (particularly the assumptions).
There was not consensus on the underlying RFC, though there was some
support for making FauxRequest better.
I, and others, expressed some concern about the lack of type checking
possible in this approach (since every API request is essentially
{action: 'thank', parameters: {}}, rather than
$$thankServiceInstance->thank( $revision ) or whatever).
A counter-argument to this is that we don't fully take advantage of the
type-checking available. However, there are type checkers for PHP which
some people use, and it's likely that even if we don't move to Hack,
more type-checking features will move into the PHP ecosystem.
Also, we do have basic type-checking at run-time already (type hints, is
it a real method?), though not quite the same thing.
Matt Flaschen
We had an RFC meeting today about an RFC
(https://www.mediawiki.org/wiki/Requests_for_comment/Watch_Categorylinks) regarding
watching categorization changes.
The original proposal was to use Echo. However, there were some
concerns regarding that, regarding performance and UX (this seems more
consistent with the watchlist's UX).
The decision at the end was to use the recentchanges table. There are
two many remaining design questions:
1. Should categorization changes (on pages using the template) due to a
template change be ignored? This would simplify implementation, but
limit the usefulness of the feature.
If template changes are reflected, there were some suggestions on
implementation.
One was to create a single bulk event when the template is edited. The
problem with this is the template can have different effects on
different pages using it.
So it would somehow need to keep track of the effects, and create an RC
entry (with the relevant info either in, or pointed to by, rc_params) at
the end of the template processing.
Gabriel Wicke suggested an alternate approach that might be easier:
Point from the RC entry to an ID, and keep updating the list of pages
affected by that categorization batch as it progresses. It could maybe
use the revid of the template/underlying page change as this ID.
2. Whether to allow watching only the category page (i.e. the
description of the category), or require watching both that and
categorization/decategorization together. If the latter, filtering
(e.g. "ignore categorization/decategorization" view) could be done on
the watchlist page.
The RFC will be updated.
Matt Flaschen
Hi Everyone,
I wanted to share two projects currently under consideration for IdeaLab
funding and which may be of directly related to engaging new and seasoned
editors. If you are interested or know someone who might be, let me know.
If you have feedback for these projects, please submit it on their
discussion pages.
Thanks,
Jason
*Wiki Controversy Monitoring Engine Call for Developers*
*Purpose*: The controversy monitoring engine maintains a real-time rating
of the controversiality of Wikipedia articles by listening to the live
stream of edits from Wikipedia. We need someone who is interested in
building the web interface and interactive visualizations around these
controversies to enable administrators to monitor, investigate, and, if
need be, intervene to deescalate controversies. The goal is to create a
site like stats.wikimedia.org editors and admins can use to identify and
deescalate controversies.
*Requirements*: Knowledge of web development, web-based visualization,
and\or data analysis using Wikipedia's API or WikiData.
*For More Information*: see
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Controversy_Monitoring_Engine
*Consciousness-Raising Repository Call for Working Group Participants*
*Purpose*: We're putting together a group of diverse Wikipedians to help
put together a repository of stories from users experiencing
marginalization on Wikipedia. Whether first timers or old timers, we're
looking to recruit users interested in engaging the community around
marginalization. The purpose of the repository is to serve as a database of
knowledge about the forms marginalization can take and as an outlet for
users experiencing marginalization.
*Requirements*: Interest in working with marginalization and marginalized
groups. Interest in the Wiki-community. Willing to attend an hour-long
biweekly meeting.
*For more information*:
https://meta.wikimedia.org/wiki/Grants:IdeaLab/A_Consciousness_Raising_Repo…
--
Jason Radford
Doctoral Student, Sociology, University of Chicago
Visiting Researcher, Lazer Lab, Northeastern University
*Connect*: LinkedIn <http://www.linkedin.com/in/jsradford>, Twitter
<http://www.twitter.com/jsradford>, University of Chicago
<http://home.uchicago.edu/%7Ejsradford/>
*Play Games for Science at Volunteer Science
<http://www.volunteerscience.com>*
*Erik*:
Went through Phabricator board, everything not in development is blocked on
something
Running the indexer on Matthias' search tickets -- are patches able to be
merged? No -- Matthias will work on that tomorrow.
Started running revision content link script -- it's still running.
LQT conversion -- turned out to be trivial minor issues, that should be
ready to swat out tonight & ready for conversions.
*Matthias*:
Worked on patches for cascading deletion -- patch works, but not for boards
that are deleted & re-created.
Krinkle reported about failing tests last week.
Tomorrow: rebasing search patches
*Matt*:
Updated core & Flow mediawiki.feedback patch. Swat deployed this morning,
now live on Mediawiki.org.
Worked on LQT notifications patch. Decided to use notify agent, figured
everything out. Too late to swat it out this morning, will do it this
evening instead.
*Stephane*:
Focus today on setting up vagrant, coding environment. Got a first bug,
work on it once environment is set up.
*Erik*:
A couple unbreak nows for history pages not showing history -- one of the
production services uses a forwarder to talk to memcache, operations may
not have been following it. Got everything restarted, hopefully they'll add
monitoring.
Looking at Matthias' code review for the deletion stuff. We should be able
to see page ids in archive table.
Looking at ElasticSearch tickets, figuring out how it all works.
*Matt*:
Code review on moving Flow boards, will finish today
Are we doing LQT conversion today? LQT --> Flow notifications conversion
still in code review.
*Erik*:
Finished up icon switcher for VE toolbar.
Worked on move page
T94779 -- Trying to suppress an IP address. There is a bug there, but it's
also a feature request -- we don't support suppressing just the IP.
Put up a patch for clicking the Hide button from the Contribs page -- fix
that should be cherrypicked.
Today: Finishing move page, then moving on to something else.
*Matt*:
Worked on VE toolbar & switcher
Updated core Mw.feedback patch
Helped a user set up Flow on a separate wiki, found a bug
Will run the production fix for ContentLength
*Matthias*:
Started working on eliminating unnecessary HTML Parsoid serialization
That will be done by tomorrow.
*Erik*:
Yesterday: VE switcher, move page
Got next CirrusSearch patch reviewed, we should be unblocked
Today: Primary goal is getting VE toolbar out and deployed tonight
*Matt*:
Merged bug fix from MM for Parsoid API, so it no longer breaks links when
you go back and forth
Reviewed VE switcher patch, made a couple minor fixes, merged
Working on GSOC
Flow plugin on message poster, for Wikimedia.Feedback
Today: Going to poke people about review on feedback form
Will help with VE code review
*Matthias*:
Review for VE switching code, patched for breaking links