Wikitech-l November 2016

wikitech-l@lists.wikimedia.org

94 participants
100 discussions

2016-11-09 Scrum of Scrums meeting notes
by Grace Gellerman 09 Nov '16

09 Nov '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-11-09 =2016-11-09= ==Product== ===Reading=== ==== Mobile Content Service ==== * Deployed: * Added more testing of response formats. * Removed hard-coded blacklist for most-read. Now using a more dynamic way to filter out pages that should not appear in the list of most-read articles. * Working on figuring out a short-term and medium-term solution for too small thumbnails for TFA and POTD in feed. (Once we get a better thumbnail API then we would be eager to switch to that, of course.) - Extra info: The cause of this problem is that now summary data (including a thumbnail) for the feed gets hydrated using the details from the /page/summary endpoint, and that is currently always capping the thumbnail size to 320px. A potential medium-term solution would be to increase the thumnails size cap in the summary endpoint from 320px to 640px and have the clients change the thumbnail URLs to have the size capped to at most 320px for the items the client is showing at a smaller size (trending, link previews, ...). https://phabricator.wikimedia.org/T149450 ====Android==== * Current sprint (https://phabricator.wikimedia.org/project/view/2331/): * Continuing Q2 goals for Wikidata descriptions * Beta coming soon * Cleaned up lots of little tech debts * Fix some UI bugs and memory leaks * Next sprint: * More Q2 goals for Wikidata descriptions (mostly polish) ====Web==== * Current sprint: https://phabricator.wikimedia.org/project/board/2336/ - * Hovercards re-write - * Page images API change to return free and non-free images - * Bugfixes - * Trending service * Next sprint: * Similar to current sprint * Also tech debt ====iOS=== https://phabricator.wikimedia.org/project/view/2220/ * Last week: - * In the news - bug fixes, UI updates, & tweaks to notification scheduling logic - * Fixed remaining issues from persistance layer update - * Finished first pass of accessibility changes - VoiceOver improvements for the explore feed & both widgets * This week: * More 5.3.0 beta feedback & fixes * Add donation announcement card to the news feed * Set up nightly alpha builds and investigate speedup of automated tests run on each pull request ==== Reading Infrastructure ==== * Not blocking/blocked * finishing up action API error localization and pageview data integration (T47843, T144865) * planning to deploy the latter with PageViewInfo extension in first week of December === Discovery: Interactive Team === * Launching <mapframe> on ruwiki today * Shared multilingual tabular and map data on Commons is on beta cluster, getting ready for launch, hopefully within 1-2 weeks ** Posted on wikitech-l, FB, T134426 ** Demo: https://en.wikipedia.beta.wmflabs.org/wiki/Maplink-page and https://en.wikipedia.beta.wmflabs.org/wiki/Dimpvis_-_Fertility_vs_Life_Expe… === Community Tech === // Sorry, I won't be able to make it to the meeting today. * Started with the wishlist survey this week: https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey ** Urge everyone to take a look and comment on proposals relevant to their field of expertise * Starting to work on updating CentralAuth migration scripts to populate the additional fields added for global watchlist. https://phabricator.wikimedia.org/T149111 * Work continues, albeit a little slowly, on the ticket for sending a cookie with each block to prevent abuse: https://phabricator.wikimedia.org/T5233 ** Can use more reviews: https://gerrit.wikimedia.org/r/#/c/48029/ ** Eventlogging for the feature: https://phabricator.wikimedia.org/T146230 * French copypatrol version ready to be deployed, waiting for Eranbot to start getting data (i.e. plagiarized edit records) for frwiki ===Wikidata / WMDE=== * more work on automated sitelinks for Wiktionary (Cognate extension) * Wikibase Repo federation / foreign repo access (for Wiktionary and Commons support) * RevisionSlider - out of beta (feature) for German and Arabic Wikipedia on Nov 22 (per community request) * ElectronPDF ** extension had security review, we addressed the issues and wait for review again ** depends on service to be deployed (it's also in security review) == Technology == === Analytics === * Blockers: none * Blocked: none Updates: ** Hiring: an offer is about to be made to a candidate, we continue to review new candidates ** MediaWiki History (edits, users, pages, all projectws except commons and wikisources) is being vetted, results seem good if not very good. *** Varnishkafka errors are down to a not-yet-seen level with Varnish4. Thanks Luca and the traffic team for the thorough work. === Architecture / ArchCom === === Release Engineering === * Blocking ** * Blocked ** * Updates ** 1.28 rc.1 today ** Help squash boogz! https://phabricator.wikimedia.org/project/board/1982/ === Security === * Security Reviews * Linter extension * Continued work on CSRF mitigation for anons ( https://phabricator.wikimedia.org/T40417) * Reviewing patch to login workflow ( https://gerrit.wikimedia.org/r/#/c/312865/) * Repairing OpenVAS scanning for FrTech * OATHAuth * Deployed extension on all private wikis * Deployed account prefix configuration in production ( https://gerrit.wikimedia.org/r/#/c/320266/) * Password Handling * Increased password length for bots to eight characters ( https://gerrit.wikimedia.org/r/#/c/318951/) * Strengthened password requirements for Abuse filter editors ( https://gerrit.wikimedia.org/r/#/c/319000/) * Strengthened password requirements for all users on private wikis ( https://gerrit.wikimedia.org/r/#/c/319598/) === Services === * Blockers: none * Updates: nothing big, tech debt and small improvements ** Working on improving CORS and redirection support in RESTBase: https://phabricator.wikimedia.org/T149295 ** Electron PDF Rendering Service passed security review - preparing for deployment. === Technical Operations === * Blocked: ** None * Blocking: ** None * Updates: ** Container registry implemented for our kubernetes goal. It will be read only of course. ** labsdbs setup and provisioned ** ulsfo and codfw are varnish 4 ** gallium is no more (Big thank you to releng!) ** Got plans to deploy the Trending Edits Service by the end of November (with Services) === Performance == * Blocked ** Operations code review on Thumbor https://gerrit.wikimedia.org/r/#/c/315648/ https://gerrit.wikimedia.org/r/#/c/317522/ ** Consensus/Dev summit to unlock further work on active/active DC project (etcd, session storage, varnish, etc.) * Blocking: ** None * Updates: ** Ori is a volunteer now ** Decision about team management still pending ** UCMini in speed mode "blacklisting" to be treated as grade C browser merged ** Working through resource limiting on Thumbor (issue where IM consumes huge amounts of disk due to lack of limit) ** Investigation on frontend performance regression merged, to investigate if people opening tabs in background tabs are responsible for spike in higher percentiles after recent change === Fundraising Tech === * Bugfixing, log quieting * Fixing offline donation imports and mailing list exports * Still puzzling over CentralNotice bug ** patch: https://gerrit.wikimedia.org/r/318488 ** bug: https://phabricator.wikimedia.org/T144952 * Testing more streamlined mobile donation flows === Editing === ==== Collaboration ==== * Flow in multi datacenters: merge and test this week, release next week (hopefully) * Flow beta feature: fixing broken user pages before re-enabling the beta feature, no ETA for all pages to be fixed * ERI ReviewStream: agreement with Services about way to go and next steps * ERI Special:RecentChanges: new filters in Core, new UI in the making * Blocking or blocked: none

