Re: [Wikitech-l] What namespaces should we use when we use them

2014-06-25 Thread Antoine Musso 
Le 24/06/2014 23:30, Bryan Davis a écrit :
> I suggested MediaWiki\Extensions\OAuth because it seems like the most
> natural naming to me. PSR-4 [2] is very opinionated about namespaces.
> It requires a top-level (or vendor) namespace. I chose "MediaWiki"
> because ... MediaWiki. Beyond that sub-namespaces are optional, but
> the file system path from the base directory to the php file must
> match. Assuming that $IP is the base directory led me to suggest
> MediaWiki\Extensions\OAuth.

Hello,

Looks good to me =)

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] Browser tests for core

2014-06-25 Thread Antoine Musso 
Le 25/06/2014 00:46, Chris Steipp a écrit :
> I just +2'ed a change to add a few basic selenium tests to core [1]. I
> think it will benefit us all to have a set of automated tests to
> quickly make sure mediawiki is working correctly. From a security
> perspective, this also takes a step towards more efficient security
> testing, which I'm also a fan of (if you've tried blindly scanning
> mediawiki, you know what I'm talking about..).


The next big step would be to trigger them whenever someone propose a
patchset in Gerrit or vote +2.  We have some scripts to setup a
MediaWiki locally and run the browser tests, but that proven to be a bit
unstable :-/

I am wondering how developer would feel with having browser tests
reported back to Gerrit.  Possibly has a different check so we dont have
to wait for them to complete before reporting all the other tests.



> I'd like to see more tests added and backported to REL1_23 to make
> sure we have an ongoing suite to check releases against for next few
> years that we support that LTS. If anyone is interested in both
> mediawiki core and browser tests, I'm sure the QA team would like to
> get you involved.

That is a nice idea.  We could then trigger them before releasing a new
tarball which will add some confidence.  There is a bit of script needed
there but that is definitely doable.

> Big thanks to hashar, Chris McMahon, and Dan Duvall for indulging me
> and getting this done. I'll let them jump in with all the details I've
> missed.

Oh I have done nothing beside requesting someone to write the
announcement :-]

-- 
Antoine "hashar" Musso


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

[Wikitech-l] bugzilla: keyword for every language

2014-06-25 Thread Petr Bena 
Can we have that? so that people can filter out bugs that are require
skills for certain languages only?

For example if I needed to fix something that is C++ I would just tag
it so, same for PHP, JS, etc... So that C++ devs could filter out only
all bugs that require C++ knowledge and see all bugs across all of
wikimedia that can be fixed in that language.

Developers could then simply filter out only bugs that they are
interested in or able to fix.

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

Re: [Wikitech-l] bugzilla: keyword for every language

2014-06-25 Thread Andre Klapper 
On Wed, 2014-06-25 at 10:44 +0200, Petr Bena wrote:
> Can we have that? so that people can filter out bugs that are require
> skills for certain languages only?
> For example if I needed to fix something that is C++ I would just tag
> it so, same for PHP, JS, etc... So that C++ devs could filter out only
> all bugs that require C++ knowledge and see all bugs across all of
> wikimedia that can be fixed in that language.
> 
> Developers could then simply filter out only bugs that they are
> interested in or able to fix.

Well, before developers can simply filter out bugs, somebody would have
to go through ~14000 open tickets, understand which language(s) a bug
report is about, and set the language(s) on all of these tickets.
Would you like to volunteer? :)

More seriously, doesn't the Bugzilla product or component that a bug
report belongs to already pretty much define the programming language(s)
in that area? That's the level where I'd expect such information to be
located. (Or in a  tag of a project's DOAP file in
its code repository.)

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

Re: [Wikitech-l] bugzilla: keyword for every language

2014-06-25 Thread Petr Bena 
No, they wouldn't need to do this, it would more like optional feature
for new bugs and only for these which are created by person who need
assistance from someone who understand the language. For example if I
needed something in JS, I could just flag it so that pool of
programmers we have on wikimedia project would know someone need their
help and did it.

For example I can resolve probably any C/C++/C#/VB bug we have on
bugzilla. But I will not do that because I have no idea which bugs are
these.

If there was such a keyword, PHP programmer who need help from some
HTML5 programmer, could create a bug for some feature and set HTML5
keyword so that HTML5 people are aware of that bug, it would same as
"ops" keyword now. It exist just to inform ops that there is a bug
which they can resolve. Now we would have it for other "teams" as
well.

