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
What's the best way to build OOjs UI locally into the MW lib directory
while developing?
I'm having two issues:
1. The README.md says:
"Install dev dependencies and build the distribution files:<br/>`$ npm
install`"
This does not actually build to dist for me.
I then tried:
npm run-script publish-build
That partly works but has many errors:
https://phabricator.wikimedia.org/P2903
However, it apparently creates the key files.
2. I see update-oojs-ui.sh, but it looks like it's only intended for
when the OOjs UI change is already published.
I had to hack it up with:
npm install '/home/matthew/Code/Wikimedia/oojs/oojs-ui/'
which seems to basically work.
If there is not yet a proper way to do this, I'll probably add this as
an option.
This should be documented, probably at
https://www.mediawiki.org/wiki/Using_OOjs_UI_in_MediaWiki .
Matt
This week, JavaScript module interfaces in ResourceLoader
<https://phabricator.wikimedia.org/T108655> were merged, the ServiceLocator
implementation continued, and there was a lively discussion of options for
balancing templates on IRC. Shadow namespaces
<https://phabricator.wikimedia.org/T91162> are scheduled for discussion at
next week's IRC meeting.
Gabriel
RFC inbox
-
T30085: RFC: Allow user login with email address in addition to username
<https://phabricator.wikimedia.org/T30085>: Last update October. Issue
is email addresses associated with multiple accounts. Possibly related to
AuthManager work.
-
T128352: RfC: Need to merge Notifications and Watchlist or lack thereof
<https://phabricator.wikimedia.org/T128352>: Very much a product
question.
-
T130528: RFC: PSR-6 Cache interface in Mediawiki core
<https://phabricator.wikimedia.org/T130528>: Addshore and Anomie have
been working on this recently.
Approved RFCs
T108655 Standardise access to JavaScript interfaces
<https://phabricator.wikimedia.org/T108655> (Roan): Previously approved.
Implementation landed in master this week.
This week's IRC meeting
T130567 RFC: Hygienic transclusions for WYSIWYG, incremental parsing &
composition <https://phabricator.wikimedia.org/T130567>,
T114444 DOM scopes <https://phabricator.wikimedia.org/T114444>, and
T114445 Balanced
templates <https://phabricator.wikimedia.org/T114445>: (Tim) The discussion
exposed two main questions: 1) How to best resolve content model conflicts,
and 2) whether to (eventually) default to balanced templates or not. The
implementation in T114445 <https://phabricator.wikimedia.org/T114445>
proposes a solution to mark specific templates for balancing, and explores
two options for conflict resolution. The discussion will continue on the
tasks.
Next week’s IRC meeting
T91162 Shadow namespaces <https://phabricator.wikimedia.org/T91162>
(brion): A proposed mechanism for sharing content like templates or modules
cross-wiki, similar to how InstantCommons and foreign file repos work.
Kunal is getting ready to work on this.
Under discussion
T124792 RFC: Service Locator for MediaWiki core
<https://phabricator.wikimedia.org/T124792> (Daniel): Discussed in IRC
Office hour last week (see task for notes). Discussed at Wikimedia
Hackathon 2016 in Israel <https://etherpad.wikimedia.org/p/wmhack2016_DI>.
Implementation under way.
T91162 RFC: Shadow namespaces <https://phabricator.wikimedia.org/T91162>
(brion): Scheduled for IRC meeting next week.
T123753 Establish retrospective reports for Security and Performance
incidents <https://phabricator.wikimedia.org/T123753> (RobLa): Briefly
discussed at last week's IRC meeting, some activity on the task.
T119908 RFC: Migrate code review / management to Phabricator from Gerrit
<https://phabricator.wikimedia.org/T119908> (RobLa): ArchCom is looking for
more detail on CI integration, as well as background on alternatives
considered for code review + CI. On hold.
T39902 RFC: Implement rendering of redlinks as post-processor
<https://phabricator.wikimedia.org/T39902> (Gabriel): Solutions for
highlighting links to non-existing pages in Parsoid HTML. Main question is
preprocessing vs. separate metadata processed on client. Experiment shows
that specific link matching / replacement can be done in <2ms for large
documents on the server.
T130663 RFC: Reference API requirements and options
<https://phabricator.wikimedia.org/T130663> (Timo): We need to better
define the scope of this RFC and come up with a solid proposal. Open to
input on whether or not this should be blocked on larger product goals
relating to centralised citations. Join WikiCite 2016 in Germany!
https://meta.wikimedia.org/wiki/WikiCite_2016
T18691 RFC: Section headings should have a clickable anchor
<https://phabricator.wikimedia.org/T18691> (Timo): Working on better
understanding of the problem space and possible solutions. Volker gathered
various considerations and challenges. Under discussion in Front-end
standards group.
T16950: Support global preferences
<https://phabricator.wikimedia.org/T16950> (no shepherd): No clear owner
yet.
T130528 RFC: PSR-6 Cache interface in Mediawiki core
<https://phabricator.wikimedia.org/T130528> (no shepherd).
T122942 RFC: Support language variants in the REST API
<https://phabricator.wikimedia.org/T122942> (Gabriel): Discussing options
with Reading.
No activity in the last two weeks:
T124504 Transition WikiDev '16 working areas into working groups
<https://phabricator.wikimedia.org/T124504> (RobLa)
T66214 Use content hash based image / thumb URLs & define an official thumb
API <https://phabricator.wikimedia.org/T66214> (Brion)
T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
<https://phabricator.wikimedia.org/T113034> (Daniel)
T128351 RFC: Notifications in core
<https://phabricator.wikimedia.org/T128351> (Brion)
T122825 Service ownership and minimum maintenance requirements
<https://phabricator.wikimedia.org/T122825> (Gabriel)
T54807: Identify and remove legacy preferences from MediaWiki core
<https://phabricator.wikimedia.org/T54807> (no shepherd)
T88596 Improving extension management
<https://phabricator.wikimedia.org/T88596> (Daniel)
T114444 RFC: Introduce notion of DOM scopes in wikitext
<https://phabricator.wikimedia.org/T114444> (Tim)
T120164 RFC: Institute "last call" period for MediaWiki RfCs
<https://phabricator.wikimedia.org/T120164> (WIP)
T118517 RFC: Use <figure> for media
<https://phabricator.wikimedia.org/T118517> (Brion)