First: Thanks for responding to this and writing it up.
<quote name="Yuri Astrakhan" date="2013-10-31" time="04:53:44 +0400">
> == Recomendations ==
> * Allow a bit more time between deployments and observe fatalmonitor before
> and after
Agreed.
I put a ton of blame on myself for not slowing down the cadence of LD
slots when a bunch of people are trying to get in on the same day.
For future LDs I am going to explicitly ask everyone to do what Yuri
suggests (monitor fatals after your deploy) before saying that you're
done. 5 minutes post-deploy of watching the fatalmonitor isn't
unreasonable, I don't think.
Relatedly, I think we should reassess the Lightning Deploys :)
Not necessarily to get rid of them (probably not), but:
1) how many deploys can go in one LD? How many do we *want* to go?
2) from 1, is the length of the LD long enough/too long?
3) LD management is still pretty high-communication ("Alright, who's in
line? Who's up next? Are you done yet?") There are basic tools that can
help with this (Etsy has an IRC "pushbot" that manages the queue mostly
automatically, for instance); I'll look into those/test them.
4) probably more, aka: your thoughts?
Greg
PS: graph of the fatals attached, just for completenesses sake.
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
TL;DR: We're starting to remove long-deprecated methods. First, they'll be wrapped in mw.log.deprecate (possibly replaced with dummy values) which will produce a stacktrace to the console when used. Example: http://cl.ly/image/3W0o131K0D3j
Pre-amble:
* As of MediaWiki 1.17 we started actively developing new javascript features.
* Any code from before that point has been tagged "legacy" and deprecated as of v1.17.0 back in 2011.
Problems:
* There is no easy way to see whether a page is using any of these deprecated interfaces.
* We still haven't removed any of the legacy code.
* Though we've added new things (jQuery, jQuery UI, mw.Title, mw.Uri etc.). We've been reluctant to iterate further on these "new" things and haven't been able to really refactor or improve them.
We've upgraded jQuery and jQuery UI a few times. But only because there were no major changes in backwards compatibility. This changed in 1.9 and that's why we're still on 1.8.
It would seem we're in a fixed position – unable to move up, only sideways. On the server-side of MediaWiki, deprecation has been a natural process enforced socially (plugins not maintained for several release cycles will simply have to be disabled). We introduce the new, we migrate uses of the old, we deprecate the old, we support both for uses for a while to allow others to migrate their stuff, then we remove the old.
In the front-end we never completed such a cycle. But, we're getting close to the completion of our first first cycle now. The legacy scripts deprecated as of v1.17.0 have all been removed or wrapped in mw.log.deprecate.
Please go to your favourite wiki in debug=true mode with a modern browser (recent Chrome, Firefox or Opera) and look at the console. Look for any uncaught exceptions, deprecation notices or other messages and try to address them soon (or report it to the maintainers of the gadgets triggering them).
-- Krinkle
[1] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.log-method-dep…
There is a plan for a worldwide round of Aaron Hackathons, on the
upcoming Nov 8-10 weekend.
http://aaronswartzhackathon.org/
Coordination:
https://www.noisebridge.net/wiki/Worldwide_Aaron_Swartz_Memorial_Hackathon_…
We have been invited to run a hackathon. Can we organize it? We would
need to find a project and a critical mass of contributors willing to
document and coordinate the hackathon.
One possibility could be to kick-off the hackathon on Friday 8 Nov in a
physical location (San Francisco), and focus initially on the
distribution of tasks. Then remote participants could also participate
taking tasks, participating with the rest of the group on some IRC
channel and occasional videoconferences.
About the project, I personally think that it should have a link with
the motivation of the hackathon:
"We were part of an inchoate, ad-hoc community of collaborators who
helped each other learn how to code. No, not how to write code ‒ how to
write code for the purpose of changing the world." - Zooko, on memories
of Aaron
See also https://en.wikipedia.org/wiki/Aaron_Swartz#Life_and_works
On Sat, 5 Oct 2013, Noah Swartz wrote:
> Hey assorted Wikimedia people,
> As I may have mentioned to some of you previously, we're running another
> round of Aaron Hackathons, on the upcoming Nov 8-10 weekend. I was
> wondering if WMF would be interested in providing a project for people to
> work on. For each event we're hoping to have one well structured project
> that people - both technical and non - can work on that can have some
> support from people who have worked on it or related projects previously,
> so that participants can jump right in.
> Would you be willing to structure something for people to work on? If not
> are there other WMF related things that people can do? Maybe go through a
> list of open bugs or feature requests? Or maybe just writing documents, or
> doing outreach, any project is welcome.
> Currently we have two tentative events in SF and ~5 more confirmed
> locations elsewhere around the world. We have a very basic landing page up
> at http://aaronswartzhackathon.org/ which might give you more of a sense of
> what's going on. I assume that SF is the location that works best for you
> but let me know if you think somewhere else would be good. I'd really love
> to see you all participate so let me know if there's anything I can do to
> help.
> As always feel free to pass this along to anyone else who you think might
> be interested, and I'm happy to answer any and all questions you have.
> Looking forward to hearing back soon!
> Noah
>
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 of free fonts.
Yes, it does hinder the cause of free fonts. We won't help scratching
the itch because in practice we will rely on a proprietary solution for
our UX work targeting the majority of users. While not forcing anybody
to use free fonts, our mockups, tests, reviews, screenshots and what not
will all assume the happy coincidence that Helvetica Neue ("the most
ubiquitous in advertising copy and logos") and Georgia (Microsoft
Corporation) are everywhere.
Now compare with this hypothetical scenario: we actually bet on a set of
optional free fonts, because we care about typography as much as we care
about freedom. We use them as default in our mockups, tests, reviews,
screenshots and what not. We serve them as web fonts, we bundle them in
our apps and offline versions, we promote them to the users missing them
in their systems. We take note of our own itches and user feedback, and
we file bugs and enhancement requests upstream, or send/commission
improvements. This way we contribute spreading free typography, just
like we contribute spreading other areas of free knowledge, free culture
and free software.
> 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 "detrimental" than not serving them conveniently mp3, mpeg, flash,
Facebook/Twitter/Google login, and other proprietary options already
installed in your average Mac / Windows desktop that we decided not to
support.
If the above scenario to improve the MediaWiki/Wikimedia UX by improving
free fonts is not exciting, or a priority, then at least we could be
neutral and not promote actively any proprietary font either.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Google Code-in has been announced:
http://www.google-melange.com/gci/homepage/google/gci2013
This is about 13-17 year old students performing tasks that can be
isolated and a skilled contributor would complete in a couple of hours.
The tasks mjust have a mentor and can be related to code, documentation,
outreach, QA or UX. Participants get one point for each task completed
and they can complete as many as they can between 18 November and 6 January.
Wikimedia can apply thanks to our participation on GSoC 2013. The
deadline is 28 October. Only 10 organizations will be accepted.
I think we should apply. Main reasons:
* The definition of a Code-in task fits very well with our ideal
definition of an annoying little bug:
https://www.mediawiki.org/wiki/Annoying_little_bugs
* The typical Code-in participant needs what most potential new
contributor also need from us: an insightful landing page, straight
connections to first tasks and friendly community support.
* Just like GSoC / OPW, it is a good chance for non-primetime projects
to raise their hands, get some help and hopefully some new contributors.
* Good exercise for first-time mentors, practicing for more co plex
internship projects.
* Good exercise for any open source project, meaning just any MediaWiki
/ Wikimedia tech project.
But of course this will only work if many projects want to step in with
a task and a mentor for it. So what do you think?
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
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 with our
support for free software throughout the movement.
I completely agree we should choose great free fonts that fit our
intended design.
> Most popular Linux variants specify an equivalent FOSS font for
> "Helvetica" that ships with the OS for exactly this scenario, ensuring
> that users get a decent approximation of the proprietary font's
> appearance by some FOSS font.
For the record (and I think similar to what you said), this may be the
case for Helvetica, but not necessarily Helvetica Neue. On my machine,
fc-match gives
'Helvetica' => "Nimbus Sans L" "Regular"'
'Helvetica Neue' => "DejaVu Sans" "Book"
'Made-up font name' => "DejaVu Sans" "Book"
Nimbus Sans L is indeed based on Helvetica
(https://en.wikipedia.org/wiki/Nimbus_Sans_L). I think the other two
are just last-ditch fallbacks (hence why it's the same for 'Made-up font
name').
I set up http://jsfiddle.net/UPBUH/ as a quick testing ground. When I
check the Fonts tab of Firefox's Web Console (not Firebug), it shows
"Nimbus Sans L Bold system". Used as: "Nimbus Sans L".
I think that means fc is looking through the whole stack and picking
Nimbus Sans L as the best match. I think corroborates what you said
earlier ("fontconfig will use the first font in the font stack that has
a positive match.")
S, can I ask what you see for that fiddle on the same console tab?
> 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 put the free font first, we're saying we want to use that free
font (because it's a free, and fits our intended design well).
The extremely few users who manually customize their font-matching can
still override e.g. what "Nimbus Sans L" points to on their machine.
> A font stack is inherently undefined behavior :)
> Yes we get somewhat unspecified behavior for a small subset of our
> users, but on balance it's better and more freedom-y to let them evolve
> a better FOSS version of the notion of "Helvetica" than nailing them to
> 2012's fallback "Nimbus Sans L".
Who says we have to nail anything down? We can choose Nimbus Sans L
initially and then put a similar but better free font first later.
Matt Flaschen
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 next few months, she may venture out into other areas (e.g.
automation).
Rummana earned a Bachelors of Science in Computer Science, from North
South University in Dhaka, Bangladesh, and recently earned a Graduate
Certificate in IT management from Golden Gate University.
You'll find her on our IRC channels as "rummana", and her email is
ryasmeen(a)wikimedia.org.
Welcome, Rummana!
Rob
p.s. important pronunciation guide, since things are about to get
confusing for many of us who work with her in-person/on phone, etc.
Rummana pronounces her name with the accent on the second syllable
("ru-MAH-nuh"), as opposed to Sumana who pronounces her name with the
accent on the first ("SU-mah-nuh")
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.
On Tue, Oct 29, 2013 at 12:51 PM, Jared Zimmerman <
jared.zimmerman(a)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'd have to do
> some testing, it really comes down to if we specify Helvetica Neue, and a
> particular system thinks that should match a different free font than the
> one we thought was a best match.
>
Just to confirm: I did a quick test, and it appears that on OSX (10.9)
Chrome and Firefox interpret font family settings the same using the order
Tim suggested. So the output is still Georgia headings and Helvetica Neue
body.
One question... it seems like specifying Helvetica regular and Neue is
slightly redundant. Is there are reason we don't cut Helvetica regular from
the list?
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/