I've posted an RFC at ...
https://meta.wikimedia.org/wiki/Requests_for_comment/Switch_default_categor…
... proposing that we change the default collation for Wikimedia wikis from
"uppercase" to "uca-default-u-kn" (Unicode Collation Algorithm with numeric
sorting). Please join the discussion if you have any thoughts on this.
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
