Today was one crazy day.
The build peers all sat down with Release Engineering and Axel Hecht to talk l10n packaging. Mike Hommey has a Q1 goal to fix l10n packaging. There is buy-in from Release Engineering on enabling him in his quest to slay dragons. This will make builds faster and will pay off a massive mountain of technical debt that plagues multiple groups at Mozilla.
The Firefox build system contributors sat down with a bunch of Rust people and we talked about what it would take to integrate Rust into the Firefox build system and the path towards shipping a Rust component in Firefox. It sounds like that is going to happen in 2015 (although we're not yet sure what component will be written in Rust). I consider it an achievement that the gathering of both groups didn't result in infinite rabbit holing about system architectures, toolchains, and the build people telling horror stories to wide-eyed Rust people about the crazy things we have to do to build and ship Firefox. Believe me, the temptation was there.
People interested in the build system all sat down and reflected on the state of the build system and where we want to go. We agreed to create a build mode optimized for non-Gecko developers that downloads pre-built binaries - avoiding ~10 minutes of C/C++ compile time for builds. Mark my words, this will be one of those changes that once deployed will cause people to say "I can't believe we went so long without this."
I joined Mark Côté and others to talk about priorities for MozReview. We'll be making major improvements to the UX and integrating static analysis into reviews. Push a patch for review and have machines do some of the work that humans are currently doing! We're tentatively planning a get-together in Toronto in January to sprint towards awesomeness.
I ended the day by giving a long and rambling presentation about version control, with emphasis on Mercurial. I can't help but feel that I talked way too much. There's just so much knowledge to cover. A few people told me afterwards they learned a lot. I'd appreciate feedback if you attended. Anyway, I got a few nods from people as I was saying some somewhat contentious things. It's always good to have validation that I'm not on an island when I say crazy things.
I hope to spend Friday chasing down loose ends from the week. This includes talking to some security gurus about another crazy idea of mine to integrate PGP into the code review and code landing workflow for Firefox. I'll share more details once I get a professional opinion on the security front.
Note: This blog post started as a rant about MDN which is sadly not very useful for add-on authors way too often. I tried to reformulate it in a neutral way. The point definitely isn’t blaming the people working hard on keeping that documentation up to date.
MDN has some great content. However, as far as extension development goes, maybe somewhat less content and more structure/quality would be beneficial. Yes, there are a few well-written overview articles. But quite frankly, I’ve seen them for the first time today — because most of the time I’ll get to MDN via a search engine. And if you take this route, there is a good chance to hit an article that pre-dates Firefox 4.0.
Don’t believe me? Try searching for a guide to write XPCOM components. You are bound to hit this book written more than a decade ago. Not only is it horribly outdated, it explains how one would create such a component in C++ — something that is completely impracticable for extensions in current Firefox versions.
The next search hit is only marginally better. The examples here have been somewhat updated to work in recent Firefox versions. It starts by sending people to an extension which is compatible with Firefox 3.0. It then explains the scary details of defining your own interface — yet most developers simply want to implement an existing interface. And as if the original document wasn’t already crappy enough, somebody also added instructions on integrating the whole thing into the Mozilla build system — all that before the actually relevant stuff of course. You might also end up in this troubleshooting guide which used to be pretty helpful — five years ago.
In fact, XPCOM Changes in Gecko 2.0 seems to be the only piece of documentation with a complete explanation, starting with the code of the component itself and ending with the way it is registered via chrome.manifest. Not that this document is comprehensible, being primarily a list of changes. And of course, that’s a place where nobody will come looking.
This isn’t even about the long list of nice functionality that was implemented but never documented. Like the XPCOM iterator helpers introduced four years ago. Or a way to listen to all events. Or a way to apply user stylesheets to individual documents. Yes, the dev-doc-needed queue is very long and there is only so many people who contribute to MDN (besides, they would also need to understand the change).
So, how can this be solved? I see a few options:
- Marking documents as deprecated or obsolete isn’t sufficient, documents that aren’t useful need huge and very visible warnings at the very least. But frankly, why still keep them around?
- Mozilla has great technical writers but they clearly cannot keep up. That’s not really surprising given how much Mozilla has grown. Maybe developers who actually wrote the changes could help beyond setting the dev-doc-needed flag? Sure, not everybody is a great writer. However, some documentation is already something that can be improved.
Anything else that can be done?
Yesterday, during the Mozilla work week, some comments made by my colleagues made me think about Webmaker Clubs using a new metaphor. I tested it out in a few conversations and it didn’t get shot down, so I’m recording it here to come back to.
I thought about there being ‘three legs to the stool’ for Webmaker Clubs (name TBC):
- Web literacy
The Web Literacy Map (currently v1.1 but soon v2.0) provides the basis for curriculum and learning pathways. We can build off this in a fairly straightforward way - and in fact Laura Hilliger has begun to do just that.
What I feel we need is some kind of 'map’ for the other two legs of the stool. What what this look like for facilitation skills? What about for pedagogy/ethos?
I was asked for clarity on pedagogy/ethos. It probably needs a better name, but all I mean here are the approaches to teaching and learning that work well in blended learning environments. What works well when you’re mentoring people both online and offline? Also, in terms of ethos, what do we mean by 'working open’?
If we went ahead with this approach we’d need to get the help of the community to help build it – as we do with the Web Literacy Map. The great thing is that if we did it right, we could provide a handbook that works in most situations. It would need to be generic enough to be applicable everywhere, but specific enough to guide new mentors.
Comments? Questions? Email me: firstname.lastname@example.org
and I realised that I completely forgot to update gh-blog. Gah
Con el lanzamiento de iOS 8 y los primeros pasos para una apertura de Apple a los navegadores que no usan Webkit como motor de renderizado, y después de haber anunciado que no lanzarían una versión de Firefox para ese sistema, Mozilla ha cambiado su postura y entrará en iOS.
El anuncio fue realizado por Jonathan Nightingale VP de Firefox y compartido por Lukas Blakk, Jefe de lanzamientos de Firefox en su cuenta en Twitter mientras realizaban un evento interno. “Necesitamos estar donde nuestros usuarios están, por eso vamos a llevar a Firefox a iOS”
Hace poco fue anunciado oficialmente esa postura y han dicho:
En Mozilla, ponemos al usuario de primero y queremos ofrecer una opción independiente para ellos en cualquier plataforma. Estamos en las etapas iniciales de experimentación con algo que permita a los usuarios de iOS poder elegir Firefox.
Estamos experimentando con un par de conceptos diferentes y cuando tengamos más, lo compartiremos.
Ahora, todas aquellas personas que usen iOS podrán contar con las características que ofrece Firefox y acabarán ganando al poder elegir entre varios navegadores dentro del ecosistema.
One of the things I am grateful for in working for Mozilla is the opportunity to learn.
Recently through various channels, I’ve learned about values, trust and integrity. (Side note: I highly recommend the book that I am currently reading : The Speed of Trust)
Values are highly important to people and the company/culture. ( Side note: I also found that for those that throw away the very value that they are trying to protect at all cost will find themselves very miserable. )
Maybe I am dumb; I don’t understand a few things still though and I need help understanding it after even having worked 4 years at the company. These are the top two things that still cause me to wonder:
1) How does one stay open about protecting privacy/IP and how can we protect privacy/IP and still be open? And without being miserable?
2) How do we stay open in a fast moving environment where we’re constantly busy? The context of this is that I had been talking to a few coworkers and when we were talking, I happened to tell them something they weren’t aware of. The expression “oh I wish I knew that sooner” was stated. Blogs and emails can be missed often, and in some people’s cases skipped from being read; miss a meeting and you won’t hear about it. Asking around and trying to get the source of truth sometimes is hard and doesn’t scale, etc. etc. Everyone has a different way of working it seems… how do you get the source of truth and maintain doing the work load of going faster?
Filed under: Planet, QMO Tagged: Planet, QMO