On Mon, Oct 28, 2013 at 12:42 AM, Ori Livneh o...@wikimedia.org wrote:
I think that the proper way to handle low-level operational data like
stack traces is to make it clear that it is liable to contain
sensitive information, and to make no pretense at all of sanitizing
it.
I don't think the
Hi,
is there any possible technical way to make a filter in bugzilla that
filter out bugs that are waiting for a response from bug opener (OP)?
I suppose there could be either a keyword or something like
WAITING-FOR-RESPONSE but in that case it would need to be removed by
hand when OP respond.
I don't think the idea here was to ever make the stack traces *safe*,
just to redact the most obvious things to reduce the risk if someone
carelessly posts a stack trace publicly.
Personally, I think the Java model as exemplified in
https://gerrit.wikimedia.org/r/#/c/92334/ PS3 goes too far
I'm thinking of proposing the redesign of the mediawiki.org homepage as
a FOSS Outreach Program for Women [1] project. I could act as co-mentor
with the help of someone else.
The RFC process held so far [2] would serve as a source of feedback, but
the project would imply basically a restart.
On Tue, Oct 29, 2013 at 2:54 PM, Petr Bena benap...@gmail.com wrote:
Hi,
is there any possible technical way to make a filter in bugzilla that
filter out bugs that are waiting for a response from bug opener (OP)?
I suppose there could be either a keyword or something like
On Tue, Oct 29, 2013 at 9:55 AM, Dan Andreescu dandree...@wikimedia.org wrote:
I think Ori's original point stands though. Configuration could be used to
redact fully / not redact at all for local debugging purposes. But a black
list for what to redact is bad for all the reasons black lists
Hey,
Most probably I am late but can we still add tasks or volunteer for
mentoring?
Apologies for being late,
Aarti
On Mon, Oct 28, 2013 at 9:22 PM, Quim Gil q...@wikimedia.org wrote:
We have applied to Google Code-in and we will know whether we have been
accepted or not this Friday.
Hi,
I have some patches for Extension:Collection, which actually apply to
mwlib. While the php code seems to reside on the wikimedia servers,
mwlib is on github.
Should I attach them to a corresponding bug on bugzilla.wikimedia.org,
or should I open a pull request on github?
Thanks,
Strainu
adding their list
-- Forwarded message --
From: Strainu strain...@gmail.com
Date: Oct 29, 2013 12:30 PM
Subject: [Wikitech-l] What's the prefered way to contribute patches to
Pediapress' mwlib?
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Cc:
Hi,
I have some patches
On 10/29/2013 09:28 AM, Aarti K. Dwivedi wrote:
Most probably I am late but can we still add tasks or volunteer for
mentoring?
Yes!
Apologies for being late,
You answered here. You are not late. Thank you for your involvement!
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia
Hi,
On Tue, 2013-10-29 at 21:58 +0530, Aarti K. Dwivedi wrote:
Most probably I am late but can we still add tasks or volunteer for
mentoring?
Thanks for your interest! Yes you can, and they are welcome!
However I'd turn that into add tasks *AND* volunteer for mentoring,
because having
+ wikitech
On Tue, Oct 29, 2013 at 8:54 AM, Siebrand Mazeland (WMF)
smazel...@wikimedia.org wrote:
Also see https://gerrit.wikimedia.org/r/#/c/23424/
In my opinion, external link icons add a lot of visual noise and not that
much relevant information.
On Mon, Oct 28, 2013 at 11:22 PM,
On Tue, 29 Oct 2013 14:54:49 +0100, Petr Bena benap...@gmail.com wrote:
Hi,
is there any possible technical way to make a filter in bugzilla that
filter out bugs that are waiting for a response from bug opener (OP)?
No, but there are some things which may or may not be close enough for your
On 10/27/2013 03:37 PM, Steven Walling wrote:
Many FOSS communities have dealt with the trade off between great-looking
fonts and freedom by commissioning foundries to get their own free fonts.
See also: Ubuntu, Android, and more. I've talked to the design team about
this idea, including perhaps
On 10/28/2013 07:43 AM, Liangent wrote:
btw. Be aware of internationalization issues: not to say that fonts are
usually tied to a (group of) alphabets. Even digits can be affected by the
language info of the context they live.
See [1]: this is the standard English Wikipedia signup screen, and
As one that started of participated in this discussion in many back
corners...
On 10/27/2013 09:50 AM, Chad wrote:
Our ideologies are far more important than typography.
We bet on free licenses for all the content and software we produce,
even if sometimes potentially superior free as in
On Tue, Oct 29, 2013 at 12:51 PM, Jared Zimmerman
jared.zimmer...@wikimedia.org wrote:
We have an action item to change the order from the free fonts that are
visually similar to the specified non-free fonts, I don't think* that this
will change the experience for user without those fonts but
We've put together an RC for 1.22.0. Please test the tarball and report
any bugs you find on Bugzilla: http://bugzilla.wikimedia.org/
Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/tags/1.22.0rc0/RELEASE-NOTES-1.22
https://www.mediawiki.org/wiki/Release_notes/1.22
They are different fonts from different font families, not members of
the same family, and Helvetica is far, far more common than Helvetica Neue.
On Oct 29, 2013, at 10:13 AM, Steven Walling swall...@wikimedia.org wrote:
One question... it seems like specifying Helvetica regular and
Hi!
How site names displayed by RelatedSites extension could be localized?
For example, such links are heavily used in Wikivoyage, but only
section header in toolbox is localized and English project names are
used for links.
Eugene.
___
Wikitech-l
Hi everyone,
I'd like to introduce Rummana Yasmeen, a new Software Test Engineer in
our QA team through April in our San Francisco office. Rummana is
going to be working with our Visual Editor team primarily on manual
testing, finding bugs so you don't have to. Depending on how things
go in the
On Tue, Oct 29, 2013 at 4:04 PM, Rob Lanphier ro...@wikimedia.org wrote:
Hi everyone,
I'd like to introduce Rummana Yasmeen, a new Software Test Engineer in
our QA team through April in our San Francisco office. Rummana is
going to be working with our Visual Editor team primarily on manual
On 10/29/2013 06:30 PM, S Page wrote:
This seems right. I repeat, there is no benefit to putting the free
names first, unless designers think they look better.
One important benefit is that we encourage use of free fonts, even when
both free and proprietary fonts are installed. This fits
On 10/29/2013 06:04 PM, Rob Lanphier wrote:
Hi everyone,
I'd like to introduce Rummana Yasmeen, a new Software Test Engineer in
our QA team through April in our San Francisco office. Rummana is
going to be working with our Visual Editor team primarily on manual
testing, finding bugs so you
On 2013-10-29 4:07 PM, Matthew Flaschen wrote:
A few brave users customize the matching behavior because they prefer
something else, or they read some how-to
article. If we put the free names first, we just frustrate those
efforts, and the experience of 90% of our users doesn't change.
If we
On 29 October 2013 17:04, Rob Lanphier ro...@wikimedia.org wrote:
Hi everyone,
I'd like to introduce Rummana Yasmeen, a new Software Test Engineer in
our QA team through April in our San Francisco office. Rummana is
going to be working with our Visual Editor team primarily on manual
On 10/29/2013 07:14 PM, Daniel Friesen wrote:
The extremely few users who manually customize their font-matching can
still override e.g. what Nimbus Sans L points to on their machine.
You're basically suggesting that users who have customized their
browsers/OS to handle the patterns used on the
On 2013-10-29 4:25 PM, Matthew Flaschen wrote:
On 10/29/2013 07:14 PM, Daniel Friesen wrote:
The extremely few users who manually customize their font-matching can
still override e.g. what Nimbus Sans L points to on their machine.
You're basically suggesting that users who have customized
On 10/29/2013 03:30 PM, S Page wrote:
Quim:
And if we want to specify any fonts in our works, they should be free.
Uh, why? Mac users actually have Helvetica Neue, the nicest-looking
font, Windows users have Georgia. The presence of these names in our CSS
does nothing to hinder the cause
On 2013-10-29 4:47 PM, Quim Gil wrote:
On 10/29/2013 03:30 PM, S Page wrote:
Removing them would be detrimental for most of our users.
Detrimental... they would still be able to access all our content and
functionality without losing a single readable character, right? A lot
less
On Tue, Oct 29, 2013 at 6:55 AM, Dan Andreescu dandree...@wikimedia.org wrote:
I don't think the idea here was to ever make the stack traces *safe*,
just to redact the most obvious things to reduce the risk if someone
carelessly posts a stack trace publicly.
Personally, I think the Java model
Proprietary fonts are copyrighted (dubiously though) not patented.
Actually this is quite complicated. In the U.S., Japan, and some other
countries, typefaces cannot be copyrighted. However, specific font
implementations of typefaces can. So for, example, someone could release a
free license
On Tue, Oct 29, 2013 at 4:07 PM, Matthew Flaschen
I set up http://jsfiddle.net/UPBUH/ as a quick testing ground.
Nice, I tweaked it to make
http://jsfiddle.net/UPBUH/7/http://jsfiddle.net/UPBUH/6/, you can
see what your browser + O.S. picks for each font name in the font
stack.
When I check
add tasks *AND* volunteer for mentoring
I agree it makes tasks easier, and I will be mentoring all the tasks I
propose and any
other tasks if I ca. Thanks a lot! :)
On Tue, Oct 29, 2013 at 11:16 PM, Andre Klapper aklap...@wikimedia.orgwrote:
Hi,
On Tue, 2013-10-29 at 21:58 +0530, Aarti K.
On 30/10/13 11:37, Ryan Kaldari wrote:
Regarding Nimbus Sans: Does anyone know how I can get this font without
installing all of Ghostscript?
apt-get install gsfonts
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
35 matches
Mail list logo
