On Tue, Apr 8, 2014 at 10:05 PM, Risker risker...@gmail.com wrote:
It's pretty clear that the objectives of this project are not successfully
met at this point, and in fact have caused major problems on non-Latin
script WMF sites, and significant but less critical problems on Latin
script
On Apr 9, 2014 2:02 PM, Steven Walling steven.wall...@gmail.com wrote:
On Tue, Apr 8, 2014 at 10:05 PM, Risker risker...@gmail.com wrote:
It's pretty clear that the objectives of this project are not
successfully
met at this point, and in fact have caused major problems on non-Latin
On 9 April 2014 09:26, John Mark Vandenberg jay...@gmail.com wrote:
I havent looked at how much
testing was done, or if there was some staging of the rollout, but it is
clear that it wasnt careful enough.
To be fair, it's easy to say that in hindsight. But e.g. who knew so
many people were
Hello,
A reminder that the Language Engineering IRC office hour will be
happening later today at 1700UTC/1000PDT on #wikimedia-office. Please
see below for the original announcement, local time and other details.
Thanks
Runa
Monthly IRC Office Hour:
==
# Date: April 9, 2014
#
On Wed, Apr 9, 2014 at 5:06 PM, David Gerard dger...@gmail.com wrote:
On 9 April 2014 09:26, John Mark Vandenberg jay...@gmail.com wrote:
I havent looked at how much
testing was done, or if there was some staging of the rollout, but it is
clear that it wasnt careful enough.
To be fair,
On 9 April 2014 11:16, John Mark Vandenberg jay...@gmail.com wrote:
Did you even read my email?
Yes, I was responding to just that part.
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 09/04/14 08:26, John Mark Vandenberg wrote:
I agree with everything Risker said. I go further and suggest the team
involved stops defending their goals and implementation. The former are not
the issue, and the latter was indefensible. I havent looked at how much
testing was done, or if there
Steven Walling steven.wall...@gmail.com wrote:
It's pretty clear that the objectives of this project are not successfully
met at this point, and in fact have caused major problems on non-Latin
script WMF sites, and significant but less critical problems on Latin
script sites. Several factors
Hi,
As part of recent work on Media Viewer we've introduced new data attributes
to thumbnails (affecting only wikis where the extension is installed):
https://gerrit.wikimedia.org/r/#/c/121613/3/MultimediaViewerHooks.php,unified
These attributes currently help us display a placeholder image
In relation to our discussion about code review metrics at
http://korma.wmflabs.org/browser/gerrit_review_queue.html
I just learned that OpenStack has a policy to abandon automatically reviews
sitting in -1 during more than one week:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63533#c1
Maybe
On Apr 9, 2014 12:08 PM, Quim Gil q...@wikimedia.org wrote:
In relation to our discussion about code review metrics at
http://korma.wmflabs.org/browser/gerrit_review_queue.html
I just learned that OpenStack has a policy to abandon automatically
reviews
sitting in -1 during more than one
Yes yes yes please!
I've been manually doing this in mobile with a short friendly note saying
if the owner wants to resubmit it they can feel free to at a later date. My
gerrit is just a spam queue right now.
Just to clarify - if someone submits a patch then says 1 month later via
comment I
I have some changesets where I uploaded a reworked patchset several weeks
or even months after an original -1 was given...
Anyway a changeset can be easily renewed by rebasing it, but the side
effect is that all existing -1's get flushed. If people start to use this
method to extend the period,
Some of my changes sitting there are a few month old.
Maybe removing such changes first will reduce the -1 changes to a greater
extent and help us get a clearer idea?
On Wed, Apr 9, 2014 at 9:09 PM, Liangent liang...@gmail.com wrote:
I have some changesets where I uploaded a reworked patchset
On Wed, Apr 9, 2014 at 1:05 AM, Risker risker...@gmail.com wrote:
snip
There is a bit of amnesia about the fact that almost all editors are also
readers and regular users of the projects we create, and those editors have
been encouraged since Day One to inform developers of any technical
Quim Gil q...@wikimedia.org wrote:
In relation to our discussion about code review metrics at
http://korma.wmflabs.org/browser/gerrit_review_queue.html
I just learned that OpenStack has a policy to abandon automatically reviews
sitting in -1 during more than one week:
Le 09/04/2014 17:39, Liangent a écrit :
I have some changesets where I uploaded a reworked patchset several weeks
or even months after an original -1 was given...
Anyway a changeset can be easily renewed by rebasing it, but the side
effect is that all existing -1's get flushed. If people
Le 09/04/2014 17:08, Quim Gil a écrit :
In relation to our discussion about code review metrics at
http://korma.wmflabs.org/browser/gerrit_review_queue.html
I just learned that OpenStack has a policy to abandon automatically reviews
sitting in -1 during more than one week:
No. First of all, this would give anyone who has -1 and can
click some buttons the power to abandon changes or at least
whip a contributor into action: Fix this /now/, or else!
I don't think this would be a healthy atmosphere for devel-
opment. From my limited view of development at
From a personal perspective, the fact we have so much code to review
in the Gerrit code review queue makes it harder for __me__ to
prioritise the important patchsets and thus review them. I would
hazard a guess that such a system would help work out which patches
are important and which are just
No. I've thought the OpenStack policy is rude to contributors.
If your personal review queues are too spammy you should be more aggressive
about removing *yourself* from the change.
-Chad
-Chad
On Apr 9, 2014 8:08 AM, Quim Gil q...@wikimedia.org wrote:
In relation to our discussion about code
Interestingly, but probably completely unrelated, I note that one of the
options on your first reference [Varnish: Pageviews By Top Wikis] shows a
drop to zero in page views at around 0625 hours UTC today. Of course, the
view only gives an 8 hour snapshot, so it's not possible for an ordinary
On Wed, Apr 09, 2014 at 08:08:01AM -0700, Quim Gil wrote:
I just learned that OpenStack has a policy to abandon automatically reviews
sitting in -1 during more than one week:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63533#c1
Maybe one week is too tight for the reality of our project,
Which gulf is growing more quickly - between the WMF staff and volunteers,
or between the veteran editing population and the typical reader? I won't
argue that there is some distance, and a degree of conflict, between the
goals and priorities of the staff and many veteran volunteers. But
On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:
That said, we shouldn't be afraid of making changes where we
reasonably think they might be a good idea, even without evidence they
actually are. You can't have data on everything. I just don't like
Well we are undoubtedly making
On 9 April 2014 09:12, Jon Robson jdlrob...@gmail.com wrote:
From a personal perspective, the fact we have so much code to review
in the Gerrit code review queue makes it harder for __me__ to
prioritise the important patchsets and thus review them.
For which repos? Do those repos have a
Currently a commit is Abandoned when rejected, mostly. If we abandon
valid patches just because they're imperfect, we'll need a way to list
the abandoned patches we'd welcome work on. Therefore, I think the user
pressing the abandon button for a stale change should first be
required to file a
On 9 April 2014 07:40, Gilles Dubuc gil...@wikimedia.org wrote:
Is there a way - for the wikis hosted by the foundation where Media Viewer
is deployed - to gradually re-save or somehow invalidate all articles?
Yes. This happens automatically after 31 days, or whenever the article is
edited,
On Wed, Apr 9, 2014 at 9:33 AM, David Gerard dger...@gmail.com wrote:
On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:
That said, we shouldn't be afraid of making changes where we
reasonably think they might be a good idea, even without evidence they
actually are. You can't
Thank you for the quick and useful round of feedback.
On Wednesday, April 9, 2014, Tim Landscheidt t...@tim-landscheidt.de wrote:
forcing work on many just so that a metric
can be easier calculated by one is putting the burden on the
wrong side.
Just to be clear, I asked the question
On 9 April 2014 14:07, Steven Walling steven.wall...@gmail.com wrote:
On Wed, Apr 9, 2014 at 9:33 AM, David Gerard dger...@gmail.com wrote:
On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:
That said, we shouldn't be afraid of making changes where we
reasonably think they
On 9 April 2014 19:36, Risker risker...@gmail.com wrote:
And has any testing been done with screen readers and dyslexia readers to
test #4? I've not seen any reports of that. We do have some regular
users of screen readers who would probably have been right there letting
you know if there
Let's talk about something that's not text-related for a change.
This has already been brought up on several venues recently; Antoine suggested
I bring it up here [1], so I'm doing that.
It's pretty clear that various wiki communities would like to see larger
thumbnails [2], either by default
Proposal:
- Make the default a nice proper size for the modern Web; I suggest
360px but could be argued up.
- Remove all the other sizes from wgThumbLimits
- Remove the user preferences for thumbnail size
Simple.
J.
On 9 April 2014 12:33, Bartosz Dziewoński matma@gmail.com
On Apr 9, 2014, at 12:45 PM, James Forrester jforres...@wikimedia.org wrote:
Proposal:
- Make the default a nice proper size for the modern Web; I suggest
360px but could be argued up.
- Remove all the other sizes from wgThumbLimits
- Remove the user preferences for thumbnail size
Le 09/04/2014 18:19, Chad a écrit :
No. I've thought the OpenStack policy is rude to contributors.
If your personal review queues are too spammy you should be more aggressive
about removing *yourself* from the change.
I disagree without you that it is rude. I find them warmly welcoming new
On Wed, Apr 9, 2014 at 12:49 PM, Brandon Harris bhar...@wikimedia.orgwrote:
On Apr 9, 2014, at 12:45 PM, James Forrester jforres...@wikimedia.org
wrote:
Proposal:
- Make the default a nice proper size for the modern Web; I suggest
360px but could be argued up.
- Remove all the
On Wed, Apr 9, 2014 at 12:53 PM, Antoine Musso hashar+...@free.fr wrote:
Le 09/04/2014 18:19, Chad a écrit :
No. I've thought the OpenStack policy is rude to contributors.
If your personal review queues are too spammy you should be more
aggressive
about removing *yourself* from the
Tech Talks are back:
A preliminary look at Parsoid internals
Subramanya Sastry and Gabriel Wicke
Tuesday, April 15 at 19:00 UTC
https://plus.google.com/u/0/events/cjo2nmv8jr79k85urg6dvfrvvl0
PS: we are also starting the simplest process we could imagine for
scheduling community events, see
On 9 April 2014 12:49, Brandon Harris bhar...@wikimedia.org wrote:
On Apr 9, 2014, at 12:45 PM, James Forrester jforres...@wikimedia.org
wrote:
Proposal:
- Make the default a nice proper size for the modern Web; I suggest
360px but could be argued up.
- Remove all the other
Bartosz Dziewoński matma@gmail.com wrote:
I think we totally should do this, but with a really long expiration period
(3 months suggested by Brian seem nice).
The concerns raised by a few people here are valid, but I think they could be
offset with some simple improvements:
* Never
On 04/07/2014 10:29 PM, Sumana Harihareswara wrote:
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09
This Wednesday, I'd like to get some quick is this RfC still
valid/what's the next step? checks on a few of our older RfCs. The list
I currently suggest we look at:
On 9 April 2014 14:10, Tim Landscheidt t...@tim-landscheidt.de wrote:
If someone is overwhelmed by changes in -1 in his dash-
board(s), it sounds odd that they would want to exclude only
changes older than three months when they could exclude all
of them.
-age:3m will achieve this too,
The mobile web team has been trying to get
https://gerrit.wikimedia.org/r/#/c/116037/ merged for quite some time now.
Particularly since this is a core change, mobile web folks are hesitant to
merge it ourselves. Can someone please help us get this taken care of?
--
Arthur Richards
Software
On 04/09/2014 06:25 PM, James Forrester wrote:
On 9 April 2014 14:10, Tim Landscheidt t...@tim-landscheidt.de wrote:
If someone is overwhelmed by changes in -1 in his dash-
board(s), it sounds odd that they would want to exclude only
changes older than three months when they could exclude
Hi, today GeoData spatial searches were switched from Solr to
Elasticsearch, for now only on testwiki. We're going to test it there
for a while before proceeding to production wikis. Suggestions where
to start are welcome - while GD is populated on many projects, it is
rarely used with a few
On Apr 9, 2014 5:43 PM, James Forrester jforres...@wikimedia.org wrote:
On 9 April 2014 12:49, Brandon Harris bhar...@wikimedia.org wrote:
On Apr 9, 2014, at 12:45 PM, James Forrester jforres...@wikimedia.org
wrote:
Proposal:
- Make the default a nice proper size for the
Awesome stuff! I'm excited to see the fruits of this everywhere. Nice work
Max et al :)
On Wed, Apr 9, 2014 at 6:04 PM, Max Semenik maxsem.w...@gmail.com wrote:
Hi, today GeoData spatial searches were switched from Solr to
Elasticsearch, for now only on testwiki. We're going to test it there
On 9 April 2014 18:08, Brian Wolff bawo...@gmail.com wrote:
Of course this thread isnt supposed to be about if its a good idea to
increase the size, so far everyone is agreement on that front. The issue
is
whether doing so would kill swift due to a large increase in object count
(or some
On Apr 9, 2014 10:16 PM, James Forrester jforres...@wikimedia.org wrote:
On 9 April 2014 18:08, Brian Wolff bawo...@gmail.com wrote:
Of course this thread isnt supposed to be about if its a good idea to
increase the size, so far everyone is agreement on that front. The
issue
is
whether
n 04/04/2014 06:33 PM, Lee Worden wrote:
The MultiUpload extension has been unmaintained for a while. I believe
its author has moved on to another job. I've written a completely
independent piece of extension code (as a byproduct of work I did for
the WorkingWiki extension) that provides a
On Wednesday, April 9, 2014, Lee Worden worden@gmail.com wrote:
n 04/04/2014 06:33 PM, Lee Worden wrote:
The MultiUpload extension has been unmaintained for a while. I believe
its author has moved on to another job. I've written a completely
independent piece of extension code (as a
Hoi,
Given that you do have statistics, how did all the huha around the ULS
performance issue and now all this hit the use of the functionality for
dyslexic people?
We know that it helps but how do we help people with dyslexia? They are
only 7 to 10% of a population.. I have not done the
53 matches
Mail list logo