1 0

Shared localized maps data demo
by Yuri Astrakhan 09 Nov '16

09 Nov '16

I would like to show one of the projects that Interactive team has been hacking on: localizable maps data (GeoJSON), stored on Commons, and usable from multiple wikis. I hope we can get it polished and enabled in production soon enough - so far, lab's beta cluster only: https://en.wikipedia.beta.wmflabs.org/wiki/Maplink-page

1 1

Congratulations to {4} Outreachy'13 selects from Wikimedia
by Tony Thomas 09 Nov '16

09 Nov '16

Hello all, Happy to announce that we have *four* selections for Outreachy'13 this time for the December-March round! You can find the timeline for the event here - https://wiki.gnome.org/Outreachy/2016/DecemberMarch#Schedule Listing down the projects: 1. https://phabricator.wikimedia.org/T147727 - Provide cumulative statistics for all programs a user has participated in - Sejal Khatri. Mentors: Ragesoss, Capt_Swing 2. https://phabricator.wikimedia.org/T148074 - Create Python library to serialize Wikimedia Quiz format, GIFT quiz format, etc - Anna Liao. Mentors: John Mark Vandenberg, Marielle Volz 3. https://phabricator.wikimedia.org/T148287- 5 subprojects with the Reading Department at Wikimedia - Zareen Farooqui. Mentors: Tilman Bayer, Jon Katz 4. https://phabricator.wikimedia.org/T147953 - Hacking: Wiki Radio - Neslihan. Mentors: Nirzar, Adam Baso Congratulations to all students and mentors invovled. This time too, we had to turn down couple of strong applications due to strict outreachy norms on academic and other commitments. We welcome to try again for the 2017 Google Summer of Code and Outreachy as well, and continue at a volunteer capacity. Announcement Link: https://wiki.gnome.org/Outreachy/2016/DecemberMarch#Wikimedia Thanks, Tony Thomas <https://www.mediawiki.org/wiki/User:01tonythomas> Home <http://www.thomastony.me> | Blog <https://tttwrites.wordpress.com/> | ThinkFOSS <http://www.thinkfoss.com>