On Wed, Jun 25, 2014 at 12:52 PM, Andre Klapper  wrote:
> On Wed, 2014-06-25 at 10:44 +0200, Petr Bena wrote:
>> Can we have that? so that people can filter out bugs that are require
>> skills for certain languages only?
>> For example if I needed to fix something that is C++ I would just tag
>> it so, same for PHP, JS, etc... So that C++ devs could filter out only
>> all bugs that require C++ knowledge and see all bugs across all of
>> wikimedia that can be fixed in that language.
>>
>> Developers could then simply filter out only bugs that they are
>> interested in or able to fix.
>
> Well, before developers can simply filter out bugs, somebody would have
> to go through ~14000 open tickets, understand which language(s) a bug
> report is about, and set the language(s) on all of these tickets.
> Would you like to volunteer? :)
>
> More seriously, doesn't the Bugzilla product or component that a bug
> report belongs to already pretty much define the programming language(s)
> in that area? That's the level where I'd expect such information to be
> located. (Or in a  tag of a project's DOAP file in
> its code repository.)
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> 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] bugzilla: keyword for every language

2014-06-25 Thread Petr Bena 
Regarding your second point. This is sci-fi in case of small projects,
it maybe works for large ones, but for example when I create a bug for
huggle or wm-bot where PHP, python, or JS guy is needed, nobody ever
notice that. BTW mozilla is already doing this and it seems to be
pretty effective, I think wikimedia could get inspired a bit (this
idea is actually not from my head) :P

On Wed, Jun 25, 2014 at 1:48 PM, Petr Bena  wrote:
> No, they wouldn't need to do this, it would more like optional feature
> for new bugs and only for these which are created by person who need
> assistance from someone who understand the language. For example if I
> needed something in JS, I could just flag it so that pool of
> programmers we have on wikimedia project would know someone need their
> help and did it.
>
> For example I can resolve probably any C/C++/C#/VB bug we have on
> bugzilla. But I will not do that because I have no idea which bugs are
> these.
>
> If there was such a keyword, PHP programmer who need help from some
> HTML5 programmer, could create a bug for some feature and set HTML5
> keyword so that HTML5 people are aware of that bug, it would same as
> "ops" keyword now. It exist just to inform ops that there is a bug
> which they can resolve. Now we would have it for other "teams" as
> well.
>
> On Wed, Jun 25, 2014 at 12:52 PM, Andre Klapper  
> wrote:
>> On Wed, 2014-06-25 at 10:44 +0200, Petr Bena wrote:
>>> Can we have that? so that people can filter out bugs that are require
>>> skills for certain languages only?
>>> For example if I needed to fix something that is C++ I would just tag
>>> it so, same for PHP, JS, etc... So that C++ devs could filter out only
>>> all bugs that require C++ knowledge and see all bugs across all of
>>> wikimedia that can be fixed in that language.
>>>
>>> Developers could then simply filter out only bugs that they are
>>> interested in or able to fix.
>>
>> Well, before developers can simply filter out bugs, somebody would have
>> to go through ~14000 open tickets, understand which language(s) a bug
>> report is about, and set the language(s) on all of these tickets.
>> Would you like to volunteer? :)
>>
>> More seriously, doesn't the Bugzilla product or component that a bug
>> report belongs to already pretty much define the programming language(s)
>> in that area? That's the level where I'd expect such information to be
>> located. (Or in a  tag of a project's DOAP file in
>> its code repository.)
>>
>> andre
>> --
>> Andre Klapper | Wikimedia Bugwrangler
>> http://blogs.gnome.org/aklapper/
>>
>>
>> ___
>> 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] What namespaces should we use when we use them

2014-06-25 Thread Tyler Romeo 
I don’t think there’s any need to impose a naming requirement for extension
namespaces. Some vendors may choose to use their own namespace scheme.

In the end, as long as the namespace chosen is PSR-4 compliant, it should not
matter.
-- 
Tyler Romeo
0xC86B42DF

From: Antoine Musso 
Reply: Wikimedia developers >
Date: June 25, 2014 at 4:16:38
To: wikitech-l@lists.wikimedia.org >
Subject:  Re: [Wikitech-l] What namespaces should we use when we use them  

Le 24/06/2014 23:30, Bryan Davis a écrit :
> I suggested MediaWiki\Extensions\OAuth because it seems like the most
> natural naming to me. PSR-4 [2] is very opinionated about namespaces.
> It requires a top-level (or vendor) namespace. I chose "MediaWiki"
> because ... MediaWiki. Beyond that sub-namespaces are optional, but
> the file system path from the base directory to the php file must
> match. Assuming that $IP is the base directory led me to suggest
> MediaWiki\Extensions\OAuth.

