Re: [Wikitech-l] An actual bikeshed

2013-01-23 Thread Bawolff Bawolff
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 got solved. It makes my mailbox ill.

 I mean if the question is really what colour is the bikeshed it would
 be good for people to propose colours, people to vote on preferred
 colours and at the end of say a week the majority colour wins and gets
 implemented (or in cases where there is no majority we discuss the
 front runners and other possible solutions).


What colour should the polling booth be?

I don't think the answer is voting. Perhaps there are some sheds that don't
need to be painted.

-bawolff

P.s. if someone built a bikeshed in the wmf office they would be my hero
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Why are we still using captchas on WMF sites?

2013-01-22 Thread Bawolff Bawolff
On 2013-01-22 3:30 PM, aude aude.w...@gmail.com wrote:

 On Tue, Jan 22, 2013 at 8:18 PM, Luke Welling WMF lwell...@wikimedia.org
wrote:

  That was not the end of the problem I was referring to. We know our
  specific captcha is broken at turning away machines. As far as I am
aware
  we do not know how many humans are being turned away by the difficulty
of
  it.


 It's at least impossible for blind users to solve the captcha, without an
 audio captcha.  (unless they manage to find the toolserver account
creation
 thing and enough motivated to do that)

 I am not convinced of the benefits of captcha versus other spam filtering
 techniques.

 Cheers,
 Katie




Someone should write a browser addon to automatically decode and fill in
captchas for blind users. (Only half joking)

-bawolff
__**_
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 @wikimediadc / @wikidata
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Coding conventions

2013-01-22 Thread Bawolff Bawolff
On 2013-01-22 6:05 PM, Jeroen De Dauw jeroended...@gmail.com wrote:

 Hey,

 I hereby admit defeat. My thread was clearly not the ultimate bikeshed.

 Cheers

 --

On this bikeshed, allowing both styles sounds perfectly acceptable to me.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Html comments into raw wiki code: can they be wrapped into parsed html?

2013-01-22 Thread Bawolff Bawolff
On 2013-01-22 6:03 PM, Alex Brollo alex.bro...@gmail.com wrote:

 2013/1/22 Paul Selitskas p.selits...@gmail.com

  What do you mean by
   any wikicode (template call, parameter, link) present into
   the value of infobox parameter breaks the stuff, since it is parsed
and
   expanded by parser with unpredictable results.
 
  If your {{{author}}} doesn't have anything and it's aсceptable, then
