On Tue, Jun 24, 2014 at 2:30 PM, Bryan Davis bd...@wikimedia.org wrote:
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 ...
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
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
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
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
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
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
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
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
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]
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 aklap...@wikimedia.org wrote:
On Wed, 2014-06-25 at 13:51 +0200, Petr Bena wrote:
it maybe works for large
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
On 6/25/14, MZMcBride z...@mzmcbride.com 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,
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
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
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 e...@wikimedia.org wrote:
This proposal will
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 jgon...@wikimedia.org
wrote:
There are three important bugs that need to be fixed
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
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,
On Wed, Jun 25, 2014 at 4:28 PM, Tyler Romeo tylerro...@gmail.com 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
On Wed, Jun 25, 2014 at 4:28 PM, Tyler Romeo tylerro...@gmail.com 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
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?
On Wed, Jun 25, 2014 at 5:49 PM, Alex Monk kren...@gmail.com 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
On 6/26/14, Chris Steipp cste...@wikimedia.org wrote:
On Wed, Jun 25, 2014 at 5:49 PM, Alex Monk kren...@gmail.com 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
24 matches
Mail list logo
