On Mar 7, 2014 2:12 AM, "Quim Gil" 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" wrote:
>
> From: David Gerard
> Date: Thu, Mar 6, 2014 at 9:44 PM
> Subject: Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
> To: Wikimedia developers
>
> (Veering off topic: So what does WMF use for a usability lab, anyway?)
>
>
> ...not s
Le 7 mars 2014 à 07:44, C. Scott Ananian 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
> given project
See also https://meta.wikimedia.org/wiki/Research:Content_persistence
On Thu, Mar 6, 2014 at 7:32 PM, Benjamin Lees 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] https://en.wikipedia.org/wi
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 wrote:
> From: David Gerard
> Date: Thu, Mar 6, 2014 at 9:44 PM
> Subject: Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
> To: Wikim
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 th
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 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.
>
> Just for a littl
On Fri, Mar 7, 2014 at 9:29 AM, Gerard Meijssen
wrote:
> 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 language.
Otherwise yo
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 wil
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 Injecti
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 i
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, le
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 m
(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, usuall
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 give
(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 wrote:
The code was merged at the final hour before a deployment train (this
is another issue that our deployment
On Fri, 07 Mar 2014 00:34:40 +0100, Brion Vibber 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
reverted -- there is
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 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 to refactor t
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
> 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 revert
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" wrote:
> (continued, about the browser testing)
>
> (tl;dr where are the tests and how
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 thre
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 els
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso 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 by various WMF
te
[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 lik
> 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 serious documentation failure here.
>
> Can something be don
On 7 March 2014 15:13, Chris McMahon 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 refactor existing test
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
> On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso
> 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
On Fri, Mar 7, 2014 at 8:55 AM, Bartosz Dziewoński wrote:
> 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 lack of reviewers)
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 wrote:
> On 7 March 2014 15:13, Chris McM
On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian 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 changes are not
> automatically merged until after the branch is cut.
I don't see how that's any better. Things st
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)
wrote:
> On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian
> wrote:
>
>> I agree. I think a better technical solution would be to halt jenkins
On Fri, Mar 7, 2014 at 12:21 PM, Brad Jorsch (Anomie) wrote:
> On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian >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 changes are not
> > automatically merged unt
+1
If this helps to get it on the list
Am 07.03.2014 12:28 schrieb "Gerard Meijssen" :
> 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
On Fri, Mar 7, 2014 at 10:30 AM, Jon Robson 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)
> wrote:
>> On Fri, Mar 7, 2014 at 12:08 PM, C. Scott Ananian
>> wrote:
>>
>>> I agr
> 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
and whether or not another human has cut the new branch
On Fri, 07 Mar 2014 14:26:48 +0100, Bartosz Dziewoński
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
earlier (Steven was the on
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 test
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 wrote:
> I feel like I should probably post here about the current W
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 for
On Fri, Mar 7, 2014 at 12:37 PM, C. Scott Ananian wrote:
> 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 didn't 24 hours ago.
>
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
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 w
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 wrote:
> On 07/03/14 17:06, Antoine
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:
> com
On 7 March 2014 17:15, Chris McMahon 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 the author of the PDF
On 03/06/2014 10:44 PM, Tyler Romeo wrote:
On Thu, Mar 6, 2014 at 10:13 PM, George Herbert wrote:
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 to be undeployed from
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:
https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/392/testReport/junit/(root)/Create%20failure%20messages/Create_account_password_mis
On 7 mrt. 2014, at 12:27, Gerard Meijssen 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 refer to
> "Creators"
On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen 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 branch
> back.
>
> That means the only option is fix or revert a commit. The general rule is
> to
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 wrote:
> Sounds like a good idea. If there is no objections to my potentially crazy
> idea I
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 a
> 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:
> >https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/392/testReport/junit/(root)/Create%20failure%20messages/Create_account_passw
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 opi
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 agree
On Fri, Mar 7, 2014 at 5:29 PM, Greg Grossmeier 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 to be (and p
On Fri, Mar 7, 2014 at 1:54 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen >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
> branch
> > back.
> >
> > That means
On 7 March 2014 22:39, George Herbert 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 worldwide
> informat
On Fri, Mar 7, 2014 at 5:39 PM, George Herbert 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 worldwide
> 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 launched almost completely untested. It
> should have
> On Fri, Mar 7, 2014 at 4:49 PM, Matthew Flaschen
> 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 branch
> > back.
> >
> > That means the only option is fix or revert a commit. The gen
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo 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
> that the opera
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 5:39 PM, George Herbert >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
> >
On Fri, Mar 7, 2014 at 2:54 PM, Tyler Romeo wrote:
> On Fri, Mar 7, 2014 at 5:39 PM, George Herbert >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
> >
On 8 mrt. 2014, at 00:47, Russell Nelson 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 key
> problem. Wiki
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 project
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
>> 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 wh
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 wrote:
> Hi folks,
>
> to i
On 08/03/14 02:48, Bartosz Dziewoński wrote:
> On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso
> 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 rul
74 matches
Mail list logo