Hello,

Looks good to me =)

--  
Antoine "hashar" Musso


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

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] bugzilla: keyword for every language

2014-06-25 Thread Andre Klapper 
On Wed, 2014-06-25 at 13:51 +0200, Petr Bena wrote:
> it maybe works for large ones, but for example when I create a bug for
> huggle or wm-bot where PHP, python, or JS guy is needed, nobody ever
> notice that. BTW mozilla is already doing this and it seems to be
> pretty effective

What do you refer to? http://www.joshmatthews.net/bugsahoy/ where you
can query Mozilla Bugzilla tickets by programming language?
Or the "[lang=php]" tags in the Status Whiteboard of Mozilla Bugzilla?
If the latter, anybody can edit the whiteboard of tickets in Wikimedia
Bugzilla, so you can just do it. :)

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

[Wikitech-l] [GSoC] Font Tailor for Chinese Wikis - Midterm Report

2014-06-25 Thread Aaron Xiao 
Hi all,
I have finished a FontTailor demo and write it in Midterm Report [1].
It still has some issues to settle [2], but proves the idea can work.

Please take a look at the report, especially the issues. Any feedback is more 
than welcomed!

Regards,

[1] 
https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector/Fonts_for_Chinese_wikis/Midterm_Report
[2] 
https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector/Fonts_for_Chinese_wikis#Know_Issues
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] bugzilla: keyword for every language

2014-06-25 Thread Petr Bena 
ok that seems to be good enough for me. What is actually difference
between these keywords and white-board if it can serve the same
purpose?

On Wed, Jun 25, 2014 at 3:04 PM, Andre Klapper  wrote:
> On Wed, 2014-06-25 at 13:51 +0200, Petr Bena wrote:
>> it maybe works for large ones, but for example when I create a bug for
>> huggle or wm-bot where PHP, python, or JS guy is needed, nobody ever
>> notice that. BTW mozilla is already doing this and it seems to be
>> pretty effective
>
> What do you refer to? http://www.joshmatthews.net/bugsahoy/ where you
> can query Mozilla Bugzilla tickets by programming language?
> Or the "[lang=php]" tags in the Status Whiteboard of Mozilla Bugzilla?
> If the latter, anybody can edit the whiteboard of tickets in Wikimedia
> Bugzilla, so you can just do it. :)
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> 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] MediaWiki Front-End Standardization Chat

2014-06-25 Thread Erik Moeller 
As a reminder, this is in 65 minutes.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Including NS_MAIN in $wgNamespacesWithSubpages by default

2014-06-25 Thread Brian Wolff 
On 6/25/14, MZMcBride  wrote:
> MZMcBride wrote:
>>Current default:
>>---
>>$wgNamespacesWithSubpages = array(
>>NS_TALK => true,
>>NS_USER => true,
>>NS_USER_TALK => true,
>>NS_PROJECT => true,
>>NS_PROJECT_TALK => true,
>>NS_FILE_TALK => true,
>>NS_MEDIAWIKI => true,
>>NS_MEDIAWIKI_TALK => true,
>>NS_TEMPLATE_TALK => true,
>>NS_HELP => true,
>>NS_HELP_TALK => true,
>>NS_CATEGORY_TALK => true
>>);
>>---
>>
>>Proposed array addition:
>>---
>>NS_MAIN => true,
>>---
>
> The more I look at this, the more I wonder why not instead invert the
> array:
>
> ---
> $wgNamespacesWithoutSubpages = array(
> NS_FILE => true,
> NS_CATEGORY => true
> );
> ---
>
> I don't know why NS_TEMPLATE isn't true by default... isn't using
> "Template:Foo/doc" for "Template:Foo"'s documentation a common pattern?
>
> Though my real goal is saner default behavior for NS_MAIN and inverting
> the array would be a larger change than a simple one-liner. Hmmm.
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Including NS_TEMPLATE sounds sane. Every so often someone on
#mediawiki asks why {{/doc}} includes template:/doc on their wiki
instead of template:{{PAGENAME}}/doc like it does on 'pedia.


