On Mar 7, 2014 2:12 AM, Quim Gil q...@wikimedia.org wrote:
On 03/06/2014 12:21 PM, Quim Gil wrote:
On 03/05/2014 02:00 PM, Ryan Kaldari wrote:
What do people think of the following stack:
Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif;
it would be useful to
On Mar 7, 2014 12:48 AM, Steven Walling steven.wall...@gmail.com wrote:
From: David Gerard dger...@gmail.com
Date: Thu, Mar 6, 2014 at 9:44 PM
Subject: Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
To: Wikimedia developers wikitech-l@lists.wikimedia.org
(Veering off topic: So
Le 7 mars 2014 à 07:44, C. Scott Ananian canan...@wikimedia.org a écrit :
If I had a procedures wishlist, it would be for:
a) a prominent link beside gerrit's +2 where teams could write
project-specific +2 guidelines.
b) a gerrit page banner in the 24 hours before deployment window for a
See also https://meta.wikimedia.org/wiki/Research:Content_persistence
On Thu, Mar 6, 2014 at 7:32 PM, Benjamin Lees emufarm...@gmail.com wrote:
Hi, Devander. Have you looked at WikiTrust[0]? It does roughly what you
describe (though I don't think the live demo works anymore).
[0]
Hoi,
Steven do I understand correctly that there is no user testing except in
English ?
Thanks,
GerardM
On 7 March 2014 00:47, Steven Walling steven.wall...@gmail.com wrote:
From: David Gerard dger...@gmail.com
Date: Thu, Mar 6, 2014 at 9:44 PM
Subject: Re: [Wikitech-l] Should MediaWiki
I oppose such idea or implementation, automating ranking of content sounds like
a way to get people focus on the rank/score aggressively instead of human work
on content. They already focus on 'number of GA reviews' and 'number of FAs I
contributed to', relying on style and content guides for
Hello,
My name is Orestis Ioannou and I am a first year graduate student in the
Master's program of the University Claude Bernard Lyon1 in Lyon, France.
I have a fair knowledge of PHP and MySQL acquired from various projects
in the university as well as some web development jobs I had. My latest
On Fri, Mar 7, 2014 at 5:23 AM, Isarra Yos zhoris...@gmail.com wrote:
The changeset was the result of the discussion on the Design list. The
reason Steven Walling gave for the -1 was simply not true, but attempts to
explain this failed and consensus apparently wound up being to ignore him.
On Fri, Mar 7, 2014 at 9:29 AM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:
Steven do I understand correctly that there is no user testing except in
English ?
You can only do usability testing (i.e. sit down with a person and listen
to them talk, or do it remotely) if you understand their
Hoi,
On the Wikidata roadmap it says that Commons will be targeted for inclusion
in the second half of 2014. This will have a big impact on Commons.
Consequently it will have a big impact on the things that you are
discussing. Chances are that much of what you come up with now will be
obsolete in
On Fri, 2014-03-07 at 11:50 +0100, Gerard Meijssen wrote:
On the Wikidata roadmap it says that Commons will be targeted for inclusion
in the second half of 2014. This will have a big impact on Commons.
Consequently it will have a big impact on the things that you are
discussing. Chances are
Hoi,
When Commons gets the Wikidata treatment, almost everything that has to do
with meta data will gain wikidata statements on the Wikidata item that
reflects a media file (sound photo movie no matter). When items refer to
Creators or Institutions they will refer to Wikidata proper.
This will
Hey,
This overview seems quite reasonable to me until this point:
on the other hand it [using ie dependency injection] would mean a lot of
gadgets break every
time we change things, and some possibly do even if we don't.
I am unsure how you are reaching that conclusion.
Dependency
Hi Nikita,
thanks for your interest!
On Fri, 2014-03-07 at 11:11 +0400, Nitika Verma wrote:
This is Nitika from India. I am comfortable with c/c++ , Php,
Javascript,HTML and MySql. In the projects listed on
https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_8
I am very
Well, this has blown up quite a lot. I'm going to try to summarize and
comment on the discussion so far, from the perspective of the
perpetrator ;). Since we've gone off on quite a few tangents I'll
send one e-mail for each one I see.
Regarding the patch itself [1]:
(tl;dr we all messed up,
This doesn't have to be just the language that the person conducting the
test knows. It goes even further. I remember at least one case where the
user could understand English, but couldn't speak it, so he listened to
Pau, but replied mostly in Russian, and later I translated the recording.
On a
(continued, about the browser testing)
(tl;dr where are the tests and how do I know they fail?)
So, we have some slick browser tests. Awesome! But what's not good is
that the tests run off-site, the results are not reported back to
gerrit nor Bugzilla (unless someone manually files a bug,
Hello,
First of all sorry for inappropriate way of presenting the content it
appears that there was problem with my email web interface , As advised by
community members
I once again present my ideas regarding Multilingual, usable and effective
captchas at my proposal page for GSOC-2014
(continued, about the deployment process)
I'm going to start this one with some quotes which summarize the topic
better than I would.
On Fri, 07 Mar 2014 00:30:24 +0100, Jon Robson jdlrob...@gmail.com wrote:
The code was merged at the final hour before a deployment train (this
is another issue
On Fri, 07 Mar 2014 00:34:40 +0100, Brion Vibber bvib...@wikimedia.org wrote:
For years and years and years we've been very free about reverting things
that break. No one, including old-timers like me and Tim, has the right
to not have something reverted. If it needs to be reverted it will be
Filed https://bugzilla.wikimedia.org/show_bug.cgi?id=62371 .
--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 06/03/2014 18:26, Erik Bernhardson a écrit :
I took a quick glance at the patch, it looks like the tests are being run
in the default interpreter mode with the JIT disabled. I submitted a patch
that turns on the JIT[1]. I can't promise its faster but probably worth
testing.
Erik B
On Thu, Mar 6, 2014 at 8:06 PM, Gergo Tisza gti...@wikimedia.org wrote:
Hi all,
== The state of unit tests ==
We discussed these issues, and decided that writing the tests was still a
good decision at the time, but once we are done with the major code
refactorings, we should take some time
Le 07/03/2014 02:29, Jon Robson a écrit :
2 problems here - tests run only for the extension the code touches
and currently browser tests only run after as these are slow and
people would be annoyed if code took 20 minutes to merge. We've had
issues in the past where changes in VisualEditor
Le 07/03/2014 14:56, Bartosz Dziewoński a écrit :
On Fri, 07 Mar 2014 00:34:40 +0100, Brion Vibber bvib...@wikimedia.org
wrote:
For years and years and years we've been very free about reverting things
that break. No one, including old-timers like me and Tim, has the right
to not have
This looks like a good time to fork this conversation as this is a good
problem to fix. How can we notify developers when they break other things
in the stack and how?
On 7 Mar 2014 05:36, Bartosz Dziewoński matma@gmail.com wrote:
(continued, about the browser testing)
(tl;dr where are the
Le 07/03/2014 07:55, MZMcBride a écrit :
Tim Starling wrote:
I would never have merged it, because it had a -1 from Steven Walling,
apparently speaking on behalf of others on design-l. I think changes
should be made by consensus.
The change also had five +1s, as noted in this thread. I find
Thank you for the people that has already filled data and improved the page!
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test
On 03/07/2014 12:39 AM, Martijn Hoekstra wrote:
In the mobile browsers I'm missing chrome for Android. Is that getting
reported with something else?
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso hashar+...@free.fr wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or correcting him/her
or whatever.
Note that such a rule never been followed by anyone, including
[x-posted]
Hello,
The Wikimedia Language Engineering team will be hosting the monthly IRC
office hour on March 12, 2014 (Wednesday) at 1700 UTC/ 1000 PDT on
#wikimedia-office.
In this edition, we will be talking about our ongoing projects, like the
Content Translation tool[1]. Also, we would
quote name=Bartosz Dz. date=2014-03-07 time=14:36:53 +0100
In fact, I still have no idea what exactly the tests encompass (I've
heard about some browser tests for VE because I lurk a lot, never
heard of any for core) or where to find them or how to run them.
Either I'm slow or we have a
On 7 March 2014 15:13, Chris McMahon cmcma...@wikimedia.org wrote:
This process is something that I think would be of great interest to a
variety of teams:
* When to throw away old tests
* When to create new tests (TDD style, before writing the code that
satisfies the test?)
* When to
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso hashar+...@free.fr
wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or correcting him/her
or whatever.
Note
On Fri, Mar 7, 2014 at 8:55 AM, Bartosz Dziewoński matma@gmail.comwrote:
I really do not think that blocking merges into core for 15% of the
week is going to do us any good. Core already has a problem with stale
patches not being touched (for various reasons, but most stemming from
the
Also see Michael Feathers' response to Coplien via Twitter:
http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html
/ https://twitter.com/mfeathers/statuses/441598005515669504
On Fri, Mar 7, 2014 at 9:53 AM, David Gerard dger...@gmail.com wrote:
On 7 March 2014
On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian canan...@wikimedia.orgwrote:
I agree. I think a better technical solution would be to halt jenkins'
auto-merge for the 24 hour period, so that +2'ed changes are not
automatically merged until after the branch is cut.
I don't see how that's
Hi,
Thanks last year for the assistance in correcting some programming issues with
the Memento Extension. We've been conducting performance testing in the
interim and have been addressing issues as they've been discovered. For the
most part, we've been pleased with the results, mostly due to
Let's also take this into a new thread. There are a lot of different
conversations now going on
On Fri, Mar 7, 2014 at 9:21 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian
canan...@wikimedia.orgwrote:
I agree. I think a better
On Fri, Mar 7, 2014 at 12:21 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian canan...@wikimedia.org
wrote:
I agree. I think a better technical solution would be to halt jenkins'
auto-merge for the 24 hour period, so that +2'ed
+1
If this helps to get it on the list
Am 07.03.2014 12:28 schrieb Gerard Meijssen gerard.meijs...@gmail.com:
Hoi,
When Commons gets the Wikidata treatment, almost everything that has to do
with meta data will gain wikidata statements on the Wikidata item that
reflects a media file (sound
On Fri, Mar 7, 2014 at 10:30 AM, Jon Robson jdlrob...@gmail.com wrote:
Let's also take this into a new thread. There are a lot of different
conversations now going on
On Fri, Mar 7, 2014 at 9:21 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
On Fri, Mar 7, 2014 at 12:08 PM, C.
quote name=Jon Robson date=2014-03-07 time=09:30:09 -0800
Let's also take this into a new thread. There are a lot of different
conversations now going on
My opinion is that fixing this with policy is going to be hard.
Either everyone who commits needs to be mindful of what day/time it is
On Fri, 07 Mar 2014 14:26:48 +0100, Bartosz Dziewoński matma@gmail.com
wrote:
While I still believe that the way this was done is the correct one
(seamless warning with JS; additional confirmation step without JS),
given the lack of consensus that is apparent now and wasn't apparent
I feel like I should probably post here about the current Wikibase /
Wikidata deployment pipeline too which probably differs slightly to other
products.
On a per commit basis:
A commit is made, the unit tests run on jenkins, the commit is reviewed,
amended, merged, Jenkins again runs the unit
One thing I didn't mention is that we recently marked a few of our selenium
tests as smoke tests which I just spotted was suggested in the other email
thread for core!
Great idea!
Addshore
On 7 March 2014 19:34, addshorewiki addshorew...@gmail.com wrote:
I feel like I should probably post
On 07/03/14 10:16, Steven Walling wrote:
Just for more background/context here... As you can see in the latest
comments on bug 61416, I'm not the only one who objects to the
implementation as currently designed. Prior to the bug, Erik M. also
proposed an alternative solution which was ignored
On Fri, Mar 7, 2014 at 12:37 PM, C. Scott Ananian canan...@wikimedia.orgwrote:
The benefit of halting auto-merge is that (a) it automatically resumes
once the deploy happens, so volunteers don't have to come back to gerrit to
repeat their approval,
Unless it merge-conflicts now where it
On 07/03/14 17:06, Antoine Musso wrote:
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso hashar+...@free.fr
wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or
Note, in case you didn't see, since this thread was getting extremely
complicated to follow.. I started two threads - one about
Merging near deployment branch cut time
and
Notifying people when integration tests
On Fri, Mar 7, 2014 at 10:50 AM, Isarra Yos zhoris...@gmail.com wrote:
On 07/03/14
On 03/07/2014 10:08 AM, Greg Grossmeier wrote:
What we should do, however, is have a true deployment pipeline.
Briefly defined: A deployment pipeline is a sequence of events that
increase your confidence in the quality of any particular build/commit
point.
A typical example is:
commit -
On 7 March 2014 17:15, Chris McMahon cmcma...@wikimedia.org wrote:
Also see Michael Feathers' response to Coplien via Twitter:
http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html
/ https://twitter.com/mfeathers/statuses/441598005515669504
With which I and
On 03/06/2014 10:44 PM, Tyler Romeo wrote:
On Thu, Mar 6, 2014 at 10:13 PM, George Herbert george.herb...@gmail.comwrote:
Based on the timing description here, it seems more like Either rush 1 or
rush 2.
This is also not true. Something does not have to be reverted in Gerrit in
order for it
On 03/06/2014 08:29 PM, Jon Robson wrote:
For the record this the test that alerted us to this issue was the following:
On 7 mrt. 2014, at 12:27, Gerard Meijssen gerard.meijs...@gmail.com wrote:
Hoi,
When Commons gets the Wikidata treatment, almost everything that has to do
with meta data will gain wikidata statements on the Wikidata item that
reflects a media file (sound photo movie no matter). When items
On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote:
Yes, it does. Unless the entire branch has a serious problem (500s or
major caching problems, etc.), we don't generally switch the entire branch
back.
That means the only option is fix or revert a commit. The
Somehow wikitech-l got dropped form the recipient list of this thread; I
know some of the OSM folks are subscribed. Anyway, re-added wikitech-l to
this thread.
On Fri, Mar 7, 2014 at 1:53 PM, Jon Robson jdlrob...@gmail.com wrote:
Sounds like a good idea. If there is no objections to my
Welcome to the latest edition of the Wikimedia roadmap and deployments
highlights email.
Full schedule at:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_10th
Other than the usual allotment of standing deploy windows for various
teams (eg Flow, Parsoid, Search, and WP Zero) there
quote name=Matthew Flaschen date=2014-03-07 time=16:53:18 -0500
On 03/06/2014 08:29 PM, Jon Robson wrote:
For the record this the test that alerted us to this issue was the following:
On 03/06/2014 09:58 PM, Tyler Romeo wrote:
I don't think you see the problem here. Consider this case as an example (I
agree that this is case-by-case, so let's limit the scope to this one).
You're forgetting that the original patch fixes a bug. In fact, it fixes a
pretty serious UX bug in my
On 03/06/2014 05:07 PM, Chris McMahon wrote:
Beyond that, there are serious concerns with any feature that a) requires
javascript support in the client in order to create an account on the wiki
and b) does not honor the characters that the user types in the username
and password fields.
I
On Fri, Mar 7, 2014 at 5:29 PM, Greg Grossmeier g...@wikimedia.org wrote:
Or a benefit, giving third-party users confidence that the core they use
has a quick feedback loop with real users and is thoroughly tested.
It's all about perspective.
From these conversations, your perspective seems
On Fri, Mar 7, 2014 at 1:54 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen mflasc...@wikimedia.org
wrote:
Yes, it does. Unless the entire branch has a serious problem (500s or
major caching problems, etc.), we don't generally switch the entire
On 7 March 2014 22:39, George Herbert george.herb...@gmail.com wrote:
With all due respect; hell, yes, development comes in second to operational
stability.
This is not disrespecting development, which is extremely important by any
measure. But we're running a top-10 worldwide website, a key
quote name=Tyler Romeo date=2014-03-07 time=17:34:11 -0500
Sure, but immediately deploying untested changes to all users is a reckless
method of having real users test something.
[snip]
I think some of the things mentioned here are good solution. The biggest
problem here is that this patch was
quote name=Tyler Romeo date=2014-03-07 time=16:54:27 -0500
On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen
mflasc...@wikimedia.orgwrote:
Yes, it does. Unless the entire branch has a serious problem (500s or
major caching problems, etc.), we don't generally switch the entire branch
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo tylerro...@gmail.com wrote:
Right now you are placing the responsibility on the developers to make sure
the site is stable, because any change they merge might break production
since it is automatically sent out. If anything that gives the appearance
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Mar 7, 2014 at 5:39 PM, George Herbert george.herb...@gmail.com
wrote:
With all due respect; hell, yes, development comes in second to
operational
stability.
This is not disrespecting development, which is
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Mar 7, 2014 at 5:39 PM, George Herbert george.herb...@gmail.com
wrote:
With all due respect; hell, yes, development comes in second to
operational
stability.
This is not disrespecting development, which is
On 8 mrt. 2014, at 00:47, Russell Nelson russnel...@gmail.com wrote:
Maps great, yes. Here's what *I* think Wikipedia needs. First and foremost,
OSM is a database, just like Wikipedia articles are data (don't get me
started). It's a foreign database, which means that you have the foreign
Hi all,
first of all I regret very much that I won't be able to make it to the
Zurich Hackathon, but Idaho, USA is a bit too far and I have just
switched to a new job.
Anyhow, I'd just like to chime in and support what Derk-Jan said
above. Even though the WikiMiniAtlas, a dynamic map, is my
Antoine Musso wrote:
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso hashar+...@free.fr
wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or correcting him/her
or
Minutes and slides from Wednesday's quarterly review of the
Foundation's Wikipedia Zero team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Wikipedia_Zero/March_2014
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@wikimedia.org wrote:
On 08/03/14 02:48, Bartosz Dziewoński wrote:
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso hashar+...@free.fr
wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or correcting him/her
or whatever.
Note that
73 matches
Mail list logo