4 3

2016W45 ArchCom-RFC meeting: official thumb API
by Daniel Kinzler 09 Nov '16

09 Nov '16

Hi all! Today at the ArchoCom-RFC meeting [E355], we will talk about defining an official thumbnail API [T66214]. At last week's ArchCom meeting, Gabriel said that at least the first part of this RFC (without the hashing bit) is good for an IRC meeting. So let's see how for we can get today. Gabriel, can you say something regarding the status of the RFC, and the desired outcome of today's meeting? Thanks! 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 PS: my appologies for initially linking to the wrong RFC in [E355]. [E355]: <https://phabricator.wikimedia.org/E355> [T66214]: <https://phabricator.wikimedia.org/T66214> [ArchComStatus]: <https://www.mediawiki.org/wiki/ArchComStatus> -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

1 0

1.28 release blocker bugs that welcome help
by Andre Klapper 08 Nov '16

08 Nov '16

MediaWiki 1.28.0 is around the corner [1] & some bug reports are marked as "need to get fixed for 1.28" [2] but do not yet have patches. Your attention, help, and code is welcome: I984b80815633a8 (Stub out DatabaseBase::getSearchEngine()) introduces breaking change without deprecation https://phabricator.wikimedia.org/T147683 Unnecessary words "Creating Category" appear when editing a category page https://phabricator.wikimedia.org/T149510 Error: 42P01 ERROR: table "unittest_user_groups" does not exist https://phabricator.wikimedia.org/T149454 WikiPage::getLastPurgeTimestamp() returning an array https://phabricator.wikimedia.org/T150191 Thanks in advance! andre [1] https://lists.wikimedia.org/pipermail/wikitech-l/2016-October/086859.html [2] https://phabricator.wikimedia.org/maniphest/query/B3w1whqqIxJj/#R -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Phabricator access
by Denny Vrandečić 07 Nov '16

07 Nov '16

Phabricator still has my wikimedia.de Email-Address and tries to confirm it's me by sending an Email to that address. Is there a way to reset the email? (The weird thing is that I seem to receive those Emails on my regular gmail account, but for logging in it still requires that I verify the wikimedia.de address? I am a bit confused)

3 2

Re: [Wikitech-l] [MediaWiki-l] SecurePoll project needs your help
by Greg Grossmeier 07 Nov '16

07 Nov '16

Looping in wikitech-l as well. <quote name="Huji Lee" date="2016-11-07" time="12:28:09 -0500"> > Dear all, > > SecurePoll is an important extension for the WMF community, yet not a whole > lot of attention has been given to it over the years. I recently became the > owner of the project, and would like to remind you that with the EN WP > ARBCOM elections coming up, it would be great if you could help the > SecurePoll project in the following ways: > > 1) Review patches: we have a few outstanding patches that address key > issues with SecurPoll. They await reviews, especially by those holding +2 > rights. Please spare a moment and review them. > > 2) Submit patches: we have quiet a few open tasks for which no patch has > been submitted. Please spare a moment on this as well. > > For your convenience, here are patches awaiting review [1] and here are > open tasks awaiting a patch. [2] > > Sincerely, > > Huji > > [1] > https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/SecurePoll+… > [2] https://phabricator.wikimedia.org/search/query/xlYokZ6kvoMd/ > _______________________________________________ > MediaWiki-l mailing list > To unsubscribe, go to: > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | Release Team Manager A18D 1138 8E47 FAC8 1C7D |

1 0

Re: [Wikitech-l] Engaging student devs with another outreach event like GSoC, GCI
by Yaron Koren 07 Nov '16

07 Nov '16