Making the array inverted does sound like it would make more sense in
many ways, but a bigger change. Maybe instead we could have
$wgNamespacesHaveSubpagesByDefault to specify what default subpage
behaviour is, and then $wgNamespacesWithSubpages[NS_FOO] = true; turns
on subpages if they are off by default, and
$wgNamespacesWithSubpages[NS_FOO] = false; turns them off if they are
on by default (And no entry falls back to
$wgNamespacesHaveSubpagesByDefault). It seems sort of like people
would want subpages on in new custom namespaces by default too.

--bawolff

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

[Wikitech-l] [GSOC 2014] Demo - Parsoid Based Linter

2014-06-25 Thread hardik juneja 
Hi Everyone,

I am a GSOC student working with Parsoid Team [1] <
https://www.mediawiki.org/wiki/Parsoid> to build a Parsoid based linter
(Linttrap) [2] <
https://www.mediawiki.org/wiki/Parsoid/Linting/GSoC_2014_Application>.
Lintrap will detect broken wikitext found on the wiki pages and will
also collect
stats about certain wikitext usage patterns.

Currently, for this demo, Lintrap can detect 4 types of broken wikitext, But,
other kinds of issues could be detected in the coming weeks and months :
 * Fostered Wikitext : Eg [3]
   
 * Missing End Tag : Eg [4]
   
 * Missing Start Tag : Eg [5]
   
 * Stripped Tags : Eg [6]
   

Linttrap also collect information about transclusion usages where multiple
templates are used to construct a DOM structure [7] <
http://lintbridge.wmflabs.org/_html/issues/53a3026794641d9101f8ea81>. Here's
our stats page [8] .

Once a page is parsed, Lintrap uses parsoid based logger facility to log
them to a web service. We call it Lintbridge [9] <
http://lintbridge.wmflabs.org/>. Currently Lintbridge is hosted on
Wikimedia Labs and use mongodb to store all the issues. Lintbridge offers a
REST api which can be used by bots and other applications to fix the broken
wikitext. Linttrap uses this REST api to store issues into Lintbridge.

We have also built a HTML app on top of Lintbridge [10]  <
http://lintbridge.wmflabs.org/_html/issues>. This is a basic app for now
which is used to demonstrate linttrap abilities. But, It is quite useful as
it is today. Feel free to browse over the issues.

  * You can use the links in the table to filter the issues.
  * Click on issue type to filter issue by issue type.
  * You can filter issue by page too.
  * You can use Fix All to fix all issue for that page.
  * You can even use filters on the top bar to filter by Wiki and Type.
  * Each issue contain a info about wiki, page, revision on the left and
the wikitext snippet on the right.

Just for the demo of this working prototype, we have collected issues by
parsing 1000 picked from  http://parsoid-tests.wikimedia.org/topfails
. If you want to try the
JSON API you can use the following routes.

GET  /_api/issues : Show all issues (
http://lintbridge.wmflabs.org/_api/issues)
GET /_api/issues/type/issue-type : Filter by issue-type (
http://lintbridge.wmflabs.org/_api/issues/type/fostered)
GET /_api/enwiki/issues : Filter by enwiki (
http://lintbridge.wmflabs.org/_api/enwiki/issues)

POST /_api/add : Add a issue to the Lintbridge
Inviting feedback.

Thank you
Hardik Juneja

--
​[1] Parsoid: https://www.mediawiki.org/wiki/Parsoid
[2] Linttrap:
https://www.mediawiki.org/wiki/Parsoid/Linting/GSoC_2014_Application
[3] Fostered Ex :
http://lintbridge.wmflabs.org/_html/issues/53a2fe1e94641d9101f8e8b2
[4] Missing End Tag eg :
http://lintbridge.wmflabs.org/_html/issues/53a2fca994641d9101f8e72a
[5] Missing Start Tag eg :
http://lintbridge.wmflabs.org/_html/issues/53a2fdc394641d9101f8e85
0

[6] Stripped Tag eg :
http://lintbridge.wmflabs.org/_html/issues/53a2fd4394641d9101f8e819
[7] Mixed Template eg :
http://lintbridge.wmflabs.org/_html/issues/53a3026794641d9101f8ea81
[8] Stats Page : http://lintbridge.wmflabs.org/stats
[9] Lintbridge: http://lintbridge.wmflabs.org/
[10] HTML App: http://lintbridge.wmflabs.org/_html/issues
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Front-End Standardization Chat

2014-06-25 Thread Erik Moeller 
Raw logs here:
https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-25-17.30.log.html

Next steps:

1) Trevor, Roan, Timo, Kaldari and others will refine the proposal at
https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework as
a concrete step to develop a standard UI framework for MediaWiki Core.

2) The proposal on the table is to implement this new skin framework, port
existing skins in MW core, and port it to "mobile as a skin" to ensure that
we're developing a multi-device, responsive design framework.

3) We'll reconvene with a dedicated IRC session about the refined RFC, and
then seek to create technical alignment and determine the exact allocation
of development effort beyond the team above. This will be in about two
weeks.

