https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-09-21
= 2016-09-21 =
== Product ==
=== Editing ===
==== Collaboration ====
* Blocking
* Blocked
** Services is working with us on the ReviewStream feed we're developing.
* Updates
** Continued work on MessagePoster. PageTriage change to use it up, but
not merged yet
** Fixed moderation (e.g. when a page or topic is deleted) of Echo
notifications
** Some other Echo changes, such as to how seen time works, GENDER i18n,
and to the page-linked notification
==== Language ====
* Blocked: none
* Blocking: none
* Updates:
** Content Translation work continue; templates and other fixes.
** Jessie migration for Apertium is scheduled on October first week.
==== Parsing (Subbu not attending because of a conflict) ====
* Blocked: Parsoid's native <gallery> implementation is blocked on getting
feedback from the VE team.
* Patches in gerrit to parse language variant markup in Parsoid -- need to
resolve a few questions before we can deploy this
* Magic-word based optout of global user pages merged (__NOGLOBAL__)
* Kunal has filed an RFC to remove magic link functionality in the parser:
https://www.mediawiki.org/wiki/Requests_for_comment/Future_of_magic_links
* Evaluation ongoing of a (already merged in core) PHP version of a HTML5
parser (as a potential replacement for Tidy).
=== Community Tech ===
* No blockers
* Copyvio tools for French Wikipedia
https://phabricator.wikimedia.org/T145431
* More performance testing in hopes to get PageAssessments deployed to
English Wikipedia
* Education Programs Dashboard https://phabricator.wikimedia.org/T125546
* Changes to CentralAuth for cross-wiki watchlists
* Investigating work on improving blocking and harassment prevention tools
=== Reading ===
==== Reading Web ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2186/
* Preparing to enable hovercards ab test in italian and russian
* Preparing to enable related articles in mobile in more wikis
* Lazy images blog post
* Next sprint: https://phabricator.wikimedia.org/project/view/2221/
* Enable related articles in mobile in more wikis
==== Mobile Content Service (MCS) ====
* Getting the aggregated feed endpoint working on Beta Cluster since feed
aggragation happens in RB now.
==== Android native app ====
* Current sprint: https://phabricator.wikimedia.org/project/view/2216/
* Next sprint: https://phabricator.wikimedia.org/project/view/2238/
* Released to beta Monday 9/19. Plan is to get feedback, fix bugs, and
release nav overhaul to the stable app by EOM.
==== iOS native app ====
* Current release board:
https://phabricator.wikimedia.org/project/view/2188/
** In regression
** Expected to be released Sept 21
* Next release board: https://phabricator.wikimedia.org/project/board/2220/
** In progress
** MIgrating iOS Feed over to the MCS
** Adding In the news and a local notification
** Expected Delivery ~3 weeks
==== Reading Infrastructure =====
* no
=== Fundraising Tech ===
* Almost done getting rid of ActiveMQ!
* Fixing CentralNotice db calls for strict mode
* More refinements to CiviCRM contact de-duplication
=== RelEng ===
* Blocking
** no
* Blocked
** wmf.18 load-time regression https://phabricator.wikimedia.org/T146099
* Updates
** Skipping wmf.19 entirely due to undiagnosed load-time regression
https://wikitech.wikimedia.org/wiki/Incident_documentation/20160915-MediaWi…
*** Tentative plan is to cut wmf.20 and deploy to group0 today and, if all
goes well, adjust the remainder of this week's schedule accordingly
*** https://phabricator.wikimedia.org/T144644#2654240
** Completed Beta Cluster database migration to jessie/MariaDB 10 yesterday
** Reminder: no deploys week of Sept 26th
** Reminder: no train week of Oct 17th (but SWATs OK)
=== Analytics ===
* Blocking: None
* Blocked: None
* Updates:
** New AQS cluster is up! Massive reduction of latency. We'll increase the
throttling threshold.
** Public Event Streams: Finalized Kasocki prototype. Considering using
server side events / streaming instead of web-sockets.
** Edit history reconstruction: Some improvements on the quality of data,
still a couple issues to fix.
** Pivot (druid based UI): More work on productionizing it using
servicerunner
** A/B testing design - Evaluating feasibility of design ideas.
** Nuria participated in the Technology off-site, very productive.
=== Technical Operations ===
* '''Blocking'''
** None
* '''Blocked'''
** None
* Updates
** TechOps offsite happening week of Sept 25 (last week of quarter), please
work around this for deployments
** Will not be able to attend SoS for the same reason
** Puppet migration complete
** Varnish upload cluster upgraded to version 4. There are some caveats,
but looking good https://phabricator.wikimedia.org/T145661
** Apertium migration to Jessie scheduled for Oct 3
** OpenStackManager in wikitech is being deprecated. There will be
information coming your way in the next weeks.
=== Security ===
* Patch deployed for CentralAuth on monday; let us know if you experience
weirdness
* Will follow-up on Youdao review (
https://phabricator.wikimedia.org/T143185)
* Catching up on e-mail, Gerrit, and Phab traffic from last week
=== Services ===
* Blocking: none
* Blocked: none
* Updates:
** Huge RESTBase deployment, VE now usable on undeleted articles
** Change-Prop: separated transclusions topics - decrease user visibility
of lagging
** Trending service planning with reading
** Bad articles stream planning
=== Discovery ===
* No blockers
* Analyzing BM25 A/B test, if results are positive deployment will be
somewhere early October
* Working on multiwiki indexes, public comments sought at:
** https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements
**
https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Design
* Working on file properties indexing (size, type, dimensions, etc.)
* WDQS servers on codfw deployed, looking into how to add them to
production setup
* Portal: updated portal strings to "Read Wikipedia in your language" and
language wiki descriptions.
== Wikidata ==
* Blocker: Can not connect to the Hangout on
https://hangouts.google.com/hangouts/_/wikimedia.org/scrum-of-scrums. Get
error "HJR: 2-RNF".
* No other ;-) blockers at the moment.
* Making usage information (which page on which wiki uses which Wikidata
entity) visible to users: https://phabricator.wikimedia.org/T103091
* Introduced batching in the job that notifies wikis about changes on
wikidata.org: https://gerrit.wikimedia.org/r/309972,
https://phabricator.wikimedia.org/T107722
* Working on cleaning up several dependencies on legacy stuff in core, e.g.
https://phabricator.wikimedia.org/T144977
* Pushing multi content revisions forward.
On Tue, Sep 20, 2016 at 10:05 AM, C. Scott Ananian
<cananian(a)wikimedia.org> wrote:
> Here are three topic suggestions, cc'ed here in case folks aren't following
> the Flow, with an illustrative (but not exhaustive) list of sessions that
> could fit under each
Thanks for doing that breakdown! I incorporated your suggestions into
this page:
<https://www.mediawiki.org/wiki/WikiDev17/Topic_ideas>
I suspect each of the three ideas you presented here are worthy of
separate threads (and perhaps separate on-wiki conversations), so I'll
reply to at least the first part under separate cover.
Rob
<quote name="Aaron Schulz" date="2016-09-20" time="15:31:44 -0700">
> How far ahead of time must entries be added?
I trust most people's best judgement here :)
But, as soon as you have an idea of when you'll do it is the best time
to do it. Obviously if the task will impact others and/or require no
other deploys at the same time that should be scheduled further in
advance (~1 week) than something that is low-risk and will be completed
in 2-3 hours.
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
The last couple years we've done a big MediaWiki Dev Summit in January,
around the time of the Wikimedia Foundation all-hands meeting. Invitations
have been fairly broad to known developers, but there's a very strong
feeling that newbies, non-technical people, and in general *the people
MediaWiki is created and maintained for* are not welcome.
I think we should change this.
I would really like a broader MediaWiki Dev Summit that asks our users to
participate, and asks "developers" to interact with them to prioritize and
work on things that really matter to them.
I want template authors, Lua module authors, template users, power editors,
folks working on the lines of defense for vandalism patrol and copyvio
checking. I want people with opinions on discussion systems. I want people
who have been editing for years and have experience with what works and
what doesn't. I want people who wish they could edit but have a bad
experience when they try, and want to share that with us so we can help
make it better.
Thoughts?
-- brion
Hi all!
This Wednesday the ArchCom office hour will be about discussing the next steps
towards support for Multi-Content Revisions (MCR). The focus will be on the
heart of the proposal, the database schema for associating multiple content
objects with a single revision[1]. The basic schema was discussed recently in
the context of improving content model storage[2]. This session will be about
resolving some remaining questions about the schema, and about discussing the
deployment and migration strategy.
Detail questions:
- Do we want a single names table, or separate tables for content_model,
content_format, etc?
- Do we need cont_hash (or cont_sha1) and cont_logical_size?
- De we re-use or copy content rows?
- If we re-use, does the role live in the content or in the slot label?
Broader questions:
- Are the scaling and Efficiency estimates correct?
- What options do we have for optimization?
- Would the proposed migration plan work?
The discussion is scheduled for 2016-09-21 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E273][3]
[ArchCom/Status][4]
Daniel
[1]: <https://www.mediawiki.org/wiki/Multi-Content_Revisions/Content_Meta-Data>
[2]: <https://phabricator.wikimedia.org/E261>
[3]: <https://phabricator.wikimedia.org/E273> Upcoming meeting
[4]: <https://www.mediawiki.org/wiki/Architecture_committee/Status>
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Due to an unexpected production database outage during last week's
maintenance window, we were unable to complete the Beta Cluster database
migration to the new Debian jessie instances. We'll be performing this
migration during a three-hour read-only maintenance window tomorrow from
1400-1700 UTC.
Please contact Release Engineering (#wikimedia-releng) if you have
concerns/questions regarding this process, or refer to the Phabricator task
(T138778).
https://phabricator.wikimedia.org/T138778
Thanks,
Dan
--
Dan Duvall
Software Engineer, Release Engineering
Wikimedia Foundation <http://wikimediafoundation.org>
Hi all,
I've tried to sort out some "probable" and interesting internship projects
which have a well-defined scope and/or *one* mentor willing to support it.
Please go through them, and let us know if you'd like to mentor, so that we
can feature it for Outreachy-13 [0]( Dec 6 to March 6 ).
*Needing Primary mentors:*
1. Fork NYPL emoji bot for Commons images (to give back 'similar'
Commons images) - T143593 [1] - Interesting project on emojis, @*Melody*
has agreed to provide design help, just needs technical help from someone.
2. Document process for creating new Zotero translator and getting it
live in production - T115158 [2] - *@Mvolz* has agreed to be co-mentor.
We need a primary mentor.
3. Editor-focused dashboard gadget - T91655 [3] - An interesting idea of
a gadget for personalized user pages for editors - *@Mvolz* has agreed
for co-mentor. We need a primary mentor.
4. Remind me of this article in X days - T2582 [4] - Interesting idea to
create reminders for editors. *@Mattflaschen and @Mooeypoo* have agreed
to be co-mentor, we need a primary mentor.
*Needing co-mentors*:
1. Improvements to ProofreadPage Extension and Wikisource - T128840
[5] - *@Yann* has agreed to help with fixes fro ProofreadPage Extension,
needs a co-mentor.
2. Pywikibot to detect and correctly handle edits that trigger
abusefilter rules - T85656 [6] - *@jayvdb* is mentoring, we need a
co-mentor
With some help we can feature these projects for Outreachy-13 and have some
more cool ideas for students to work on.
For signing up as a mentor, just add yourself on the task, or ping and
we'll do the rest.
Please do consider giving a shot :)
[0] - https://www.mediawiki.org/wiki/Outreachy/Round_13
[1] - https://phabricator.wikimedia.org/T143593
[2] - https://phabricator.wikimedia.org/T115158
[3] - https://phabricator.wikimedia.org/T91655
[4] - https://phabricator.wikimedia.org/T2582
[5] - https://phabricator.wikimedia.org/T128840
[6] - https://phabricator.wikimedia.org/T85656
--
-Thanks and Regards,
Sumit
Outreachy-13 Org Admin
Hi,
I only now noticed that Phabricator has blogs:
https://phabricator.wikimedia.org/phame/blog/
I couldn't find a way to subscribe to them in RSS. Is it possible?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
In the last day I've seen quite a few images that throw errors when
trying to view them (for example, [1]). Already-existing thumbnails
work, but when one tries to force rendering new sizes, the server
throw an error message: "Error! Our servers are currently experiencing
technical difficulties".
Is this a know issue? It doesn't seemn to be anything wrong with the
images themselves, because they were previously used in articles.
Strainu
[1] https://ro.wikipedia.org/wiki/Fi%C8%99ier:Cele_mai_%C3%AEnalte_cl%C4%83diri…
I am pleased to announce that, thanks to Google Summer of Code student
Priyanka Mandikal, the project for the Accuracy Review of Wikipedias
project has delivered a working demonstration of open source code and
data available here:
https://github.com/priyankamandikal/arowf/
Please try it out at:
http://tools.wmflabs.org/arowf/
We need your help to test it and try it out and send us comments. You
can read more about the project here:
https://priyankamandikal.github.io/posts/gsoc-2016-project-overview/
The formal project report, still in progress (Google docs comments
from anyone are most welcome) is at:
https://docs.google.com/document/d/1_AiOyVn9Qf5ne1qCHIygUU3OTJcbpkb14N3rIty…
This allows experiments to measure, for example, how long it would
take to complete proofreading of the wikipedias with and without
paying editors to work alongside volunteers. I am sure everyone agrees
that is an interesting question which bears directly on budget
expectations. I hope multiple organizations use the published methods
and their Python implementations to make such measurements. I would
also like to suggest a proposal related to the questions in both of
the following reviews:
http://unotes.hartford.edu/announcements/images/2014_03_04_Cerasoli_and_Nic…http://onlinelibrary.wiley.com/doi/10.1111/1748-8583.12080/abstract
The most recent solicitation of community input for the Foundation's
Public Policy team I've seen said that they would like suggestions for
specific issues as long as the suggestions did not involve
endorsements of or opposition to any specific candidates. My support
for adjusting copyright royalties on a sliding scale to transfer
wealth from larger to smaller artists has been made clear, and I do
not believe there are any concerns that I have not addressed
concerning alignment to mission or effectiveness. I would also like to
propose a related endorsement.
The Making Work Pay tax credit (MWPTC) is a negative payroll tax that
expired in 2010. It has all the advantages of an expanded Earned
Income Tax Credit (EITC) but would happen with every paycheck.
Reinstating the Making Work Pay tax credit would serve to reduce
economic inequality.
This proposal is within the scope of the Foundation's mission because
reducing economic inequality should serve to empower people to develop
educational content for the projects because of the increased levels
of support for artistic production among a broader set of potential
editors with additional discretionary free time due to increased
wealth. This proposal is needed because economic inequality produces
more excess avoidable deaths and leads to fewer years of productive
life than global warming. This proposal would provide substantial
benefits to the movement, the community, the Foundation, the US and
the world if it were to be successfully adopted. For the reasons
stated above, this proposal will be seen as positive.
Here is some background and supporting information:
* MWPTC overview: https://en.wikipedia.org/wiki/Making_Work_Pay_tax_credit
* MWPTC details: http://tpcprod.urban.org/taxtopics/2011_work.cfm
* Problems with expanding the EITC:
http://www.taxpolicycenter.org/taxvox/eitc-expansion-backed-obama-and-ryan-…
* Educational advantages of expanding the EITC:
https://www.brookings.edu/opinions/this-policy-would-help-poor-kids-more-th…
* Financial advantages of expanding the EITC:
http://www.cbpp.org/research/federal-tax/strengthening-the-eitc-for-childle…
* The working class has lost half their wealth over the past two
decades: https://www.nerdwallet.com/blog/finance/why-people-are-angry/
* Health effects of addressing economic inequality:
http://talknicer.com/ehlr.pdf
* Economic growth effects of addressing economic inequality:
http://talknicer.com/egma.pdf
* Unemployment and underemployment effects of addressing economic
inequality: http://diposit.ub.edu/dspace/bitstream/2445/33140/1/617293.pdf
For an example of how a campaign on this issue could be conducted
based on the issues identified in the sources above, please see:
http://bit.ly/mwptc
Please share your thoughts on the wikipedias proofreading time
measurement effort and this related public policy proposal.
I expect that some people will say that they do not understand how the
public policy proposal relates to the project to measure the amount of
time it would take to proofread the wikipedias. I am happy to explain
that in detail if and when needed. On a related note, I would like to
point out that the project report Google doc suggests future work
involving a peer learning system for speaking skills using the same
architecture as we derived from the constraints for successfully
performing simultaneous paid and volunteer proofreading. I would like
people to keep that in mind when evaluating the utility of these
proposals.
Sincerely,
Jim Salsman
