We have decided to officially retire the rest.wikimedia.org domain in
favor of /api/rest_v1/ at each individual project domain. For example,
https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
becomes
https://en.wikipedia.org/api/rest_v1/?doc
Most clients already use the new path, and benefit from better
performance from geo-distributed caching, no additional DNS lookups,
and sharing of TLS / HTTP2 connections.
We intend to shut down the rest.wikimedia.org entry point around
March, so please adjust your clients to use /api/rest_v1/ soon.
Thank you for your cooperation,
Gabriel
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
BMJ, the publishers of the *British Medical Journal* and other top-tier
biomedical journals, have kindly recruited the best minds they can get to
review the en.Wikipedia's article, "Parkinson's disease".
We began the review by passing the article, in a Word document, from one
reviewer to the next by email. Each made proposed changes to the article
text and left comments in the document, using Word's "Review" and "Track
changes" features.
At that point we needed to start a discussion, and Word isn't ideal for
that. So I pasted the relevant paragraphs from the Word document into the
left column of a wiki table, and the reviewers' comments into the right
column, where the discussion could happen. [1] I manually applied
background colours to distinguish deletions from additions in the left
column, using <span style="background:#xxxxxx">.
That discussion has now begun but one of the many things I've learned
during all this is, the top researchers and theorists spend a lot of time
in the air (travelling to conferences, lectures, meetings), and it is then,
free from the demands of job and family, when they do their reviewing.
So, I have pasted that wiki table into Word and have made it available to
the reviewers here: [2]. Now they can download a copy before they get on a
flight, and email it back to me with their comments when they're online
again, and I'll transcribe their comments into the wiki table for
discussion.
This may be as simple as it gets but I just thought I'd put this before
you, in case you may have thoughts on a better technical approach for next
time. (BMJ have offered to do more of these.) I'm finding the construction
of the wiki table tedious (particularly highlighting the deletions and
additions) though I'm getting faster, and transcribing offline comments
from the Word document into the wiki table will be a small chore. The wiki
table pastes easily into Word with highlighting and formatting intact, but
not vice versa. (I've also asked at Village pump (technical).)
Any thoughts on making this easier or smarter would be much appreciated.
Anthony Cole
1. https://en.wikipedia.org/wiki/User:Anthonyhcole/sandbox
2.
https://onedrive.live.com/view.aspx?resid=C1FF29217E209194!2141&ithint=file…
Luke081515 set up #wikimedia-codereview on freenode and I'm going to try to
figure out some time slots that might work. I think we should start with
once or twice a week and expand from there.
Further input is welcome either here or on the task:
https://phabricator.wikimedia.org/T128371
On Thu, Mar 31, 2016 at 3:33 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
> Forwarding to engineering@ to get more visibility from WMF engineers who
> have +2 and/or who want to experiment with a possible way of doing
> code-review office hours.
>
> There's a vote on the task to show your interest if you have it:
> https://phabricator.wikimedia.org/T128371
>
> Greg
>
> ----- Forwarded message from Greg Grossmeier <greg(a)wikimedia.org> -----
>
> > Date: Tue, 29 Mar 2016 14:22:03 -0700
> > From: Greg Grossmeier <greg(a)wikimedia.org>
> > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> > Subject: [Wikitech-l] Code review office hours (was Re: Improving
> Wikimedia's Code Review process)
> > Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> >
> > Changing subject to focus on the code-review office hours idea.
> >
> > Also, a request at the end for people with +2 to indicate if they would
> > be willing to participate in an experiment or not :)
> >
> > <quote name="Jon Robson" date="2016-03-16" time="15:47:49 -0700">
> > > We have two swat windows every day. It's magical... I post a request
> for a
> > > deploy on a Wiki page and someone deploys it.
> >
> > :) glad you like it
> >
> > > Could we try a similar thing with code review. Code review window
> (maximum
> > > 1 patch per person) and have a group of +2ers look at a maximum set of
> > > patches?
> > >
> > > It would need a few more rules than that and a bit of tweaking but
> seems
> > > like a good experiment. I'd sign up to help it if it was a maximum 2
> > > windows for me a week.
> >
> > That sounds like an interesting idea indeed, Jon.
> >
> > An action item from me from the DevSummit was
> > https://phabricator.wikimedia.org/T128371, which is basically "setup
> > code-review office hours" without much more detail than that (it was a
> > drive-by idea during one of the sessions that I volunteered to follow-up
> > with).
> >
> > My initial idea was very minimal (basically just a time and a virtual
> > place to do code-review together) but adding in the explicit support of
> > +2ers helping merge ready patches during the time gives it more
> > effectiveness.
> >
> > The hardest part will, I assume, be getting enough people with commit
> > rights to volunteer for at least one day/week.
> >
> > Any one reading this far with +2 willing to? If so, please comment on
> > the task (to save the mailing list):
> > https://phabricator.wikimedia.org/T128371
> >
> > Thanks,
> >
> > Greg
> >
> > --
> > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> > | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
>
>
>
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> ----- End forwarded message -----
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
I recently transferred from the Reading Infrastructure team to the
Community Tech team [0]. The move happened because I want to spend
more of my time working with the developers who build tools and bots
to help the Wikimedia communities. I've been thinking about needs of
the Tool Labs developers for a while, and in November I finally wrote
up a proposal about a job focused on this work [1]. I was ready for a
lengthy discussion with management to defend my ideas about this need,
but to my surprise the feedback I got instead was mostly "it's about
time" and "when can you start?". My draft position proposal is now
"official" and posted on meta [2]. This project will be my major focus
on the Community Tech team, but I will also be helping out with code
review, deployments, and other things that the rest of the team is
working on.
People watching wikitech, labs-l, and Phabricator may have noticed
that I have been poking at various things since January like a
redesign of the wikitech main page [3], a new namespace for tool
documentation [4], and generally being more active in discussing
problems and possible solutions. Now that I am working on these issues
full time I want to start talking about bigger issues. I have drafted
a "vision" document on meta [5] describing some of the larger issues
with Tool Labs (and Labs and wikitech) that are making things harder
than they could be. This vision comes with a straw dog project roadmap
that I think we could work towards. This is not a set in stone
timeline, but rather a very high level description of a series of
projects that I believe would move Tool Labs towards being an easier
environment for collaborative FLOSS projects to thrive in. I will
continue to refine these project ideas and create Phabricator tasks to
track them, but before I dive too deeply into that I would like to
solicit input on both the problems and the general solution roadmap.
The project page is on meta rather than wikitech to make it easier for
existing Wikimedians who aren't wikitech users to participate. The
talk page is open for comments [6] and I look forward to hearing about
problems and solutions that I have not yet imagined. I hope that as
the various sub-projects solidify some of you will join me in getting
the work done.
[0]: https://wikimediafoundation.org/w/index.php?title=Template:Staff_and_contra…
[1]: https://www.mediawiki.org/wiki/User:BDavis_%28WMF%29/Projects/Tool_Labs_sup…
[2]: https://meta.wikimedia.org/wiki/Community_Tech/Tool_Labs_support
[3]: https://wikitech.wikimedia.org/wiki/Main_Page
[4]: https://wikitech.wikimedia.org/wiki/Category:Tool_Labs_tools
[5]: https://meta.wikimedia.org/wiki/Community_Tech/Tool_Labs_support/Tool_Labs_…
[6]: https://meta.wikimedia.org/wiki/Talk:Community_Tech/Tool_Labs_support/Tool_…
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
I've noticed that a lot of my fellow MediaWiki devs using OS X or Linux
don't have much experience with Windows 10's new 'Edge' browser, so I wrote
up some notes about testing with it and what to expect regarding versioning
and bug reporting:
https://www.mediawiki.org/wiki/Microsoft_Edge_browser_testing_notes
In particular, note that although versioning of the browser engine is tied
to the Windows 10 operating system, the OS is updated much more
aggressively than older versions of Windows.
The 'Windows Insider' preview release program also gives a chance to check
new engine features for bugs, or confirm that a reported bug has been fixed
correctly, before major OS updates go out. Not as good as the nightly
browser builds we get from Mozilla and Google, but it's a big improvement
from IE days. :)
-- brion
Apologies for not sending out this announcement before hand.
Short summary: The machine that Phabricator is hosted on rebooted itself
last night due to high temperatures. It ended up just shutting itself
down.
Today we needed our DataCenter Technician to reapply the thermal paste
in an attempt to remedy the issue. That took less than 10 minutes but it
happened during the middle of the day.
Full details: https://phabricator.wikimedia.org/T131742
And yes, we are requesting a backup machine so issues like this won't
have as much of an impact on you (our users):
https://phabricator.wikimedia.org/T131775
Best,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
There is clearly a need for a generic solution to hash fragment
routing in MediaWiki.
So far I've seen needs in MultimediaViewer, Kartographer,
MobileFrontend, Gather and potential needs in VisualEditor. There are
probably other bespoke solutions in other extensions too.
It would be great to take a minute and standardise on something (we
can always change it later).
I invite your discussion here:
https://phabricator.wikimedia.org/T114007
and your thoughts on my straw man proposal:
https://gerrit.wikimedia.org/r/#/c/260950/4
We are planning to enable automatic redirect following in all REST API
[1] HTML entry points on April 25th. When responding to a request for
a redirected title [2], the response headers will contain:
Status: 302
Location: <path-to-redirect-target>
For most clients, this means that their HTTP client will automatically
follow redirects, simplifying common use cases. The few clients with a
need to retrieve the redirect page content itself have two options:
1) Disable following redirects in the client. For HTML and
data-parsoid entry points, the response still includes the HTML body &
regular response headers like the ETag.
2) Send a `?redirect=false` query string parameter. This option is
recommended for browsers, which lack control over redirect behavior
for historical security reasons.
If you do have a need to avoid following redirects, you can make these
changes before the feature is enabled. Internally, we have already
done so for VisualEditor and the Mobile Content Service. See also
https://phabricator.wikimedia.org/T118548 for background & related
discussion.
Let us know if you have any concerns or questions about this.
Thanks,
Gabriel Wicke for the Wikimedia Services Team
[1]: https://en.wikipedia.org/api/rest_v1/?doc (using en.wikipedia.org
as an example)
[2]: https://www.mediawiki.org/wiki/Help:Redirects