- - - - -

The aforementioned work will be coordinated on-wiki and via Bugzilla.

This proposal will only address parts of UX standardization. It does not
currently focus on look and feel itself, though it would lay the groundwork
for more CSS standardization as well. Other aspects - such as more
consistent browser support expectations - need to be resolved independently.

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Front-End Standardization Chat

2014-06-25 Thread S Page 
Developing a better way to generate interactive HTML with consistent UX is
important. I support this work, along with <
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library>.
But...

On Wed, Jun 25, 2014 at 11:53 AM, Erik Moeller  wrote:

> This proposal will only address parts of UX standardization. It does not
> currently focus on look and feel itself, though it would lay the
> groundwork for more CSS standardization as well.


No it won't (!), at least not for year or two. We already have the
under-resourced haphazard efforts to apply and refine a consistent UX
("Agora") to the HTML generated by random PHP, special pages, HTMLForm,
jQuery UI, various templating systems, and OOjs UI. This proposal adds
another, better, approach to generating that HTML, but until we drop the
other approaches it's increased the work (cue https://xkcd.com/927/  :) ).

2) The proposal on the table is to implement this new skin framework, port

> existing skins in MW core, and port it to "mobile as a skin"
>
Which is good but doesn't help other projects and their inconsistent UX.
The supposition is that because this new framework is in core it'll be a
tool available to all developers that will deliver UX consistency. I
propose a simple use case to prove that supposition:

* Extensions and core right now need a replacement for jquery.dialog() that
will render a modal dialog with Agora styling.

If this effort produces such a dialog with the requisite browser support (a
thorny issue as Erik says) and doesn't require rewriting the rest of the
extension's UX code, we'll know this is on the right track for more than
just skins and a mobile convergence. And there will be much rejoicing :)

(Maybe OOjs UI already provides that dialog, I think MultimediaViewer's
share dialog uses it.)

Regards,
-- 
=S Page  WMF Features engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] iPad bugs we need to fix in VE

2014-06-25 Thread Juliusz Gonera 
One more important bug to add to the list:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64575
(input becomes unresponsive in mobile link inspector on iOS Safari)


On Mon, Jun 23, 2014 at 3:17 PM, Juliusz Gonera 
wrote:

> There are three important bugs that need to be fixed in VE before we can
> move it to stable for tablets (specifically iPads). The first two were
> added by me just today. The third was reported in May by Rummana and for
> some odd reason had Jon assigned to it, although he has never worked on it
> (I removed him).
>
> Following Roan's suggestion I recorded videos on iOS simulator to
> illustrate what is happening in each case (thanks to Monte for letting me
> use his Macbook with up-to-date Xcode).
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=66999
> https://bugzilla.wikimedia.org/show_bug.cgi?id=67002
> https://bugzilla.wikimedia.org/show_bug.cgi?id=65326
>
> Let us (the mobile team) know if you need any help with those.
>
> --
> Juliusz
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] bugzilla: keyword for every language

2014-06-25 Thread Andre Klapper 
On Wed, 2014-06-25 at 17:11 +0200, Petr Bena wrote:
> ok that seems to be good enough for me. What is actually difference
> between these keywords and white-board if it can serve the same
> purpose?

See https://www.mediawiki.org/wiki/Bugzilla/Fields

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

[Wikitech-l] MediaWiki Bug Bounty Program

2014-06-25 Thread Tyler Romeo 
Hey everybody,

So today at the iSEC Partners security open forum I heard a talk from Zane 
Lackey,
the former security lead for Etsy, concerning the effectiveness of bug bounties.

He made two points:

1) Bug bounties are unlikely to cause harm, especially for Wikipedia, which I 
asked
him about, because the mere popularity of our service means we are already being
scanned, pentested, etc. With a bounty program, there will be incentive for 
people to
report those bugs rather than pastebin them.

2) Even without a monetary reward, which I imagine WMF would not be able to 
supply,
crackers are motivated simply by the “hall of fame”, or being able to be 
recognized for
their efforts.

