It's that time of year again; the holiday season.
Different from last year:
In the interest of both 1) giving engineers full time off at the end of the
year (not needing to be aware of what code they wrote is being deployed)
and 2) to keep the site reliable during our end-of-year fundraising
pushes there will be 2 weeks (instead of just 1) at the end of December
that are NO DEPLOYS weeks.
Here's the basic outline from now until mid-January (by week):
* Nov 7th: normal
* Nov 14th: normal
* Nov 21st: (Thanksgiving)
** All week: no train
** Mon/Tues: SWATs only
** Wed/Thur/Fri: NO DEPLOYS
* Nov 28th: normal
* Dec 5th: normal
* Dec 12th: normal
* Dec 19th: NO DEPLOYS (XMAS)
* Dec 26th: NO DEPLOYS (XMAS)
* Jan 2nd: normal (with train)
* Jan 9th: no train, SWATs only (but no one from RelEng is garaunteed to
* be around) (DevSummit+All Hands)
* Jan 16th: resume normalcy (Monday is MLK Day)
As always, the canonical location for deployment information is at:
https://wikitech.wikimedia.org/wiki/Deployments
Best,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Greetings,
The Android team has earlier started a consultation [0] several months ago
to collect input on the type of contributions that readers can carry out in
order to help editors and further engage them in our projects, while still
being helpful to our editors. The ideas that have had the most discussion
from that phase, have been further elaborated on with clear wireframes for
demonstration.
Please check the ideas here
<https://www.mediawiki.org/wiki/Reading/Readers_contributions_via_Android>,
[1] and add your feedback to the page.
Kindly note that this is an experiment discussion and an attempt to
understand your needs and perspectives. None of these ideas is so far in
the planning or research phase. This is the first time the reading team is
discussing ideas at the earliest stage possible and we welcome your own,
very early ideas that are discussed as possibilities.
This awesome work has been made possible by Nirzar, Rita, Dmitry and Jon
Katz.
Looking forward to your feedback.
Moushira
[0] https://www.mediawiki.org/wiki/User_Interaction_Consultation
[1] https://www.mediawiki.org/wiki/Reading/Readers_contributions_via_Androidhttps://www.mediawiki.org/wiki/Reading/Readers_contributions_via_Android#Ad…
:
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-12-21
= 2016-12-21 =
== Product ==
=== Reading ===
==== iOS native app ====
* Last Week
** Shipped 5.3.2 (Dynamic text size, data layer update, performance
enhancements) https://phabricator.wikimedia.org/project/view/2281/
** More performance enhancements & bug fixes
** Started work on this day in history MCS endpoint
** Started work on 5.4 (Nearby, Login updates)
https://phabricator.wikimedia.org/project/view/2326/
* This week
** Monitor 5.3.2 release, fix any remaining issues, release 5.3.3 on
Thursday
** Continue work on 5.4
==== Android native app ====
* Last week:
** More bug fixes for new release
** Released v2.4.184 to prod
** Continuing Q2 goals for Wikidata descriptions
* Next week (https://phabricator.wikimedia.org/project/view/2352/ ):
** Holiday
** Work towards release of Wikidata description editing
==== Web ====
* Current Sprint: https://phabricator.wikimedia.org/project/view/2405/
** Mostly finishing up work left from last week
** Allow users who have the NavPopups gadget to use PagePreviews
** Start working towards Wikipedia branding on the mobile site
* Next week: chilling
==== Mobile Content Service (MCS) ====
* Board: https://phabricator.wikimedia.org/project/board/1323/query/open/
* Deployed (last week):
** Emitted etags have double quotes now.
https://phabricator.wikimedia.org/T150886
* To be deployed next year:
** Add additional information to file and user pages clients can use for
rendering
** Ordered news link to have "most relevant" article in a news story appear
first in list
* Working on:
** Adding isDisambiguation flag
==== Reading Infrastructure ====
* working on tech debt mostly
* not blocking
* blocked:
** WMDE on the last API i18n patch before we can move to hard deprecation:
https://gerrit.wikimedia.org/r/#/c/321464/
=== Community Tech ===
* Blockers: None
* Blokced: Nope
* Special page for looking at page assessments data:
https://en.wikipedia.org/wiki/Special:PageAssessments is deployed to all
wikis
* Wikimania scholarships app was updated for the next iteration and will be
deployed in January when the deploy freeze ends
* A draft proposal about setting up a Tool Labs Standards committee:
https://wikitech.wikimedia.org/wiki/Help:Tool_Labs/Tool_Labs_standards_comm…
* Continue to roll out improvements to Programs Dashboard
=== Discovery ===
* No blockers
* Continuing work on crosswiki searching, refactoring Special:Search and
allowing extensions to define query keywords
* Added ICU folding to hewiki
* Added support for returning interwiki results driven by language
detection via API: https://phabricator.wikimedia.org/T142795
* Updated portal stats on Dec 12th (
https://phabricator.wikimedia.org/T128546)
* Wikidata Query Service now supports triple pattern fragments:
https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual#Linked_Da…
==== Interactive ====
* Published Terms of Use for maps:
https://wikimediafoundation.org/wiki/Maps_Terms_of_Use
* Structured data is live, and seems to be working with minor bugs
Fun demos:
** https://en.wikipedia.org/wiki/User:Yurik/Weather_barchart
** https://www.mediawiki.org/wiki/Template:Graph:US_Map_state_highlight
=== Editing ===
==== Collaboration ====
* Blockers: None
* Blocked: None
* Updates:
** Continued work on getting new RC page finished and merged.
** Various bug fixes, e.g. to Echo
** Coordinating about Deferred Changes
** Finishing up processing the Flow survey results
== Technology ==
=== Services ===
* Blockers: none
* Updates:
** Trending service deployed and completely functional. Check it out!
*** https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits
** All scb services config deploys are on scap3 now
** Separated API cluster from appservers cluster
*** https://phabricator.wikimedia.org/T152074
** Moved RESTBase/Parsoid background updates to codfw
** Team availability update:
*** Marko is around until NY and on vacation the week after
*** Petr is on vacation for 2 weeks
*** Eric and Gabriel and on vacation next week
=== Technical Operations ===
* '''Blocked'''
** By none
* '''Blocking'''
** None
* Updates
** Start of Q4 will probably have a DC switchover in it. Goal for Ops (and
other teams) in next quarter is automating and streamlining it more
** preliminary support for encryption when talking to backend appservers is
here
** Ubuntu Precise Pangolin will be fully phased out by end of next quarter
in both labs and production. Services/apps will have to migrate or cease to
be.
=== Fundraising Tech ===
* CiviCRM: data hygiene fixes
* finding and batch refunding unintended duplicate donations, brainstorming
ways to prevent more
* investigated Ireland missing impressions, suspect rural network speeds
are the culprit
* internal dashboard fixes
* fixed mobile style for backup payment processor
=== Analytics ===
* Culmination of 8 months of work, standard metrics computed on
reconstructed mediawiki history:
https://analytics.wikimedia.org/dashboards/standard-metrics/
* Newly updated mediawiki history beta pivot data cube:
https://pivot.wikimedia.org/#mediawiki-history-beta
* stat1001 was replaced with thorium, and stat1001 is being decommissioned
* Thanks very much for the reviews to the mediawiki-Dashiki extension, I'll
be looking to deploy that and JsonConfig to meta early next quarter (any
advice appreciated, but the docs seem comprehensive)
* Starting to clean up datasets.wikimedia.org structure (adding readmes and
keeping everything the same via symlinks)
== Research ==
* Showcase featuring Tor users and Wikipedia Quality Dynamics today at
11:30AM PST, 19:30 UTC. https://www.youtube.com/watch?v=nmrlu5qTgyA
Hi all!
Today's ArchCom office hour will not be an RFC discussion. Instead, it's an open
discussion about the upcoming DevSummit. We cant talk about what you want to do
there, what went good or bad last time, etc.
The meeting will be at the usual time (Wednesday, 21 UTC, 14 PDT, 23 CET)
and place (#wikimedia-office). For an overview of ArchCom activity, see
[ArchComStatus].
-- Daniel
[ArchComStatus]: <https://www.mediawiki.org/wiki/ArchComStatus>
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Hi,
I am a sophomore student at Indian Institute of Technology, Guwahati,
India. I would like to start contributing, and if possible as a GSoC 2017
participant. It would be great to be directed to the right direction to
start contributing.
Thanks
Regards
Mahim Goyal
*Cross posting on purpose, no excuses made.*
Hi,
At Wikimedia Sverige we have been working on an extension called
Wikispeech. It will be a text-to-speech solution which aim to make the
information on Wikipedia more accessible for people that have limited
abilities to read.
This is Wikimedia Sverige's first MediaWiki development project from
scratch and it has been suggested to us that we should ask for endorsements
- as this will make the need clear if/when the extension needs support. So,
if you think that this sound like something important, please let everybody
know it! https://www.mediawiki.org/wiki/Wikispeech#Endorsement
Please spread the word. Best,
André Costa
André Costa | Senior Developer, Wikimedia Sverige | Andre.Costa(a)wikimedia.se
| +46 (0)733-964574
Stöd fri kunskap, bli medlem i Wikimedia Sverige.
Läs mer på blimedlem.wikimedia.se
(Now forking this from the "Changes in colors of user interface" thread.)
Hi Adam,
Thanks for your email.
I don't think that our interface evolves particularly rapidly, our
interface makes me feel like it's 2003 again. I'd like to have our
interface's usability and our workflows be much easier for our users,
both in terms of learning how to use our tools and in terms of
providing guidance about how to adhere to community policies and
norms. However, editing Wikipedia and its sister sites is often much
more complex than posting an update to Facebook, and WMF lacks the
design and engineering resources of big tech companies, so I think
that we're likely to lag behind Facebook and Google for usability for
the foreseeable future.
The issue which I am attempting to address is not a UI change itself
(good or bad) but rather communication about proposed and upcoming UI
changes. Like many other help resources, the videos and their
accompanying materials (such as a quick-reference card that you
mentioned) can be updated with varying degrees of ease and cost. If
people know about changes well in advance, this will make updating
those resources a much smoother experience both for the maintainers
and for the people who rely on those resources for information.
My proposal would be that proposed UI changes which affect large
proportions of the user base should be announced 3 months in advance.
This would provide plenty of opportunity for discussion,
synchronization, and testing of proposed changes. These announcements
could be neatly organized in Tech News, and Tech News could be sent to
this mailing list as well as posted to individuals' personal talk
pages and individual wikis' village pumps. This would likely make Tech
News be a lengthier publication than it is today, but I would find
notifications like these to be highly valuable and I think that other
community members would too. English Wikipedia for awhile had a
wiki-specific list of proposed changes (largely focused on policy, but
also related to technical matters and community organization) that ran
in the Signpost; what I envision for Tech News would be similar except
with a longer time horizon and aimed at technical and design
audiences.
What do you think?
Pine
On Wed, Dec 14, 2016 at 2:07 AM, Adam Wight <awight(a)wikimedia.org> wrote:
> Hi Pine,
>
> That's a really interesting question you bring up, that people develop
> associations between colors and exact positions on the screen, so that
> moving or discoloring a button will jar them out of a pleasant, easy to
> anticipate experience, and will invalidate some of what they learned,
> possibly making the videos less effective teaching tools as the interface
> changes.
>
> I'm not sure what we (wearing my WMF hat) can do to help with the problem,
> however. Change control at the level you're talking about would mean a
> radical reworking of our deployment strategy. As I understand it, the
> alternative is to stockpile code changes and do big software releases on a
> longer timeline, but that's a somewhat discredited approach. If we stick
> to the lighter, weekly deployments then it's inevitable that the interface
> will be evolving rapidly.
>
> Also, let me thank you for your work on the instructional videos! I'm sure
> these will make a huge difference for newbies and might even attract new
> editors. In an ideal world, we could write scripts to automate the UI
> segments you'll be filming, and could even replay them later and replace
> segments to publish new editions of the videos. Short of that, however,
> maybe you could distribute a companion quick reference card, which would be
> easier to keep up-to-date and would illustrate the placement and coloration
> of major components.
>
> I'm happy to see so many of my colleagues in this thread, and feeling
> immensely proud that such a potentially explosive issue (the bigger issue
> of WMF deployments in the context of broader community consensus and
> engagement in the process) was discussed at length, yet there was nothing
> but an outpouring of generosity and assumption of good faith. This is when
> it feels good to be a Wikimedian!
>
> I do think we should start new threads for potential ideas to improve WMF
> deployment communication. Amir's announcement was a wonderful model of
> developer citizenship, and I think the palette change itself is beyond
> reproach. Continuing here makes me uncomfortable really, because our focus
> should not be on Amir's patch or even his announcement, but on the bigger
> issues of two-way communication. Making sure we're targeting policy for
> criticism rather than people is essential to this healthy
> communication--otherwise some of us will feel obliged to defend the person
> being targeted and will struggle to be receptive to the constructive
> content.
>
> Warm regards,
> Adam
After updating my wiki from 1.27.1 to 1.28.0, VisualEditor has stopped working. I click the Edit tab, and the page content fades slightly in color as if VisualEditor were about to load. But then the editor tools don't appear, and Chrome displays a dialog box:
example.com responded: "http" [OK] [Cancel]
There are no PHP errors in the Apache error log, and no errors in the parsoid log file (looks like a normal parsoid access). However, Chrome developer tools show a JavaScript error: BadMethodCallException. If I remove VisualEditor from LocalSettings.php, the error vanishes.
The only extension I am running is VisualEditor; otherwise it's a vanilla MediaWiki that requires users to be logged into read (a private wiki). The same LocalSettings.php files works perfectly in MW 1.27.1.
Has anything significantly changed in VisualEditor that I need to configure it differently?
LocalSettings.php has:
# visual editor
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;
$wgVirtualRestConfig['modules']['parsoid'] = array(
'url' => 'http://localhost:8142',
'prefix' => 'example.com'
);
$wgSessionsInObjectCache = true; /* Using memcached */
$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
The parsoid settings file has:
parsoidConfig.setMwApi({ prefix: 'example.com', uri: 'http://dev.example.com/w/api.php' });
parsoidConfig.useSelser = true;
Thank you for any insights!
DanB
Hi,
grrrit-wm has been subsumed by wikibugs. You'll now see events from
Gerrit reported to IRC by wikibugs. The main purpose of this was to
unify the pretty similar codebases and infrastructure instead of having
to maintain them separately.
I also took the opportunity to fix some silly bugs like the "[]" one.
I'll be archiving the "grrrit-wm" Phabricator project shortly - you can
use the "wikibugs" one to report any issues you notice.
-- Legoktm