make
  it {{{author|}}}, or {{#if:{{{author|}}}|span .}}. Please clarify
the
  statement above.


 Imagine that my infobox had a parameter author=, and imagine a clean
 content as this:

 author=Alessandro Manzoni

 With my template code:
 span data-author={{{author}}}/span

 I get into parsed html:
 span data-author=Alessandro Manzoni/span

 Perfect!

 But imagine that my template parameter is:
 author=[[Alessandro Manzoni]]

 When I pass the parameter content to span
 data-author={{{author}}}/span, I dont' get into html page what I'll
 like:
 span data-author=[[Alessandro Manzoni]]/span

 since wikicode [[Alessandro Manzoni]] will be interpreted by the server,
 and parsed/expanded into a html link as usual, resulting into a big mess.

 The same occurs for any wikicode and/or html passed into a infobox
template
 parameter.

 Alex brollo
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Have you tried {{#tag:nowiki|{{{author} to prevent interpretation?

There may still be issues with quotes. Im not sure.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Completed ! Re: More Update on Ashburn data center switchover / migration – target date is week of 1/22/13

2013-01-22 Thread Bawolff Bawolff
Good work to everyone involved!

-bawolff
On 2013-01-22 6:53 PM, Ct Woo ct...@wikimedia.org wrote:

 All,

 The switchover work is done.

 The site was was available to readers throughout the migration work though
 it was in read-only mode for about 32 minutes, when Asher and Mark had to
 migrate the database masters over from Tampa to Ashburn.

 We will cancel the reminding maintenance windows.

 Thank you all for your patience and understanding.

 Regards,
 CT Woo

 On Sat, Jan 19, 2013 at 10:57 AM, Ct Woo ct...@wikimedia.org wrote:

   All,
 
  We will be proceeding with the datacenter switchover plan this coming
  Tuesday (Jan 22, 2013), unless we discover some unexpected and
  insurmountable issues in our tests between now and then.
 
  During the 8-hour migration window on the 22nd, 23rd and 24th (from 17:00
  UTC to 01:00 UTC hours  / 9am to 5pm PST),  there would be times (lasting
  about 30 minutes) where the site would be set to read-only mode, to
  facilitate master database switchovers from one datacenter to another.
  While the site should be available to readers, no new contents could be
  created, edited or uploaded.
 
  We are aware of the inconvenience and we have put together plans to
  minimize such annoyances, e.g., automating much of the procedures,
  mitigating known risks,  and performing tests to identify issues prior to
  deployment. Given the scale and complexity of this migration, we do
 realize
  not all operational impact is predictable.  Some users could experience
  intermittent site unavailability and/or performance issues unfortunately.
 
  You can follow the migration on chat.freenode.net
 http://irc.freenode.net
  (and not irc.freenode.org as mentioned in previous email) in the
  #wikimedia-operations channel.
 
  Thanks,
  CT Woo
 
  -- Forwarded message --
  From: Ct Woo ct...@wikimedia.org
  Date: Fri, Jan 11, 2013 at 12:07 PM
  Subject: Update on Ashburn data center switchover / migration – target
  date is week of 1/22/13
  To: Wikimedia developers wikitech-l@lists.wikimedia.org, Development
  and Operations Engineers engineer...@lists.wikimedia.org
 
 
  All,
 
  The Migration team is in the last lap on completing the remaining tasks
 to
  ready our software stack and Ashburn infrastructure for the big
  switchover day.
 
  Per my last update,
 http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/063668.html
  with the Fundraising activity behind us now, the team has scheduled the
 *week
  of 22nd January*, 2013 to perform the switchover. We are going to block a
  8-hour migration window on the *22nd, 23rd and 24**th*.  During those
  periods, *17:00 UTC to 01:00 UTC hours (9am to 5pm PST*), there will be
  intermittent blackouts and they will be treated as 'planned' outages.
  You
  can follow the migration on irc.freenode.org in the
 #wikimedia-operations
  channel.
 
  The team is putting the finishing touches to the last few tasks and we
  will make the final Go/No decision on 18th Jan, 2013. An update will send
  out then. For those interested in tracking the progress, the meeting
 notes
  are captured on this wikitech page
 http://wikitech.wikimedia.org/view/Eqiad_Migration_Planning#Improving_Switchover
 
  .
 
  *Please note that we will be restricting code deployment during that
  week, allowing only emergency and critical ones only.*
 
  Thanks.
 
  CT Woo
 
 
 
 
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Why are we still using captchas on WMF sites?

2013-01-21 Thread Bawolff Bawolff
On 2013-01-21 3:56 AM, Andre Klapper aklap...@wikimedia.org wrote:

 On Mon, 2013-01-21 at 07:48 +, David Gerard wrote:
  On 21 January 2013 05:13, Victor Vasiliev vasi...@gmail.com wrote:
   On 01/20/2013 04:22 PM, David Gerard wrote:
 
   The MediaWiki captcha is literally worse than useless: it doesn't
keep
   spambots out, and it does keep some humans out.
 
   I don't see how the spambot statement is true. Do you have evidence
for it?
 
 
  That spambots get through at all.

 Evidence is not provided by simply repeating the statement. :)


Does http://elie.im/publication/text-based-captcha-strengths-and-weaknessescount
as evidence? (Copied and pasted from the mailing list archives)

Sure captchas do prevent some limitted attacks - it makes it more effort
then a 5 minute perl script. Most spammers are more sophisticated than that.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Why are we still using captchas on WMF sites?

2013-01-21 Thread Bawolff Bawolff
Given that there are algorithms that can solve our captcha presumably they
are mostly preventing the lazy and those that don't have enough knowledge
to use those algorithims. I would guess that text on an image without any
blurring or manipulation would be just as hard for those sorts of people to
break. (Obviously that's a rather large guess). As a compromise maybe we
should have straight text in image captchas.

-bawolff
On 2013-01-21 7:40 PM, Anthony wikim...@inbox.org wrote:

 On Mon, Jan 21, 2013 at 3:00 AM, David Gerard dger...@gmail.com wrote:
  I mean, you could redefine something that doesn't block all spambots
  but does hamper a significant proportion of humans as successful,
  but it would be a redefinition.

 It's not a definition, it's a judgment.

 And whether or not it's a correct judgment depends on how many
 spambots are blocked, and how many productive individuals are
 hampered, among other things.

 After all, reverting spam hampers people too.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Why are we still using captchas on WMF sites?

2013-01-20 Thread Bawolff Bawolff
 This question is something we've also been asking ourselves on the E3
team,
 as part of our work on account creation. I think we all agree that
CAPTCHAs
 are at best a necessary evil. They are a compromise we make in our user
 experience, in order to combat automated attacks.

That's kind of missing the point of the original poster. The point being
that they are an *un*nessary evil and do not prevent automated attacks
whatsoever.

[Snip]
 To get more numbers on how much taking away the CAPTCHA might gain us in
 terms of human registrations, we have considered a two hour test (to start
 with) of removing the CAPTCHA from the registration page:
 https://meta.wikimedia.org/wiki/Research:Account_creation_UX/CAPTCHA That
 kind of test would probably not be an accurate measurement of what kind of
 spam would be unleashed if we permanently removed it, but the hourly
volume
 of registrations on enwiki is enough to tell us the human impact.

That would be interesting. Remember that captchas arent just on the user
reg page though.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


[Wikitech-l] Caching of images in varnish

2013-01-19 Thread Bawolff Bawolff
There are reports everywhere of uploading new versions of images failing
(upload works but new version does not show up).

Last time this happened all that needed to be done was fot varnishhtcpd to
be restarted on the image cache servers. [1] could someone with the ability
to check,  check if that needs to be done again? Imho this type of issue is
a rather serious one which causes lots of frustration and confusion.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=41130

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Huggle is now in git

2013-01-18 Thread Bawolff Bawolff
English is a useless language anyhow. There's not even a compilier for it!

-bawolff
On 2013-01-18 11:49 AM, Petr Bena benap...@gmail.com wrote:

 * in case anyone is interested in *

 common mistake done by me. One day I will hopefully master english :)


 On Fri, Jan 18, 2013 at 4:48 PM, Petr Bena benap...@gmail.com wrote:

  Hi,
 
  I would like to remind even here that we have moved the source code to
  github this week.
 
  In case anyone is interesting in improving huggle or joining the project,
  you are welcome to do so: https://github.com/benapetr/huggle
 
  Please note that branch csharp is the branch containing latest version
 you
  probably want to work on. Trunk is huggle 2x.
 
  Have fun
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Google Summer of Code 2013

2013-01-17 Thread Bawolff Bawolff
One thing I would like to see is code from projects being merged into core
at a regular basis instead of just at the end. Obviously that might not be
possible for all projects depending on what your project is, but many that
modify core can be done in incremental steps. I don't know about last year
specificly but in other years there have been gsoc projects coded away
happily in branches, getting code review but not held to the same standard
as core was. When they tried to merge it the student gets a rather rude
awekening with all sorts of objections to their code they didnt expect.

Tl; dr: good in depth feedback early and often is critical for success. If
we make people merge their projects in small steps as they complete
independant features (like once every 2 weeks) gsocers get better feedback
and no giant painful merge at the end.

-bawolff
On 2013-01-17 3:47 PM, Petr Bena benap...@gmail.com wrote:

 hi,

 Can you explain the roles of mentors and admins? Also what is requirement
 for participants? I suppose it's for students?


 On Thu, Jan 17, 2013 at 8:32 PM, Quim Gil q...@wikimedia.org wrote:

  Surprised? Me too!
 
  Please read / watch / discuss
  https://www.mediawiki.org/**wiki/Summer_of_Code_2013
 https://www.mediawiki.org/wiki/Summer_of_Code_2013
 
  *Nothing* about GSOC 2013 is confirmed at this point, but there is no
 harm
  in starting collecting ideas and recruiting participants.
 
  Your feedback is welcome at the wiki page - or here if you are really
  really lazy. Reason: potential participants visiting that page in the
 near
  future will have an easier time following background discussions if they
  are take place there.
 
  Thank you!
 
  --
  Quim Gil
  Technical Contributor Coordinator @ Wikimedia Foundation
  http://www.mediawiki.org/wiki/**User:Qgil
 http://www.mediawiki.org/wiki/User:Qgil
 
  __**_
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Generating documentation from JavaScript doc comments

2013-01-16 Thread Bawolff Bawolff
 Would it be possible/difficult to get something similar working for
 gadgets on WMF wikis?

 Helder

What would be really cool would be if the js content handler code detected
code doc comments and formatted them nicely. Something similar to how back
in the old days people used to have things like
/*
==header ==
*/
That would be picked up by mw and formatted as headers. But automatic and
more complete.

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] The ultimate bikeshed: typos in commit messages

2013-01-16 Thread Bawolff Bawolff
On 2013-01-16 7:20 PM, Chad innocentkil...@gmail.com wrote:

 On Wed, Jan 16, 2013 at 6:07 PM, Tim Starling tstarl...@wikimedia.org
wrote:
  On 17/01/13 00:14, Chad wrote:
  Really, I think the whole thread is moot with the pending upgrade.
  Typos should always be fixed before merging (I think we all agree?),
  and the new abilities to fix these from the UI means we won't need
  to mark people as -1 to do so.
 
  I didn't mention commit summaries in my post. My interest is in
  nitpicking in general. Jeroen calls arguments over commit summaries
  the /ultimate/ bikeshed, which they may or may not be; there are
  plenty of other examples which may compete for that title.
 

 Indeed, I had missed that.

  Nitpicking is the minor end of the negative feedback spectrum. By
  definition, it has the smallest concrete payoff when advice is
  followed, in exchange for complex, context-dependent social costs. You
  should think carefully before you do it.
 

 *nod* I agree. And really, nitpicks in code can always be cleaned
 up later (heck, we did it for years with SVN).

 It's only nitpicks in commit messages that should always be fixed,
 since they're  immutable after submission. And it's *that* that I think
 won't be a big deal anymore (since any drive-by contributor could
 fix a typo on the spot).



If we're talking nitpicks in general. Ive seen -1 for things like
someFunc($a, $b) instead of someFunc( $a, $b ) which I agree does more harm
than good.

I imagine how much someone considers spelling issues to be a minor
nitpick varries quite a lot between people.
-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l