Therefore, I thought it may be beneficial to take that over to Wikipedia and 
start our own
bug bounty program. Most likely, it would be strictly a hall of fame like 
structure where
people would be recognized for submitting bug reports (maybe we could even use 
the
OpenBadges extension *wink* *wink*). It would help by increasing the number of 
bugs
(both security and non-security) that are found and reported to us.

Any thoughts? (Of course, Chris would have to approve of this program before we 
even
consider it.)

-- 
Tyler Romeo
0xC86B42DF


signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Bug Bounty Program

2014-06-25 Thread Chris McMahon 
On Wed, Jun 25, 2014 at 4:28 PM, Tyler Romeo  wrote:
>
> Therefore, I thought it may be beneficial to take that over to Wikipedia
> and start our own
> bug bounty program. Most likely, it would be strictly a hall of fame like
> structure where
> people would be recognized for submitting bug reports (maybe we could even
> use the
> OpenBadges extension *wink* *wink*). It would help by increasing the
> number of bugs
> (both security and non-security) that are found and reported to us.
>
> Any thoughts?


Some time ago I ran a number of public exercises testing various aspects of
Wikipedia. I ran into a number of issues:

1) It takes a lot of preparation and time spent to do well.
2) Essentially 100% of bugs reported by naive reporters are DUPLICATE,
WONTFIX, or are in the backlog of some feature already.
3) Reporting bugs directly in bugzilla creates a lot of noise and annoys
people who monitor traffic there. (Mozilla runs things like this from time
to time, from them I learned to have people report in a separate system
e.g. etherpad or email, and have someone triage and sort the reports before
creating Bugzilla tickets, see point 1) above.)

Google, who spends a lot of money doing stuff like this for security
exploits, narrows the circumstances radically:
http://www.chromium.org/Home/chromium-security/pwnium-4 .
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Bug Bounty Program

2014-06-25 Thread Chris Steipp 
On Wed, Jun 25, 2014 at 4:28 PM, Tyler Romeo  wrote:
> Hey everybody,
>
> So today at the iSEC Partners security open forum I heard a talk from Zane
> Lackey,
> the former security lead for Etsy, concerning the effectiveness of bug
> bounties.
>
> He made two points:
>
> 1) Bug bounties are unlikely to cause harm, especially for Wikipedia, which
> I asked
> him about, because the mere popularity of our service means we are already
> being
> scanned, pentested, etc. With a bounty program, there will be incentive for
> people to
> report those bugs rather than pastebin them.
>
> 2) Even without a monetary reward, which I imagine WMF would not be able to
> supply,
> crackers are motivated simply by the "hall of fame", or being able to be
> recognized for
> their efforts.
>
> Therefore, I thought it may be beneficial to take that over to Wikipedia and
> start our own
> bug bounty program. Most likely, it would be strictly a hall of fame like
> structure where
> people would be recognized for submitting bug reports (maybe we could even
> use the
> OpenBadges extension *wink* *wink*). It would help by increasing the number
> of bugs
> (both security and non-security) that are found and reported to us.
>
> Any thoughts? (Of course, Chris would have to approve of this program before
> we even
> consider it.)

I've been thinking of at least putting up a list of top contributors
on mediawiki.org for a while, and just hadn't had the time to do it.
If anyone wants to compile that list from the list of closed security
bugs, I'd be very supportive.

As for a more official program, the downside that I predict we would
quickly hit (from talking to a few people who have run these) is the
high volume of very low quality reports that have to be investigated
and triaged. Which is something that just takes time from a human...
so my evil_plans.txt towards this was (I really had almost this
exactly in my todo list):
* Get more volunteers access to security bugs
** {{done}} get list of top contributors
** Find out from Philippe how to get a bunch of volunteers identified
*** Doh, we're probably changing our identification process soon. On hold.

So, I was planning to wait until we have a more streamlined process
for getting volunteers access to data that could potentially be
covered by our privacy policy, then invite some people who have
contributed significantly to MediaWiki's security in the past to get
access to those bugs and help triage/assign/fix bugs, then look into
starting something official or semi-official. But if a few of you
would be willing to deal with our current identification/NDA process
and are willing to help out investigate report, I'm happy to start
working on it sooner.



>
> --
> Tyler Romeo
> 0xC86B42DF

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

Re: [Wikitech-l] MediaWiki Bug Bounty Program

2014-06-25 Thread Alex Monk 
Chris, why don't we leave privacy policy compliance to the users posting on
the bug? Wikimedia personal user data shouldn't be going to the security
product.

