Please comment on whether to approve the introduction to the "Committee"
section of the draft Code of conduct for technical spaces.
The draft text is at
https://www.mediawiki.org/w/index.php?title=Code_of_Conduct/Draft&oldid=220…
. This is the part after the "Page: Code of Conduct/Committee" heading
and before the "Diversity" heading.
You can comment at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_introduc…
. A position and brief comment is fine.
You can also send private feedback to conduct-discussion(a)wikimedia.org .
Thanks again,
Matt Flaschen
P.S. Sorry, I should have combined this into my previous email.
Good question - the code tries to fetch the images ahead of them coming
into the viewport. That can mean upon section expansion, as well.
On Tuesday, August 23, 2016, Justin Ormont <justin.ormont(a)gmail.com> wrote:
> This sounds great. Are the images pre-loaded when the user gets close, or
> once it's scrolled into view?
>
> --justin
>
> On Tue, Aug 23, 2016 at 3:48 PM, Volker Eckl <volker(a)wikimedia.org
> <javascript:_e(%7B%7D,'cvml','volker(a)wikimedia.org');>> wrote:
>
>> Amazing work! Enjoying the further speed improvements and the detailed
>> analysis of Japanese Wikipedia testcase.
>>
>> On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson <jrobson(a)wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','jrobson(a)wikimedia.org');>> wrote:
>>
>>> FYI after much experimentation, research and testing the mobile site has
>>> been lazy loading images [1] since Thursday 18th August. This means if you
>>> do not see an image you will not download it. We have taken care to ensure
>>> users without JavaScript can still view images and that most users will
>>> barely notice the difference.
>>>
>>> We are currently crunching the data this change has made and we plan to
>>> write a blog post to reporting the results.
>>>
>>> In our experiments on Japanese Wikipedia we saw a drop in image bytes
>>> per page view by 54% On the Japanese Japan article bytes shipped to users
>>> dropped from 1.443 MB to 142 kB.
>>>
>>> This is pretty huge since bytes equate to money [3] and we expect this
>>> to be significant on wikis where mobile data is more expensive. In a
>>> nutshell Wikipedia mobile is cheaper.
>>>
>>> As I said blog post to follow once we have more information, but please
>>> report any bugs you are seeing with the implementation (we have already
>>> found a few thanks to our community of editors).
>>>
>>> ~Jon
>>>
>>> [1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Performa
>>> nce/Lazy_loading_images
>>> [2] https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_
>>> of_images_on_Japanese_Wikipedia
>>> [3] https://whatdoesmysitecost.com/
>>>
>>>
>>>
>>> _______________________________________________
>>> Mobile-l mailing list
>>> Mobile-l(a)lists.wikimedia.org
>>> <javascript:_e(%7B%7D,'cvml','Mobile-l(a)lists.wikimedia.org');>
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','Mobile-l(a)lists.wikimedia.org');>
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
For those of you who follow
http://koti.kapsi.fi/~federico/crstats/extensions.txt or other
https://www.mediawiki.org/wiki/Development_statistics : I just recloned
all the MediaWiki extensions and rerun the stats, which were no longer
correct.
Given that either git pull or the ref/notes/review fails every few
months, I now also run check-sync.sh from the mediawiki/extensions.git
repo so that http://koti.kapsi.fi/~federico/crstats/git-sync.log
(hopefully) tells you whether the data is actually up to date.
I also finally set the character-encoding so that UTF-8 is recognised as
such in all its glory without browser guesses/instructions. ;-)
Nemo
Hi everyone,
For this week's office hour, let's discuss [T69223: schema change for
page content language][1] Jaime Crespo has asked that the developers
seeking this change get general consensus for the change. A
discussion at an ArchCom IRC meeting isn't strictly necessary for
this, it can't hurt, so let's do it.
My understanding of the key commit[2] is that the new "page_lang"
field was added to the "page" table and that the other schema changes
in the commits are just the ripple effects from changing the page
table.
The discussion is scheduled for 2016-08-24 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E263]3]
[ArchCom/Status][4]
Rob
[1]: <https://phabricator.wikimedia.org/T69223>
[2]: <https://gerrit.wikimedia.org/r/#/c/135312/>
[3]: <https://phabricator.wikimedia.org/E263>
[4]: <https://www.mediawiki.org/wiki/Architecture_committee/Status>
Hey,
This is the 18th weekly update from revision scoring team that we have sent
to this mailing list.
*Communications:*
- Aaron presented on how user-feedback has been helping us address some
sneaky biases in ORES' models. [1, 2, 3]
*New development:*
- We included 'autoreview' and 'patroller' groups in Turkish wiki models
to get a fitness boost. [4]
- We added some basic uwsgi metrics to grafana[5] and added a response
timing metric from Change Propagation so that we can track any performance
issues. [6]
*Maintenance and robustness:*
- We increased the number of workers per node in production for a 66%
increase in total capacity for ORES[7]
- We updated all of our edit quality models with the new version of
revscoring [8] and sent an email out to wikitech-l and ai-l about the
implications for tool developers. [9]
- We decided not to make specialized models for ORES in beta labs. [10]
Instead, we'll use the production models so that issues with them will be
caught in beta.
1. https://phabricator.wikimedia.org/T143275 -- Present on user-feedback
stories at Research Showcase
2. https://www.youtube.com/watch?v=rsFmqYxtt9w#t=29m00s -- Video of ORES
user-feedback talk
3.
https://www.mediawiki.org/wiki/File:Deploying_and_maintaining_AI_in_a_socio…
4. https://phabricator.wikimedia.org/T140474 -- Include specific user
groups in the trwiki edit quality model
5. https://phabricator.wikimedia.org/T143081 -- Add uwsgi-related metrics
to grafana
6. https://phabricator.wikimedia.org/T143568 -- Add median, 75% and 95%
response time to ORES dashboard
7. https://phabricator.wikimedia.org/T143105 -- Increase celery workers to
40 per scb node
8. https://phabricator.wikimedia.org/T143125 -- Update editquality models
with new version of revscoring
9. https://lists.wikimedia.org/pipermail/ai/2016-August/000068.html --
"[AI] New models coming to ORES & notes"
10. https://phabricator.wikimedia.org/T141980 -- Should we make a model for
ores in beta?
Sincerely,
Aaron from the Revision Scoring team
tl;dr: Starting the week of August 22nd there will be 3 SWAT deploy
windows: at 13:00, 18:00, and 23:00 UTC (6am, 11am, 4pm PDT).
Hello all,
I'm pleased to announce that after being heavily SF-focused for a long
time we're adding a Europe-focused (and slightly better for Asia/India)
SWAT window[0] starting on August 22nd[1].
This new SWAT window follows a couple changes to the SWAT process[2] and
scap tooling[3] which make SWAT deploys less risky and stressful for all
involved.
We hope this additional window will make the lives of all teams and
volunteers (at least slightly) better.
<3,
Greg and the Release Engineering Team
[0] https://wikitech.wikimedia.org/wiki/SWAT_deploys
[1] https://wikitech.wikimedia.org/wiki/Deployments#Week_of_August_22nd
[2] Utilizing mw1099/X-Wikimedia-Debug headers, see:
https://wikitech.wikimedia.org/wiki/SWAT_deploys#Doing_the_deploy
[3] Canary error rate checks built-in, see:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-August/086255.html
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
All,
I would like to draw your attention to ticket
https://phabricator.wikimedia.org/T47317.
This ticket highlights some issues with the way sections, headers and the
TOC are handled in the parser in combination with tag extensions and parser
functions.
Basically the problem is that the TOC is created before strip markers are
substituted, which prevents some sections from showing up in the TOC.
This issue is limiting the usefulness of such constructs, so I am very
interested to spend some time on it with people well-versed in the parser
code and in particular the formatHeadings function.
Of course, there are plenty more details I could give but before flooding
wikitech-l with those I thought I'd poll for the interest in addressing
this. Maybe the next step could be some chat over IRC or another medium?
Thanks in advance,
Lord_Farin