Hi all!
Getting MCR support into MediaWiki is going to be one of the big challenges of
the next half year or so, and I'm really happy that quite a few people seem to
be interested in seeing it done. If you are interested in helping with the
effort, with discussion, review, coding, or organizing, please let me know.
Anyway, I have now put up a design draft for Multi-Content-Revision support
here: <https://www.mediawiki.org/wiki/Multi-Content_Revisions>. The top level
page explains the concept and rationale, and it links to several subpages
discussing different parts of the overall design. Some of these parts are
already fairly mature, while others are still just collections of notes.
This is the first time I have made a writeup of how all the parts fit together,
and I'd be really grateful for feedback. I'm particularly interested in what you
think of the proposed database schema described at
<https://www.mediawiki.org/wiki/Multi-Content_Revisions/Content_Meta-Data>. Is
it appropriate? feasible? scalable?
The content meta-data storage design is the heart of MCR. While it doesn't
necessarily have to be done first, we need commitment on this before we do any
of the other parts.
I have however tried to isolate the different components to a large degree, so
they can be implemented independently of each other, as described at
<https://www.mediawiki.org/wiki/Multi-Content_Revisions#Implementation_Roadm…>
Another part besides the content meta-data that is already quite mature and
ready for implementation is the BlobStore facility
<https://www.mediawiki.org/wiki/Multi-Content_Revisions/Blob_Storage>. But I'm
also interested in your thoughts on the design of the higher level interfaces
described in
<https://www.mediawiki.org/wiki/Multi-Content_Revisions/Revision_Retrieval> and
<https://www.mediawiki.org/wiki/Multi-Content_Revisions/Page_Update_Controll…>.
I have linked to some code experiments throughout the design document. Note that
these experiments often do not completely line up with the draft document. In
some cases, the experiment has progressed since the draft, in others, the draft
contains lessons learned from the experiment that never made it into code. The
canonical proposal is always the one on the wiki.
Please comment on the talk pages.
Thanks!
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Let's spin-off the topic about Summit participants.
On Tue, Sep 6, 2016 at 3:40 PM, Eran Rosenthal <eranroz89(a)gmail.com> wrote:
> So the capability limit can be soften a bit - this could be a simultaneous
> event in multiple different locations where the main part take in SF, but
> Wikimedia chapters may organize in the same time smaller scale events (it
> could be even 1 room +pizza ++beer).
The capacity limit for 200 is actually a more flexible number, yes. This
number is related to these expectations:
* size of the main room so everyone can fit
* catering so everyone is fed
* social events at night
* accommodation booked by the organizers
While many participants basically "live" at the Summit using all of its
services from beginning to end, others may be interested in participating
without challenging the expectations mentioned, i.e. attending only some
days / sessions, not requiring accommodations, etc. This is something that
can be discussed.
The idea of remote participation needs to be better explored, but at least
for the Summit I would start looking at the case of individual contributors
willing to participate in specific discussions. The Summit is more about
discussing that about hacking.
The idea of complementary locations organized by chapters sounds like a
better fit for the hackathons. There is the aspect of timezones too. In any
case, if a chapter wants to try, we are happy to experiment (WMDE sounds
like a good candidate for experimentation, since they send a good number of
people to the Summit but many more are "left" in Berlin).
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hey,
This is the 20th weekly update from revision scoring team that we have sent
to this mailing list.
New development:
- We implemented the basic functionality for handling bag of words and
other types of abstract feature vectors in `revscoring`. [1] This required
some changes to some dependencies as well. [2]
- We extended the user-group related features to include more of the
dominant groups outside of English Wikipedia [3] and incremented the models
that changed substantially [4]
Documentation:
- We extended the documentation at mw:Extension:ORES to make it easier
for new developers to work with us. [5]
Resourcing:
- We discussed the teams resourcing needs (hardware, engineering, and
community liaison support) with Wes Moran. [6]
Maintenance and robustness:
- We addressed a variety of issues around caching and how the ORES
extension loads new data
- ORES now returns headers that will disable secondary caching. [7]
- Our maintenance scripts will circumvent caches that do not listen to
no-cache headers. [8, 9]
- We fixed an issue where the ORES review tool would duplicate items in
Special:RecentChanges. [10]
- We standardized the extraction pattern for the enwiktionary model so
that it looks similar to other models. [11]
1. https://phabricator.wikimedia.org/T132580 -- Implement abstraction for
Sparse Feature Vectors
2. https://phabricator.wikimedia.org/T144430 -- Update yamlconf so that
import_path can handle deep attributes
3. https://phabricator.wikimedia.org/T143909 -- Extend user group features
4. https://phabricator.wikimedia.org/T144855 -- Increment ruwiki
editquality models
5. https://phabricator.wikimedia.org/T144676 -- Improve technical
documentation in Extension:ORES in mediawiki.ore
6. https://phabricator.wikimedia.org/T144517 -- ORES and Product:
resourcing discussion
7. https://phabricator.wikimedia.org/T144193 -- Set max-age header to 0
seconds for ORES to quiet secondary caches
8. https://phabricator.wikimedia.org/T144196 -- Get model version needs to
invalidate cache
9. https://phabricator.wikimedia.org/T144195 -- Check model version
replaces every time it runs.
10. https://phabricator.wikimedia.org/T144233 -- Redundant results in ORES
review tool
11. https://phabricator.wikimedia.org/T144605 -- Fix makefile entry for
enwiktionary.rev_reverted.20k_2016.tsv
Sincerely,
Aaron from the Revision Scoring team
Hello,
The Qunit Jenkins jobs have been failing most of the day due to the CI
images no more having the Apache2 plugin for PHP. That caused any web
request to the local host MediaWiki to serve the raw PHP files.
The issue is **entirely solved** since 14:00 UTC.
Task: https://phabricator.wikimedia.org/T144802
The timeline:
09:00 UTC I push a new image for Jessie. The previous one had been
stall for more than a week. Around that time the qunit jobs start failing.
<lunch break in Europe>
11:30 UTC https://phabricator.wikimedia.org/T144802 is filled.
Investigation follow (thank you Amir, Niklas, Kartik, Paladox).
12:20 UTC confirmation of the main symptom (PHP served raw)
12:35 UTC confirmed libapache2-mod-php5 is missing :(
14:00 UTC fixing puppet, rebuilding an image, testing locally, pushing
to wmflabs, testing for real => all OK.
--
Antoine Musso
We are going to finally switch off the deprecated domain rest.wikimedia.org
by September 1st. This should not affect any REST API users, as this domain
has been officially deprecated since January & sunset since April [1].
Since then, requests to that domain have returned an error informing users
about the move.
Access to the REST API is exclusively through the main project domains,
following the following pattern:
https://en.wikipedia.org/api/rest_v1/?doc
Thank you for your cooperation,
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
[1]: https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085309.html
In order to improve browser testing tools, release engineering team has
created browser testing user satisfaction survey:
https://goo.gl/xS6mmV
It should take you up to 5 minutes. Most of the questions have simple 5
level linear scale. There are 5 sections, and the last question in each
section will be free form text field, so you can leave comments on anything
we forgot to ask.
For details about the survey, feel free to take a look at phabricator task:
https://phabricator.wikimedia.org/T131123
Željko
Hi all,
What do y'all think of using this week's ArchCom review to talk about
T91162: Shadow Namespaces[1]? That's what I just put into the status
page[2], and up in the Phab event for this week[3].
This would be at the usual time (Wednesday 21 UTC, 14 PDT, 23 CEST) and
place (#wikimedia-office).
If this won't work for Legoktm especially, we'll plan on having an RFC
triage meeting instead, since we haven't had one of those in a while.
Rob
[1]: <https://phabricator.wikimedia.org/T91162>
[2]: <https://www.mediawiki.org/wiki/ArchComStatus>
[3]: <https://phabricator.wikimedia.org/E269>