Why does WMF get the right to control by access to MediaWiki security bugs
anyway? Could we not simply host MediaWiki stuff externally? Perhaps on the
servers of any other major MediaWiki user.

Alex
Sent from phone

On Wed, Jun 25, 2014 at 4:28 PM, Tyler Romeo  wrote:
> Hey everybody,
>
> So today at the iSEC Partners security open forum I heard a talk from Zane
> Lackey,
> the former security lead for Etsy, concerning the effectiveness of bug
> bounties.
>
> He made two points:
>
> 1) Bug bounties are unlikely to cause harm, especially for Wikipedia,
which
> I asked
> him about, because the mere popularity of our service means we are already
> being
> scanned, pentested, etc. With a bounty program, there will be incentive
for
> people to
> report those bugs rather than pastebin them.
>
> 2) Even without a monetary reward, which I imagine WMF would not be able
to
> supply,
> crackers are motivated simply by the "hall of fame", or being able to be
> recognized for
> their efforts.
>
> Therefore, I thought it may be beneficial to take that over to Wikipedia
and
> start our own
> bug bounty program. Most likely, it would be strictly a hall of fame like
> structure where
> people would be recognized for submitting bug reports (maybe we could even
> use the
> OpenBadges extension *wink* *wink*). It would help by increasing the
number
> of bugs
> (both security and non-security) that are found and reported to us.
>
> Any thoughts? (Of course, Chris would have to approve of this program
before
> we even
> consider it.)

I've been thinking of at least putting up a list of top contributors
on mediawiki.org for a while, and just hadn't had the time to do it.
If anyone wants to compile that list from the list of closed security
bugs, I'd be very supportive.

As for a more official program, the downside that I predict we would
quickly hit (from talking to a few people who have run these) is the
high volume of very low quality reports that have to be investigated
and triaged. Which is something that just takes time from a human...
so my evil_plans.txt towards this was (I really had almost this
exactly in my todo list):
* Get more volunteers access to security bugs
** {{done}} get list of top contributors
** Find out from Philippe how to get a bunch of volunteers identified
*** Doh, we're probably changing our identification process soon. On hold.

So, I was planning to wait until we have a more streamlined process
for getting volunteers access to data that could potentially be
covered by our privacy policy, then invite some people who have
contributed significantly to MediaWiki's security in the past to get
access to those bugs and help triage/assign/fix bugs, then look into
starting something official or semi-official. But if a few of you
would be willing to deal with our current identification/NDA process
and are willing to help out investigate report, I'm happy to start
working on it sooner.

>
> --
> Tyler Romeo
> 0xC86B42DF

___
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] MediaWiki Bug Bounty Program

2014-06-25 Thread Chris Steipp 
On Wed, Jun 25, 2014 at 5:49 PM, Alex Monk  wrote:
> Chris, why don't we leave privacy policy compliance to the users posting on
> the bug? Wikimedia personal user data shouldn't be going to the security
> product.