Hi, I hit across this idea in the recent GSoC Mentors summit, and in the > discussion with Srishti and Sumit on the reducing usability and scope of > GSoC/Outreachy projects[1] among the years. > *The problem* > Students show up one or two weeks before GSoC or Outreachy, and propose a > solution to existing ideas, and often end up completing it and leaving the > project. Due to this, there is a decline in student-proposed ideas as well, > given 1-2 weeks is not enough to understand Wikimedia from any direction. I didn't really understand this. You seem to be talking about some or all of the following issues: 1) Fewer students doing projects for the Wikimedia Foundation as part of the Google Summer of Code and, I guess, Outreachy, than in previous years - 2013 being the high point. 2) Students doing projects that are less useful than in previous years. 3) Students not staying with the Wikimedia/MediaWiki after the conclusion of their project. 4) Students doing projects proposed by existing MediaWiki developers, rather than projects they proposed themselves. I see these as four unrelated issues, and actually I see only two of them as real issues: #2 I don't think is true (though I'm not sure if that's what you meant by "usability"), while #4 I don't see as an issue at all. Personally, I think only projects proposed by potential mentors should be considered at all, and that the documentation should state that clearly. I'm not aware of any GSoC projects where the student came up with the idea on their own and then executed on it successfully - with the exception of projects where the student is an established MediaWiki developer who happens to currently be in college, but that's obviously a special case. It's just not reasonable to expect that someone from outside the WMF/MediaWiki community would be able to come up with a project that (a) makes sense, (b) fits within the current development roadmap, and (c) is of the right scope for a GSoC/Outreachy project. More generally, I don't think there's anything less rewarding about doing a project that someone else came up with. In software development, as in most things, the difficult part - and the most rewarding part - is the execution, not the original idea. (There are various inspirational quotes to this effect.) That leaves #1 and #3 - fewer students participating, fewer students staying on afterwards. I think #1 is just a function of fewer potential mentors getting involved. Retaining students, on the other hand, is a real problem. I can think of various ways to try to improve this, though creating a new outreach/funding program seems extreme - it would take a lot of work, and you would presumably run into the same problem of a limited number of mentors. If there's money to pay for these kinds of things, why not just put more money into, say, hiring more developers from out of the GSoC pool? It's one idea. -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com

6 10

2016 Community Wishlist Survey
by Danny Horn 07 Nov '16

07 Nov '16

Hi everyone, The second annual Community Wishlist Survey starts today, and you're invited to post proposals for projects that you'd like WMF's Community Tech team to work on: https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey The Community Tech team builds features and makes changes that active Wikimedia contributors want, and the Wishlist Survey sets the team's agenda for the year. The Wishlist Survey starts with a two-week proposal period, when contributors from all Wikimedia projects are invited to post, discuss and improve propsals. After that, there's a two-week voting period, when everyone can post support-votes on the proposals that they think are worthwhile. We end up with a ranked list of wishes, measured by the participants' enthusiasm for each idea. Community Tech is responsible for addressing the top 10 wishes on the list, as well as some top wishes from smaller groups and projects that are doing important work, but don't have the numbers to get their proposal into the top 10. The Wishlist is also used by volunteer developers and other teams, who want to find projects to work on that the community really wants. So I hope that everybody comes and participates; it's an opportunity to set the agenda for a Wikimedia Foundation product team. We would also ask that you help us spread the word. Please do post on your wikis and tell others this is happening, and that if they don't feel comfortable writing in English, proposals are welcome in any language. Danny Horn Wikimedia Foundation Senior Product Manager, Community Tech

1 0

Wikimedia takes part in Google Code-in. Which small tasks do you plan to mentor?
by Andre Klapper 07 Nov '16

07 Nov '16

Wikimedia is among the 17 organizations in Google Code-in (GCI) 2016! GCI starts on November 28th. It's a contest for 13-17 year old students working on small tasks and a great opportunity to let new contributors make progress and help with smaller tasks on your To-Do list! What we want you to do: BECOME A MENTOR: 1. Go to https://www.mediawiki.org/wiki/Google_Code-in_2016 and add yourself to the mentor's table. 2. Get an invitation email to register on the contest site. PROVIDE SMALL TASKS: * Do your docs on your wiki need some improvements? * Does your template or gadget code needs some updates? * Do you have small and self-contained bugs you'd love to get fixed? * Does your UI have small design issues? * Do your old bugs welcome some testing? We want your tasks in the following areas: code, outreach/research, documentation/training, quality assurance, user interface/design. 1. Create a Phabricator task (which would take you 2-3h to complete) or pick an existing Phabricator task you'd mentor. 2. Add the "Google-Code-In-2016" project tag. 3. Add a comment "I will mentor this in #GCI2016". Looking for task ideas? Check the "easy" tasks in Phabricator: https://www.mediawiki.org/wiki/Annoying_little_bugs offers links. Make sure to cover expectations and deliverables in your task. And once the contest starts on Nov 28, be ready to answer and review contributions quickly. Any questions? Just ask, we're happy to help. Thank you for your help broadening our contributor base! andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l November 2016