Le 02/12/2014 23:55, Chad a écrit :
Yes, the repo will also have a path for cloning (at a later time) and
a name (which is arbitrary and can be changed by repo owners
whenever they want).
Great, that works for me so :-]
--
Antoine hashar Musso
Hi everyone!
I'm trying to write my notification for Echo and I'm a bit stuck coding the
formatter. The standard way to write a formatter seems to override the
processParam function (like in Thanks extension). There is a lot of magic
in the code below, I can't figure out how the processParam
Hello,
i don't know, if we already had this in this discussion round, but maybe we can
learn from Googles new reCaptcha noCaptcha[1][2]
[1]
http://www.theverge.com/2014/12/3/7325925/google-is-killing-captcha-as-we-know-it
[2] https://developers.google.com/recaptcha/
Freundliche Grüße / Kind
Hi all,
it's been quite a journey since we started working on HHVM, and last
week (November 25th) HHVM was finally introduced to all users who didn't
opt-in to the beta feature.
Starting on monday, we started reinstalling all the 150 remaining
servers that were running Zend's mod_php, upgrading
Amazing work. Kudos for this staggered deployment!
On Dec 3, 2014 6:04 PM, Giuseppe Lavagetto glavage...@wikimedia.org
wrote:
Hi all,
it's been quite a journey since we started working on HHVM, and last
week (November 25th) HHVM was finally introduced to all users who didn't
opt-in to the
On Tue Dec 02 2014 at 2:23:49 PM James Forrester jforres...@wikimedia.org
wrote:
On 2 December 2014 at 13:51, Chad innocentkil...@gmail.com wrote:
So I'm thinking people are liking where we've ended up on callsigns...at
least I haven't seen any major objections in the last day or so.
Do
Following the code through, we are starting with your call to
EchoBasicFormatter::setTitleLink(). The third argument you are asking
about is labeled props, and gets passed on to
EchoBasicFormatter::buildLinkParams(). This is the function that deals
with the contents of that argument. From
On 3 December 2014 at 17:03, Giuseppe Lavagetto
glavage...@wikimedia.org wrote:
it's been quite a journey since we started working on HHVM, and last
week (November 25th) HHVM was finally introduced to all users who didn't
opt-in to the beta feature.
Excellent! Excellent! Does that make us
This is fantastic -- kudos to everyone for pushing to get this through the
finish line. Making editing faster (and improving general site
responsiveness) is one of the most obvious things we can do that serves
every single contributor to our projects. We've still got lots more that we
can do in
This is awesome! Great work everyone!
On Wed, Dec 3, 2014 at 9:03 AM, Giuseppe Lavagetto glavage...@wikimedia.org
wrote:
Hi all,
it's been quite a journey since we started working on HHVM, and last
week (November 25th) HHVM was finally introduced to all users who didn't
opt-in to the beta
I like these thoughts:
- https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079340.html
Literally an anti-captcha. Letting bots in and keeping humans out.
- https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079346.html
Why not disable the ConfirmEdit extension for a week
On Wed, 03 Dec 2014 18:56:27 +0100, Erik Bernhardson
ebernhard...@wikimedia.org wrote:
I'm not aware of any list anywhere that summarizes the possible query
parameters mediawiki accepts for wikitext pages.
There is https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php .
It
On Wed Dec 03 2014 at 1:27:33 PM svetlana svetl...@fastmail.com.au wrote:
I like these thoughts:
- https://lists.wikimedia.org/pipermail/wikitech-l/2014-
November/079340.html Literally an anti-captcha. Letting bots in and
keeping humans out.
-
The main reason our captcha is easy for bots to bypass isn't because it's
easy to read (it's not); it's because it works the same way as 90% of other
captcha's on the internet. So if you're a spam-bot writer, all you have to
do is download one of the dozens of generic captcha-breaking programs on
On Wed, Dec 3, 2014 at 8:19 PM, David Gerard dger...@gmail.com wrote:
What sort of bugs needed squashing? (Is there a list, or a suitable
Phabricator query?)
A HHVM tag exists: https://phabricator.wikimedia.org/tag/hhvm/
___
Wikitech-l mailing list
On 3 December 2014 at 23:08, Ryan Kaldari rkald...@wikimedia.org wrote:
Surely we can come up with a creative idea that is:
* Easy for humans to solve
* Can't be solved by out-of-the-box captcha breakers
* Isn't trivial for programmers to solve
* isn't an abomination for accessibility
-
- Original Message -
From: Ryan Kaldari rkald...@wikimedia.org
spambots. We just have to jump out of the existing captcha design
band-wagon. Here are some ideas:
Surely we can come up with a creative idea that is:
* Easy for humans to solve
* Can't be solved by out-of-the-box
fyi, a feedback from duala, cameroon, concerning uploading fotos to commons.
-- Forwarded message --
From: Kasper Souren kasper.sou...@gmail.com
Date: Wed, Dec 3, 2014 at 12:01 AM
Subject: Re: [African Wikimedians] Afripédia Douala
To: Mailing list for African Wikimedians
This is fantastic. Great job team and do put up a blog post about this.
--tomasz
On Wed, Dec 3, 2014 at 9:03 AM, Giuseppe Lavagetto
glavage...@wikimedia.org wrote:
Hi all,
it's been quite a journey since we started working on HHVM, and last
week (November 25th) HHVM was finally introduced to
I like how my message to try abandoning captcha entirely came up with a myriad
of complaints how we can be smart, enable new captcha which is unique, etc.
Let's measure the impact.
Could someone kindly please do some metrics on these cases after a user opened
an edit box:
- edit saved without
It's a cool idea. Also not usable by those who are visually impaired, as
best I can tell.
I'm going to be honest, I think svetlana may be on to something.
Risker/Anne
On 3 December 2014 at 18:17, Jay Ashworth j...@baylink.com wrote:
- Original Message -
From: Ryan Kaldari
Hey, I just rendered [[Barack Obama]] in about 6 seconds. I haven't tested
it for several months, but in the post-Lua era I've generally gotten around
12-15 seconds. (Prior to Lua citations, it was 30 seconds.) I don't know
is HHVM is the whole story, but that's a fabulous improvement towards
Truly fantastic news - awesome work!
On Wed, Dec 3, 2014 at 5:01 PM, Robert Rohde raro...@gmail.com wrote:
Hey, I just rendered [[Barack Obama]] in about 6 seconds. I haven't tested
it for several months, but in the post-Lua era I've generally gotten around
12-15 seconds. (Prior to Lua
On 04/12/14 10:08, Ryan Kaldari wrote:
The main reason our captcha is easy for bots to bypass isn't because it's
easy to read (it's not);
Actually, it's extremely easy to read. As I said in the commit message
on I05b5bb6, I was able to break 66% of FancyCaptcha images with the
open source OCR
Very nice.
The impact can is also reflected and easy to spot in the Cluster CPU graphs
on Ganglia:
https://ganglia.wikimedia.org/latest/?r=monthc=Application+servers+eqiad
https://ganglia.wikimedia.org/latest/?r=yearc=Application+servers+eqiad
— Krinkle
On 3 Dec 2014, at 17:03, Giuseppe
svetlana wrote:
I like how my message to try abandoning captcha entirely came up with a
myriad of complaints how we can be smart, enable new captcha which is
unique, etc.
Let's measure the impact.
We disabled the CAPTCHA entirely on test.wikipedia.org a few weeks ago.
The wiki seems to be about
Hi,
On Thu, 4 Dec 2014, at 15:02, MZMcBride wrote:
svetlana wrote:
I like how my message to try abandoning captcha entirely came up with a
myriad of complaints how we can be smart, enable new captcha which is
unique, etc.
Let's measure the impact.
We disabled the CAPTCHA entirely on
MZ: you mean removing just for account creation right? There is also a
CAPTCHA delivered on external link addition for some editors–I think IPs
and users not autoconfirmed. This is probably a lot more important for
combating spam.
(Sorry for top posting. On my phone.)
On Wed, Dec 3, 2014 at 8:03
svetlana wrote:
On Thu, 4 Dec 2014, at 15:02, MZMcBride wrote:
We disabled the CAPTCHA entirely on test.wikipedia.org a few weeks ago.
The wiki seems to be about the same. It probably makes sense to continue
slowly disabling the CAPTCHA on wikis until users start to shout.
Perhaps we'll
We have many smart people, and undoubtedly we could design a better captcha.
However, no matter how smart the mousetrap, as long as you leave it strewn
around the doors and hallways, well-meaning people are going to trip over
it.
I would support removing the captcha from generic entry points,
On 2014-12-03 8:35 PM, Robert Rohde wrote:
However, captchas might be useful if used in conjunction with simple
behavioral analysis, such as rate limiters. For example, if an IP is
creating a lot of accounts or editing at a high rate of speed, those are
bad signs.
Don't we already do rate
Hi Robert,
With accounts it is no problem, we can just make them enter a captcha when
registering and assume they're human from now on.
However where an IP contributor enters a captcha, we can't assume it's human
because IPs are often shared. There is lots of past discussion on
On Wed, Dec 3, 2014 at 8:47 PM, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
On 2014-12-03 8:35 PM, Robert Rohde wrote:
However, captchas might be useful if used in conjunction with simple
behavioral analysis, such as rate limiters. For example, if an IP is
creating a lot of accounts
Steven Walling wrote:
MZ: you mean removing just for account creation right? There is also a
CAPTCHA delivered on external link addition for some editors–I think IPs
and users not autoconfirmed. This is probably a lot more important for
combating spam.
For testwiki, we actually set
On Wed Dec 03 2014 at 8:18:53 PM MZMcBride z...@mzmcbride.com wrote:
svetlana wrote:
On Thu, 4 Dec 2014, at 15:02, MZMcBride wrote:
We disabled the CAPTCHA entirely on test.wikipedia.org a few weeks ago.
The wiki seems to be about the same. It probably makes sense to continue
slowly
On Wed Dec 03 2014 at 8:57:38 PM MZMcBride z...@mzmcbride.com wrote:
Steven Walling wrote:
MZ: you mean removing just for account creation right? There is also a
CAPTCHA delivered on external link addition for some editors–I think IPs
and users not autoconfirmed. This is probably a lot more
36 matches
Mail list logo
