On 22/01/13 18:43, David Gerard wrote:
On 22 January 2013 17:37, vita...@yourcmc.ru wrote:
Per the previous comments in this post, anything over 1% precision
should be regarded as failure, and our Fancy Captcha was at 25% a year
ago. So yeah, approximately all, and our captcha is well known to
Luke, we do not know how many humans are being turned away by the
difficulty: actually we sort of do, that paper tells this as well. It's
where their study came from, and gives recommendations on what captcha
techniques are best for balancing efficacy with difficulty for humans.
We don't seem
(anonymous) wrote:
[...]
Really, we should be using them in the footer so gerrit can track them.
Eg:
===
Some awesome new feature
Blah blah blah
I did stuff
Fixed this too.
Bug: 1234
Change-Id: I
===
This should be Fixes-Bug: or something similar (I'll leave
it to the native
Whenever a file is linked to with a size specification, e.g.
[[File:test.png|thumb|123px]], a new thumbnail is generated in that
particular size, and saved to the disk.
This is generally a good thing, because it minimises the amount of data
the clients need to download without losing quality at
In the meantime, I tested the urlencode:...|WIKI trick, it runs perfectly
for quotes, html tags as br / and links wikicode. Now it can be used both
for tl|Autore and tl|Intestazione into it.wikisource, and I hope into
tl|MediaWiki:Proofreadpage_index_template too. But it fails with
templates;
I would advise against doing anything with the word Fix in it, because a
commit does not necessarily fix a bug. It's possible that a fix for a bug
spans multiple commits, depending on the scope of the bug. When you do just
Bug, all it implies is that you can see that bug report for related
It definitely needs a redesign or a different approach. I believe that
putting rendered view into data attributes is the worst practice ever. Data
is for data, and if you want to put rendering onto client's shoulders (that
is why you want these data attributes, right?), then you should not mix
2013/1/23 Paul Selitskas p.selits...@gmail.com
It definitely needs a redesign or a different approach. I believe that
putting rendered view into data attributes is the worst practice ever. Data
is for data, and if you want to put rendering onto client's shoulders (that
is why you want these
On 23 January 2013 13:24, Georgiy Tugai georgiy.tu...@gmail.com wrote:
However, this is also an avenue for denial of service - someone could
create many links to different images with non-standard sizes,
intentionally or unintentionally, and therefore overload computational
(temporarily) and
I don't know if we are talking at cross purposes, or if I missed it, but
this paper:
http://elie.im/publication/text-based-captcha-strengths-and-weaknesses
does not try to answer my question.
What I want to know is *How many humans get turned away from editing
Wikipedia by a difficult captcha?*
Hi, back in November Erik and Sumana explained the intention of the WMF
to get less involved in the direct organization of developer events.
Instead, the WMF will empower and help community groups taking the lead
organizing developer activities.
On 01/23/2013 12:14 PM, Quim Gil wrote:
Hi, back in November Erik and Sumana explained the intention of the WMF
to get less involved in the direct organization of developer events.
Instead, the WMF will empower and help community groups taking the lead
organizing developer activities.
I felt the last conversation stalled due to a lack of data and lots of
speculation.
It would be great if someone in the analytics team could give an idea
of the most commonly requested thumbnails and we could use this as the
basis for a new conversation.
I'd suggest that once we have such a list
Quim,
Responses inline.
- We seem to have an erratic use of Wikipedia, Wikimedia, MediaWiki,
[choose your logo] and [nothing] for naming these events. For instance, see
the web pages of San Francisco Hackathon Berlin Hackathon or Amsterdam
Hackathon and try to find the full name written down.
Tyler Romeo tylerro...@gmail.com wrote:
I would advise against doing anything with the word Fix in it, because a
commit does not necessarily fix a bug. It's possible that a fix for a bug
spans multiple commits, depending on the scope of the bug. When you do just
Bug, all it implies is that
+1 for not forcing a standard on. (Talking from the perspective of
organizing smaller events)
If we standardize on 'Hackathon', we'll have people coming in and asking us
'how to crack fb?'. If we call it 'Workshop', we'll have people coming in
asking for certificates (or wondering how much to pay
Hi,
There's been a lot of bikeshedding topics recently. On things ranging
from spaces, to typos, to naming things. I was kind of tired of these
mundane threads, so I decided to start one on something productive.
What color should the bikeshed be?
I vote blue.
-Chad
(ex)Gerrit Green.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wadler's law will always hold. :P
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Wed, Jan 23, 2013 at 1:11 PM, Chad innocentkil...@gmail.com wrote:
Hi,
There's been a lot of bikeshedding topics
On Wed, Jan 23, 2013 at 10:11 AM, Chad innocentkil...@gmail.com wrote:
Hi,
There's been a lot of bikeshedding topics recently. On things ranging
from spaces, to typos, to naming things. I was kind of tired of these
mundane threads, so I decided to start one on something productive.
What
That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix
bug 123. However, what if there's a case like I said, where a bug is fixed
across multiple commits. If you're using the Fixes tag, then technically
you should only be tagging the last commit that finally fixes the bug, in
On Wed, Jan 23, 2013 at 1:17 PM, Tyler Romeo tylerro...@gmail.com wrote:
My reasoning has to do with the motivation behind why we tag commits. Maybe
I'm wrong, but the reason we tag commits with bug numbers is so that, in
the future, if one wants to find the commit(s) that fixed a certain bug,
(It would be good to have the opinion of the
http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 organizers here)
On 01/23/2013 09:21 AM, Sumana Harihareswara wrote:
I am actually fine with inconsistency here.
I think you mean you are fine with flexibility. Me too. :)
I don't think we
On Wed, Jan 23, 2013 at 9:14 AM, Quim Gil q...@wikimedia.org wrote:
MediaWiki Hackathon City
As a team that doesn't exclusively work within MediaWiki what would you
suggest for naming if someone wanted to run a hackathon on our mobile apps?
Our mobile apps are fully decoupled from mw and only
On 01/23/2013 01:11 PM, Chad wrote:
Hi,
There's been a lot of bikeshedding topics recently. On things ranging
from spaces, to typos, to naming things. I was kind of tired of these
mundane threads, so I decided to start one on something productive.
What color should the bikeshed be?
I
Tomasz has a good point. Language tools and apps don't use Mediawiki
exclusively either.
This is one of the reasons we used Wikipedia Engineering instead of
Mediawiki for our Bangalore DevCamp naming.
-Alolita
On Wed, Jan 23, 2013 at 10:37 AM, Tomasz Finc tf...@wikimedia.org wrote:
On Wed,
Hey,
What color should the bikeshed be?
I'll forgive you for your ignorance - one really needs to start with
picking the kind of paint first
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
On Wed, Jan 23, 2013 at 11:57 PM, Quim Gil q...@wikimedia.org wrote:
Looking at e.g. the Mozilla and Ubuntu communities you can see that they
have defaults (MozCamps, Firefox OS App Days, Ubuntu Hours, UDS, LoCo
meetings... and flexibility for alternatives as well.
Another relevant example
Are we just appropriating a random bikeshed somewhere in SF for this
project?
On Wed, Jan 23, 2013 at 10:47 AM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
What color should the bikeshed be?
I'll forgive you for your ignorance - one really needs to start with
picking the kind of
It's actually a bus, not a bikeshed. It is already painted. And vim is
obviously the better editor.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If an event is specific to a piece of software then by all means let's
call it after such piece of software e.g.
Wikipedia Mobile Hackathon
(or DevCamp, if we decide that is a better default than Hackathon)
On 01/23/2013 10:46 AM, Alolita Sharma wrote:
Tomasz has a good point. Language
Blue, and bigger on the inside.
On Wed, Jan 23, 2013 at 6:57 PM, Yuvi Panda yuvipa...@gmail.com wrote:
It's actually a bus, not a bikeshed. It is already painted. And vim is
obviously the better editor.
___
Wikitech-l mailing list
Tyler Romeo tylerro...@gmail.com wrote:
That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix
bug 123. However, what if there's a case like I said, where a bug is fixed
across multiple commits. If you're using the Fixes tag, then technically
you should only be tagging the
I mean does it have to be a bike shed or can I put my boat in it?
On a more serious note, I think all this bikeshedding reveals a big
problem we have.
It is very hard to reach consensus on many topics and it seems one
person saying no has more weight than 10 people say yes.
Bikeshedding
IMHO the primary motivation for using Fixes: 123 (or
Relates-To: 123) is to absolve the committer from te-
diously going back to the Bugzilla page and adding a Gerrit
link and (in the former case) the merger from marking the
bug as resolved as computers are so *much* better at that
(and
On 2013-01-23 3:38 PM, Jon Robson jdlrob...@gmail.com wrote:
Suggested solution:
Maybe some kind of voting system might be of use to force some kind of
consensus rather than leaving problems unsolved. I'm fed up of
receiving emails about the same problem I discussed weeks before that
never
Tyler Romeo tylerro...@gmail.com wrote:
IMHO the primary motivation for using Fixes: 123 (or
Relates-To: 123) is to absolve the committer from te-
diously going back to the Bugzilla page and adding a Gerrit
link and (in the former case) the merger from marking the
bug as resolved as
I'd strongly suggest considering this kind of approach.
--
View this message in context:
http://wikimedia.7.n6.nabble.com/Limiting-storage-generation-of-thumbnails-without-loss-of-functionality-tp4994447p4994493.html
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
This proposal got a basic agreement and is being implemented at
https://www.mediawiki.org/wiki/QA/Weekly_goals
A rough start is expected in the first iteration of the four areas but
we hope to have improvements every week.
Get involved!
Development teams: your proposals for testing bug
On Wed, Jan 23, 2013 at 01:53:39PM -0800, Aaron Schulz wrote:
I'd strongly suggest considering this kind of approach.
Ditto. Among other benefits already mentioned, having a predetermined
set of sizes would help greatly in the architecture and capacity
planning of media storage, as well as in
On 01/16/2013 09:48 AM, Quim Gil wrote:
Hi, next week I will have a casual chat with Siko about the new
Wikimedia Individual Engagement Grants and how MediaWiki contributors
could theoretically benefit from them.
I just had that chat. Very interesting!
Individual Engagement Grants also apply
Highlighted updates from today's roadmap meeting:
- Gabriel Wicke will be announcing a RFC + Roadmap for future Parsoid
plans on Wikitech-l shortly
http://www.mediawiki.org/wiki/Parsoid/RFC:_Longer-term_plan
- EQIAD migration completed. You can see the steps taken here:
On 01/23/2013 12:56 PM, Bawolff Bawolff wrote:
On 2013-01-23 3:38 PM, Jon Robson jdlrob...@gmail.com wrote:
Suggested solution:
Maybe some kind of voting system might be of use to force some kind of
consensus rather than leaving problems unsolved. I'm fed up of
receiving emails about the same
On Wed, Jan 23, 2013 at 3:13 PM, Quim Gil q...@wikimedia.org wrote:
[snip]
But there is another point here, which is how narrowed / inclusive are we
with the MediaWiki word. You can see it as the name of a CMS. You can see
it as a name of a wider community. Looking at the content at
Fellow MediaWiki hackers!
After the pretty successful December release and some more clean-up work
following up on that we are now considering the next steps for Parsoid.
To this end, we have put together a rough roadmap for the Parsoid project at
https://www.mediawiki.org/wiki/Parsoid/Roadmap
On 01/23/2013 03:07 PM, bawolff wrote:
To be honest making naming requirements sounds like a bikeshed
discussion.
I'm sorry it has been perceived by some as such. I started the
discussion after the real need this morning of suggesting a name to a
local promoter willing to organize an event.
As the linked thread mentioned, MediaWiki is used on many deployments
outside of Wikimedia.
For example, I'm running three instances on a server with 10 GB of disk
space.
Therefore, this should be an option in LocalSettings.php rather than a
global change; that way, the installations which are
On 01/23/2013 10:07 PM, Georgiy Tugai wrote:
As the linked thread mentioned, MediaWiki is used on many deployments
outside of Wikimedia.
For example, I'm running three instances on a server with 10 GB of disk
space.
Therefore, this should be an option in LocalSettings.php rather than a
Greetings,
Wikimania is six months away - and in terms of planning - that means it is
right around the corner.
As such, folks involved with programme and Hackathon organizing are very
interested in any ideas that WM developers may have for this year's Hackathon.
Please contribute them on-wiki
On 23/01/13 20:38, Jon Robson wrote:
Suggested solution:
Maybe some kind of voting system might be of use to force some kind of
consensus rather than leaving problems unsolved. I'm fed up of
receiving emails about the same problem I discussed weeks before that
never got solved. It makes my
50 matches
Mail list logo