There are a few cases where there may be legitimate private data in a
security bug ("look, sql injection, and here are some rows from the
user table!", "Hey, this was supposed to be suppressed, and I can see
it", "This user circumvented the block on this IP"). But there might
be ways to flag or categorize a report as also including private data?
Someone with more bugzilla experience would need to comment.

> Why does WMF get the right to control by access to MediaWiki security bugs
> anyway? Could we not simply host MediaWiki stuff externally? Perhaps on the
> servers of any other major MediaWiki user.

This certainly could be done. That "other major MediaWiki user" would
have to be someone everyone trusts, and preferably with a strong track
record of being able to keep their infrastructure secure. If there's a
legitimate proposal to try it, let's definitely discuss.

> Alex
> Sent from phone
>
> On Wed, Jun 25, 2014 at 4:28 PM, Tyler Romeo  wrote:
>> Hey everybody,
>>
>> So today at the iSEC Partners security open forum I heard a talk from Zane
>> Lackey,
>> the former security lead for Etsy, concerning the effectiveness of bug
>> bounties.
>>
>> He made two points:
>>
>> 1) Bug bounties are unlikely to cause harm, especially for Wikipedia,
> which
>> I asked
>> him about, because the mere popularity of our service means we are already
>> being
>> scanned, pentested, etc. With a bounty program, there will be incentive
> for
>> people to
>> report those bugs rather than pastebin them.
>>
>> 2) Even without a monetary reward, which I imagine WMF would not be able
> to
>> supply,
>> crackers are motivated simply by the "hall of fame", or being able to be
>> recognized for
>> their efforts.
>>
>> Therefore, I thought it may be beneficial to take that over to Wikipedia
> and
>> start our own
>> bug bounty program. Most likely, it would be strictly a hall of fame like
>> structure where
>> people would be recognized for submitting bug reports (maybe we could even
>> use the
>> OpenBadges extension *wink* *wink*). It would help by increasing the
> number
>> of bugs
>> (both security and non-security) that are found and reported to us.
>>
>> Any thoughts? (Of course, Chris would have to approve of this program
> before
>> we even
>> consider it.)
>
> I've been thinking of at least putting up a list of top contributors
> on mediawiki.org for a while, and just hadn't had the time to do it.
> If anyone wants to compile that list from the list of closed security
> bugs, I'd be very supportive.
>
> As for a more official program, the downside that I predict we would
> quickly hit (from talking to a few people who have run these) is the
> high volume of very low quality reports that have to be investigated
> and triaged. Which is something that just takes time from a human...
> so my evil_plans.txt towards this was (I really had almost this
> exactly in my todo list):
> * Get more volunteers access to security bugs
> ** {{done}} get list of top contributors
> ** Find out from Philippe how to get a bunch of volunteers identified
> *** Doh, we're probably changing our identification process soon. On hold.
>
> So, I was planning to wait until we have a more streamlined process
> for getting volunteers access to data that could potentially be
> covered by our privacy policy, then invite some people who have
> contributed significantly to MediaWiki's security in the past to get
> access to those bugs and help triage/assign/fix bugs, then look into
> starting something official or semi-official. But if a few of you
> would be willing to deal with our current identification/NDA process
> and are willing to help out investigate report, I'm happy to start
> working on it sooner.
>
>>
>> --
>> Tyler Romeo
>> 0xC86B42DF
>
> ___
> 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

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

Re: [Wikitech-l] MediaWiki Bug Bounty Program

2014-06-25 Thread Brian Wolff 
On 6/26/14, Chris Steipp  wrote:
> On Wed, Jun 25, 2014 at 5:49 PM, Alex Monk  wrote:
>> Chris, why don't we leave privacy policy compliance to the users posting
>> on
>> the bug? Wikimedia personal user data shouldn't be going to the security
>> product.
>
> There are a few cases where there may be legitimate private data in a
> security bug ("look, sql injection, and here are some rows from the
> user table!", "Hey, this was supposed to be suppressed, and I can see
> it", "This user circumvented the block on this IP"). But there might
> be ways to flag or categorize a report as also including private data?
> Someone with more bugzilla experience would need to comment.
>
>> Why does WMF get the right to control by access to MediaWiki security bugs
>> anyway? Could we not simply host MediaWiki stuff externally? Perhaps on
>> the
>> servers of any other major MediaWiki user.
>
> This certainly could be done. That "other major MediaWiki user" would
> have to be someone everyone trusts, and preferably with a strong track
> record of being able to keep their infrastructure secure. If there's a
> legitimate proposal to try it, let's definitely discuss.
>

Personally I'd prefer that MediaWiki related support software stay
hosted by WMF (at least for the foreseeable future). WMF just seems
like the logical people to host it, and I don't see any harm in
MediaWiki being a "Wikimedia project" in a similar sense as wikipedia
is a Wikimedia project. What I would like to see though is a mediawiki
world where WMF is not special.  What I mean by that is that being a
WMF employee/contractor wouldn't get you any special treatment -
trusted people would get special access where needed because they're
trusted and have demonstrated their competence. A WMF staffer would
have to go through the same procedure as anyone else would have to to
get any sort of special access. Much of the people who have special
access would still be WMF employees, since WMF employs most senior
developers, but it wouldn't be "you're a wmf employee = here's access
to everything even if you don't need it", "you're not a WMF employee =
have to jump through a million hoops plus sign something in blood plus
bribe someone to get access to things that would be extremely helpful
to your work".

--bawolff

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

[Wikitech-l] Fwd: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives

2014-06-25 Thread Tilman Bayer 
Meant to CC Wikitech-l too...


-- Forwarded message --
From: Tilman Bayer 
Date: Wed, Jun 25, 2014 at 8:37 AM
Subject: Re: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
To: Wikimedia Mailing List 


Minutes and slides from last Friday's quarterly review of the
Foundation's Parsoid team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Parsoid/June_2014
.

On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller  wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> ___
> Wikimedia-l mailing list
> wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


-- 
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

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