On Tuesday Nov 13, at 9 am UTC, the web server for the dumps and other
datasets will
be unavailable due to maintenance. This should take no longer than 10
minutes. Thanks for your understanding.
Ariel
Hi,
YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been
working the UrlShortener extension, which is designed to implement the
URL shortener RfC[1] (specifically Tim's implementation suggestion).
I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd
like to use the "w.wiki" short domain, which the WMF is already in
control of.
A test wiki has been set up mimicking what Wikimedia's configuration
would be like: http://urlshortener.wmflabs.org/, and has an accompanying
"short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please
play with it and report any bugs you might find :)
[1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener
[2] https://phabricator.wikimedia.org/T108557
Thanks,
-- Legoktm
Hi,
bawolff wrote:
I actually disagree somewhat - I think it can be very rewarding to fix
> a problem that you yourself have, as opposed to fixing somebody else's
> problem. This is a traditional ideology about open source - that it is
> all about scratching your own itch.
> Although arguably most gsoc students coming up with their own projects
> aren't actually scratching their own itch but desperately trying to
> come up with an idea. However, if someone happens to be a preexisting
> user of MediaWiki, and finds something they find super annoying, I
> think that can make for a very good project.
In theory this is true. In practice, I'm not sure if there has ever been a
successful WMF GSoC project where the idea was the student's own - other
than in cases where the student was already part of the MediaWiki
community. Which makes sense: if a student's only experience with MediaWiki
is, say, reading and writing wiki articles, then chances are good that
whatever they find annoying is something that many other people also find
annoying, and thus would have been fixed already if it were easy to fix.
bawolff also wrote:
As for users sticking around - I think the communication around gsoc
> has shifted from "Here's some money so you can work on MediaWiki
> without starving to death" to "Here's a little money and a job so you
> can put something cool on your resume". If students are being
> attracted to the program principally to have something on their resume
> or for the money (To be clear, I'm not saying there is anything wrong
> with that), its not surprising that they leave afterwards when the
> money goes away. If we want to attract people in the long term, we
> should probably come up with a better carrot.
Yes, this is absolutely the issue. I don't know if there's a lower
"conversion" percentage now than there used to be, but certainly to
convince people to do free labor for you, especially if their first
experience with you involved payment, seems difficult. That's assuming that
free labor is the ultimate goal, as opposed to, say, finding more people
for the WMF to hire. More on that below.
Tony Thomas wrote:
I would want to agree to disagree at places like - 'hiring everyone of
> them' or things like that. If we are talking about making people stick,
> the model I am talking about would be a *cheaper *option ?
I assume that's a reference to what I wrote, although I certainly didn't
say to hire everyone - I said "students who had useful projects". I don't
know which option would be cheaper - hiring some of the students or setting
up a new mentorship program - but the main question is really what the goal
is. Is it to get more free labor over the long term? If so, I don't know if
either option is that effective. Personally, I think it's great if such
projects result in actually useful software, and it's a shame if that
software goes uncompleted or abandoned at the end of the program.
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
Hi Jonathan,
On Thu, Nov 10, 2016 at 7:12 PM, Jonathan Morgan <jmorgan(a)wikimedia.org>
wrote:
> Hi Quim,
>
> Could you provide a little more detail about what is required from session
> proposers for the Nov. 28th deadline? It says "Deadline for consolidating a
> discussion, regularly summarized in the proposal." But I'm not sure yet I'm
> expected to do.
>
> I see that a plurality of submissions are currently in the "missing active
> discussion" lane on the Phab board. To me, that wording implies that unless
> there is active discussion on the phab ticket, the proposal is unlikely to
> be selected. Is that accurate? If so, what kind of discussion should I be
> encouraging, as a session proposer, and how much discussion is enough?
>
Your question is totally fair. :) We are building this process as we go,
and your ideas and criticism are very important ingredients.
I have tried to explain reasons and expectations about this deadline at
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Call_for_par…
Additional questions and feedback about this deadline and the selection
process in general are welcome in the related Talk page:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit/2017/Call_fo…
> It seems clear that I should be letting people know about my session.
> Should I encourage them to post a comment indicating their interest, or to
> ask a question in the thread? Or is it enough if some people subscribe to
> the task?
>
"Passive" demonstrations of interest like subscribing to the related
Phabricator task (or awarding tokens, a possibility that we have started to
discuss) are definitely useful to prove that someone is interested about
the topic beyond the person or small group proposing it.
However, active discussions are the sauce of the Summit. There is a lot of
competition for the pre-scheduled slots. We'd rather assign these slots to
the discussions that are already ongoing and will clearly benefit from,
say, well advertised 90 minutes in one room with video recording.
Theoretically relevant proposed topics relying on a discussion just
starting at the Summit are playing a gable. It might just work, but from
the Program committee perspective that is risky gamble to bet our (rather
expensive) space and participants' attention span.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hey,
This is the 29th weekly update from revision scoring team that we have sent
to this mailing list.
Deployments:
- We deployed logging changes to ORES that will reduce the verbosity[1]
- We also deployed revscoring 1.3.0 and new models built with it to WMF
labs[2]. This won't change anything important from a user-perspective, but
it paves the way for developing new modeling strategies.
Maintenance and robustness:
- We fixed puppet so that log file directories are also created on the
celery worker nodes (affects wmflabs)[3]
- We fixed an issue with our recall_at_fpr metrics which was incorrectly
defined and implemented a recall_at_precision metric to take its place[4]
New development:
- We've made a lot of progress on modeling sentences and have just
started experimenting with a sentence model from featured articles[5]
- We're reviewing a dataset of spam/vandalism/attack new page creations
for public release[6]. This dataset will help our collaborators work with
us on modeling the quality of drafts and supporting new page triage.
1. https://phabricator.wikimedia.org/T149730 -- Deploy logging changes to
ORES
2. https://phabricator.wikimedia.org/T150447 -- Deploy revscoring 1.3.0 and
updated editquality and wikiclass to wmflabs
3. https://phabricator.wikimedia.org/T149925 -- /srv/log/ores/ not created
on worker nodes
4. https://phabricator.wikimedia.org/T149825 -- Implement recall at
precision (and fix FPR metrics)
5. https://phabricator.wikimedia.org/T148867 -- Implement sentences
datascources & experiment with normalization.
6. https://phabricator.wikimedia.org/T150307 -- Create manually vetted
dataset of spam/vandalism/attack pages
Sincerely,
Aaron from the Revision Scoring team
Hello everyone,
we've released OOjs UI 0.18.0 today. It will be in MediaWiki core from
1.29.0-wmf.2,
which will be deployed to Wikimedia production in the regular train, starting on
Tuesday 15 November. As in this release there are six breaking changes, at least
nominally, please carefully look over them to see if they affect your code.
Breaking changes since last release:
* TextInputWidget: remove `isValid()` method, deprecated since v0.12.3
(Ricordisamoa)
Though named "isValid", this function has always returned a Promise, and not a
boolean (the Promise was resolved with true/false). Way back over a
year ago in
v0.12.3 we introduced `getValidity()` instead, with saner semantics
(it returns
a Promise that is resolved or rejected depending on validitity), with the old
function left in for backwards compatibility. We're now removing the
old function;
if you're still using it, you'll need to switch over.
* ComboBoxWidget: Remove this deprecated alias for ComboBoxInputWidget
(James D. Forrester)
We renamed the `ComboBoxWidget` to `ComboBoxInputWidget` a year ago,
refactoring
it to inherit from `TextInputWidget`, with the old names left as deprecated
backwards-compatible options. We're now removing the old name; if you're still
using it, you'll need to simply switch over the name of the widget you call.
* core: Remove {add|remove}CaptureEventListener (James D. Forrester)
We provided 'addCaptureEventListener' and its sibling as proxies for
'node.addEventListener' and its sibling with special code to support Internet
Explorer 8. However, from version 0.15.0 we dropped support for that
browser (as
MediaWiki did), so this indirection was no longer necessary. We're
now removing
the old methods; if you're still using it, you'll need to simply
switch over to
the native ones.
* icons: Remove deprecated alias 'photoGallery' (Ed Sanders)
We renamed the 'photoGallery' icon to 'imageGallery' in v0.13.3 in
November 2015,
and left the old name as a duplicate for a while for backwards
compatibility. We're
now removing the old name; if you're still using it, you'll need to
simply switch
over to the new one.
* InputWidget: Remove deprecated #setRTL function (James D. Forrester)
We renamed the 'setRTL' function to 'setDir' in v0.13.1 to be more standard in
our naming and not imply that LTR is the normal direction. We left
the old name
for more than a year, but now it's removed, so you'll switch from passing a
boolean to one of the strings 'ltr' and 'rtl'.
* MediaWiki theme: Remove deprecated `constructive` variables (Volker E)
We scrapped the 'constructive' flagged state in the MediaWiki theme some time
ago. This also removes the Less variables, which we had temporarily set to the
same values as the 'progressive' flag. This might be a breaking change if you
were using these downstream, but it is unlikely.
Deprecations since last release:
* Break out parts of TextInputWidget into a new SearchInputWidget
(Prateek Saxena)
TextInputWidget is being simplified to reduce load, with specialised
assumptions
around behaviour and what icons to display by default moved down
into a bespoke
sub-classed widget for that use case. The old parameters will be respected for
now for backwards-compatibility, but please switch over soon if
you're using the
widget for search.
* CapsuleMultiSelectWidget: Rename to CapsuleMultiselectWidget
(Bartosz Dziewoński)
The capital letter on the 'S' is out of keeping with the rest of our
widgets, so
we renamed it. The old name is left for backwards-compatibility for
at least one
full release cycle, but please do switch over sooner rather than later.
Additional details are in the full changelog[0]. If you have any further queries
or need help dealing with deprecations, please let me know. As always, a general
set of library documentation is available on mediawiki.org[1], and there is some
comprehensive generated code-level documentation and interactive demos hosted on
doc.wikimedia.org[2].
[0] - https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md
[1] - https://www.mediawiki.org/wiki/OOjs_UI
[2] - https://doc.wikimedia.org/oojs-ui/master/
Best,
Volker
--
Senior UX Engineer, Editing
Wikimedia Foundation
volker.e [at] wikimedia
@Volker_E
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
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
