Why an ops career
Disclaimers: Not all tasks that come to a person in an ops role meet my definition of ops tasks. Advanced ops teams move on from simple problems and choose more complex problems to solve, for a variety of reasons. This post contains generalizations, and all generalizations have counter-examples. This post also refers to feelings, and humans often experience different feelings in response to similar stimuli, so yours might not be like mine.
It’s been a great “family reunion” of FOSS colleagues and peers in the OSCON hallway track this week. I had a conversation recently in which I was asked “Why did you choose ops as a career path?”, and this caused me to notice that I’ve never blogged about this rationale before.
I work in roles revolving around software and engineering because they fall into a cultural sweet spot offering smart and interesting colleagues, opportunities for great work-life balance, and exemplary compensation. I also happen to have taken the opportunity to spend over a decade building my skills and reputation in this industry, which helps me keep the desirable roles and avoid the undesirable ones. Yet, many people in my field prefer software development over operations work.
I’ve chosen, and stuck with, ops because it gives me the sensation of having better-defined success conditions than I get when developing code for others. When I tackle an ops problem, it is usually a task which I could tediously, miserably, but correctly perform by hand. This base case of “if all else fails, the desired thing can be done by hand” frames a problem more concretely and measurably than any written description of someone’s hopes and dreams about a piece of software.
Of course, performing ops tasks by hand does not scale. Often, the speed with which a given task is performed is part of its success criteria. And if you ask a human to perform the same task 20 times, you’ll likely get 21 subtly different outputs. This is why we automate: Automation brings computers’ strengths of speed and lack of boredom to the equation.
Automation tasks are necessarily framed in terms of the specific behaviors, described in technical terms, that computers are supposed to be performing. The constraints of the infrastructure provide a rigorously defined abstraction layer between psychology and code. This vocabulary of infrastructure expresses the constraints for ops work such that even if I’m not the end user of a piece of automation code, I can experience a high level of confidence that I understand what the person requesting it believed that they wanted when they made the request.
Automation is unlike software engineering tasks with success conditions that hinge on human emotions and behavior. Any success condition with psychology integral to it becomes time-consuming, if not impossible, to test against. Throw in psychological effects that incline a human to have slightly different reactions to the same thing depending on when and how you show it to them, and you lose even basic repeatability from the simple task of testing whether your code is “good enough”. For software engineering tasks with human behavior and emotions in their success criteria, I cannot consistently prove to myself that success is even possible. Although I enjoy recreationally tackling potentially-impossible challenges from time to time, I do not enjoy the pressure and uncertainty that come from betting my career and compensation on such puzzles.
Even systems built solely from understandable components develop complexity and challenges. Emergent behaviors arise, perhaps necessarily, from complex systems. In ops work, I feel a certainty that each component is independently predictable when broken down small enough, and that it would be possible with enough work to rebuild the entire system incrementally from such “atoms” of predictability. Of course it is almost never worth the time and effort to actually rebuild the system from scratch, but simply knowing that it would be possible gives me confidence that the problems I encounter with my systems can be solved. (To reiterate, “can be solved” bears little relation to “is worth solving”, but it does affect the way I feel about tasks.) Contrast this “certainty of solvability” to the problems encountered when developing software for other people: “the customer doesn’t like this!”, “users aren’t clicking where we want them to!”. Those problems hinge on human components that would usually be highly unpleasant, unethical, and illegal to disassemble and debug. Software problems tightly coupled to psychology do not make me feel like I can be certain that any amount of effort would guarantee a solution.
No workflow can, nor should, eliminate the bigger-picture questions about what we want to be building, or how we want to go about building it. However, I find that the
The Rust team is happy to announce a new version of Rust, 1.27.2. Rust is a systems programming language focused on safety, speed, and concurrency.
If you have a previous version of Rust installed via rustup, getting Rust 1.27.2 is as easy as:
$ rustup update stable
If you don’t have it already, you can get rustup from the
appropriate page on our website, and check out the detailed release notes for
1.27.2 on GitHub.
What’s in 1.27.2 stable
This patch release fixes a bug in the borrow checker verification of match expressions. This bug
was introduced in 1.27.1 with a different bugfix for match ergonomics.
fn transmute_lifetime<'a, 'b, T>(t: &'a (T,)) -> &'b T {
match (&t, ()) {
((t,), ()) => t,
}
}
fn main() {
let x = {
let y = Box::new((42,));
transmute_lifetime(&y)
};
println!("{}", x);
}
1.27.2 will reject the above code.
Concern over numerous patches to the match ergonomics feature
Users have expressed concern with the frequency of patch releases to fix bugs in the match ergonomics verification by the current borrow checker on a variety of Rust’s forums. There are two primary reasons for the increased rate of patch releases: significantly higher bandwidth and the age of the currently used borrow checker.
With the formation of the Release team, Rust’s ability to generate patch releases has greatly increased. This means that the investment from the compiler and core teams required to make a patch release is greatly reduced, which also makes such a patch release more likely to happen.
The current borrow checker has been around for years now, and is beginning to show its age. The work on a better, more precise borrow checker is underway, and it has detected all of these bugs. This work is planned to be stabilized in the next few releases, so expect to hear more about it soon.
Together, the lack of good maintenance on the current borrow checker and an increased capacity for releases make it feasible for us to ship patch releases on a more rapid and frequent basis.
As a large, complex, and heavily visited site, it can be challenge for our small team to make sure that extension users and developers have a good experience on addons.mozilla.org (AMO). Fortunately, we are not alone. Thanks to volunteer contributors who share their time, energy, and talent, we’re able to extend our ability to extend the web by fixing reported bugs, implementing routine updates, landing new features, and moderating content listed on AMO.
We’d like to acknowledge and thank the following community members for their contributions to AMO from April – June 2018.
addons.mozilla.org (AMO)
Last quarter, 19 community members submitted 68 patches to fix a variety of frontend and backend issues on AMO, like removing obsolete code, keeping the content on the Developer Hub up-to-date, making it easier for users to rate add-ons, and making sure the user interface stays tidy. Many thanks to community members Biskit1, Ankush Chadda, Deepanshu Jain, Dominic Lee, gabbyjose, Lavish Aggarwal, Manish Devgan, Piyush Mittal, Raffaele Spinelli, Revi, Sanyam Khurana, Sean Prashad, Shivam Singhal, Svitlana Galianova, Swarnava Sengupta, Trishul Goel, TwinProduction, Vimal Raghubir, and xu3u4 for their code contributions to improve AMO!
Extension & Theme Reviewers
No one enjoys coming across spam or unsavory themes while browsing AMO, or installing an extension that comes with a nasty surprise (like compromising user security). Our team of volunteer reviewers helps ensure that users have a good experience on AMO by moderating extensions and themes to make sure they comply with our Acceptable Use Policy and Add-on Policies.
We would like to extend a special thanks to this quarter’s top reviewers: erosman, rctgamer3, Ett Chung, B.J. Herbison, Jyotsna Gupta, happy-ferret, Pam, and candelora for their exceptional contributions to the review process during the last few months.
Community members contribute in many other ways to keep the add-ons ecosystem vibrant and strong. To learn more about these contributions, please visit our recognition wiki. To get involved, wiki for current contribution opportunities!
The post Thank you, contributors! appeared first on Mozilla Add-ons Blog.
Every day, countless Mozillians spend numerous hours testing Firefox to ensure that Firefox users get a stable and secure product. However, no product is bug free and, despite all of our testing efforts, browsers still crash sometimes. When we investigate our crash reports, some of them even look like lingering security issues (e.g. use-after-free or other memory corruptions) but the data we have in these reports is often not sufficient for them to be actionable on their own (i.e. they do not provide enough information for a developer to be able to find and fix the problem). This is particularly true for use-after-free problems and some other types of memory corruptions where the actual crash happens a lot later than the memory violation itself.
In our automated integration and fuzz testing, we have been using AddressSanitizer (ASan), a compile-time instrumentation, very successfully for over 5 years. The information it provides about use-after-free is much more actionable than a simple crash stack: It not only tells you immediately when the violation happens, but also includes the location where the memory was free’d previously.
In order to leverage the combined power of Nightly testing and ASan we have joined them together to form the ASan Nightly Project. For this purpose we made a custom ASan Nightly build that is equipped with a special ASan reporter addon. This addon is capable of collecting and reporting ASan errors back to Mozilla, once they are detected. We launched this project to find errors in the wild and then leverage the ASan error report to identify and fix the problem, even though it might not be reproducible. So far, we made these builds for Linux only, but we are actively working on Windows and Mac builds.
Of course this approach comes with a drawback: While ASan’s performance can almost compete with the performance of a regular build, its already higher memory usage grows the longer you run the browser as ASan needs to retain freed memory for a while in order to detect use-after-free on it. Hence, running such a build requires you to have enough RAM (at least 16 GB is recommended) and to restart the browser once or twice a day to free memory.
However, if you are willing to browse the web using this new Firefox environment, you might be eligible to earn a bug bounty: We will treat the automated reporter submissions as if they were filed in Bugzilla (with no test case) which means that if the issue is 1) an eligible security problem and 2) can be fixed by our developers, you will receive a bug bounty for it. All rules of the Mozilla Bug Bounty Program apply. If you would like to participate, ensure that you read the Bug Bounty section carefully and set the right preference, so your report can be attributed to you.
This project can only succeed if enough people are using it. So if you meet the current requirements, we would be very happy if you joined the project.
The post Introducing the ASan Nightly Project appeared first on Mozilla Security Blog.
https://blog.mozilla.org/security/2018/07/19/introducing-the-asan-nightly-project/
As the final part of Mozilla and the National Science Foundation’s Wireless Innovation Challenges, 14 community technologists will live demo their creative projects in Mountain View, CA this August
Across the U.S., community technologists are using creative ideas — like solar-powered Wi-Fi and mesh networks — to connect the unconnected. This August, Mozilla is gathering those projects under one roof for a science fair — and awarding $1.6 million in prizes to the most promising ideas.
The event is the final leg of the Wireless Innovation for a Networked Society (WINS) Challenges, a $2 million competition run by the National Science Foundation (NSF) and Mozilla. Launched in 2017, the initiative awards prizes to the people and projects who are connecting unconnected Americans with scalable, secure, and resilient solutions.
Mozilla and the NSF created the competition to address the U.S. digital divide. Some 34 million Americans — many of them located in rural communities and on Tribal lands — lack high-quality internet access.
The August 14 event, held at Mozilla’s Mountain View, CA headquarters, will run three hours and feature live demos plus Q&As with the 14 finalists. Finalists include a solar-powered LTE network, network infrastructure that fits inside a single backpack, connectivity for homeless shelters, and others. They hail from Cleveland, OH, Oakland, CA, Beatrice, NE, and beyond. (See the full list of finalists below.)
WINS judges — leading technologists and academics in the realm of wireless internet — will be present. The live demos will influence which projects are ultimately selected as winners in fall 2018. Two first-place winners will receive $400,000 each; two second-place winners will receive $250,000 each; two third-place winners will receive $100,000 each; and two fourth-place winners will receive $50,000 each.
“Every day, the internet becomes more vital to everyday life — it’s how we find jobs, learn, manage our finances, and communicate with family,” says Mark Surman, Mozilla’s executive director. “This means the 34 million Americans without reliable internet access are at a severe economic, educational, and social disadvantage. And it’s something we need to fix.”
“By investing in affordable, scalable solutions like these, we can unlock opportunity for millions of Americans,” adds Jim Kurose, head of the Directorate for Computer and Information Science and Engineering (CISE) at NSF.
The August 14 event will feature seven finalists from each WINS category: “Off the Grid Internet Challenge,” for projects that connect Americans in the wake of earthquakes, hurricanes, and other disasters, and “Smart Community Networks Challenge,” for projects that bring affordable, speedy internet access to underserved communities. The physical event is not open to the public, but we will be streaming the demos online.
In February 2018, Mozilla and the NSF announced the first batch of winners — $10,000 to $60,000 in grants for 20 promising design concepts. (See those winners here.)
THE FINALISTS
WINS Off the Grid Internet Challenge finalists
[1] Baculus | Baculus is a rolling backpack stuffed with off-the-shelf hardware and open-source software that helps community leaders know where to move to maximize Wi-Fi and cellular coverage. It can run independent of any other infrastructure for up to 72 hours. It is meant to be used year-round as a public Wi-Fi access point that also works when power, cell towers, and ISPs fail. Project Lead: Jonathan Dahan in New York; Design Lead: Ariel Cotton; learn more.
[2] Wind: Off-Grid Services for Everyday People | Wind uses Bluetooth, Wi-Fi Direct, and physical infrastructure nodes built from common routers to create a peer-to-peer network. The project also features decentralized software and a content distribution system. By the Guardian Project in New York; learn more.
[3] Project Lantern | A Lantern is a keychain-sized device that hosts decentralized web apps with local maps, supply locations, and more. These apps are pushed to Lanterns via long-range radio and Wi-Fi, and then saved offline to browsers for continued use. Lanterns can be distributed by emergency responders and are accessed by citizens through a special-purpose Wi-Fi network supported by the Lanterns. Project by
In June, Mozilla collaborated with an artist named Ian Brill to create an installation called the “Arch” at JSConf EU in Berlin. This interactive environment allowed people to experience the intersection of art and technology in a physical, pulsating, immersive way.
Visitors could view the larger-than-life Arch and experience an ever-changing light show of 30,000 colored LEDs. To support the exhibit, Mozilla engineers built a platform that enabled anyone to use web technologies (with underlying implementation in Rust & WebAssembly) to control the Arch animations and makes the light display interactive. The result was fun and colorful — and it gave developers a chance to interact with unfamiliar new technologies.
You may recall reading Lin Clark’s post about “Baby’s First Rust+WebAssembly module“. It gives an excellent overview of why we decided to create an art installation around Rust and WebAssembly. TL:DR: “Hello World” projects are fine, but this provides a fun and engaging way to learn something new.
JSConf recently posted the full video of Lin’s talk online. You can check it out below:
Additional Links:
Learn more about using Rust with Web
https://hacks.mozilla.org/2018/07/the-arch-using-rust-webassembly-to-animate-30k-colored-led-lights/
Did you know Firefox has a unique page full of great links and ideas curated just for you? In one simple click, we’ve made it faster and easier for you … Read more
The post Open Your Own Front Page Using Firefox New Tab appeared first on The Firefox Frontier.
https://blog.mozilla.org/firefox/open-your-own-front-page-using-firefox-new-tab/
It’s easy to make lots of mistakes with a new technology, especially something that’s as big of a change from the past as CSS Grid. In this video, I explain the 9 Biggest Mistakes people are making, with advice and tips for avoiding these pitfalls and breaking old habits.
For more information:
Mistake 1: Thinking CSS Grid is Everything
Flexbox vs. CSS Grid — Which is Better?
Using Flexbox & Grid Together
Obliterate Boxiness with CSS Shapes
Mistake 2: Using Only Percents for Sizing
Min & Max Content Sizing in CSS Grid
FR Units in CSS Grid
MinMax in CSS Grid
Mistake 3 : Assuming You Need Breakpoints
Incredibly Easy Layouts with CSS Grid
Mistake 4: Getting Confused by Numbering
Innovative & Practical Graphic Design with CSS Grid
Basics of CSS Grid: The Big Picture
Mistake 5: Always Using 12-columns
I talk about this towards the end of “FR Units in CSS Grid”
Mistake 6: Ignoring the Power of Rows
Flexibility & The Fold
Whitespace on The Web
Mistake 7: Reaching for a Framework
Mistake 8: Waiting for IE11 to Die
Internet Explorer + CSS Grid?
7-part Series on Writing Resilient CSS that works in all browsers
Mistake 9: Hesitating, Instead of Playing
Responsive Mondrian
CSS Grid like you are Jan Tschichold
https://hacks.mozilla.org/2018/07/9-biggest-mistakes-with-css-grid/
The decision by the European Commission today to sanction Google for practices regarding the Android mobile operating system drives home the importance of true openness in the mobile ecosystem. These are complex issues, and we expect that we will be evaluating the remedies and their repercussions for some time. We are hopeful the result will help level the playing field for mobile browsers like Firefox, and to foster openness that creates and sustains competition and innovation.
For Mozilla, these issues of innovation, openness, and competition speak to our history. Twenty years ago, we made Firefox to combat the vertical integration of Microsoft Windows and Internet Explorer. Today, we are again witnessing vertical integration concerns on a larger scale, with powerful players at all parts of the internet ecosystem. Mozilla’s 2018 Internet Health Report identified decentralization as a major goal to promote a healthy internet.
Targeted, effective interventions can strengthen technology markets and are necessary to advance consumer welfare. Mozilla will continue to build competitive products and to advocate for effective policies and approaches to build a competitive and open technology ecosystem.
The post Mozilla Responds to European Commission’s Google Android Decision appeared first on The Mozilla Blog.
It brings us great sadness to share with you the recent news about one of our dear Rep we will so fondly remember. Abbackar DIOMANDE from Ivory Coast is unfortunately no longer with us.
Diomande, was a Mozillian from Bouake, Ivory Coast and was contributing in various Mozilla projects including SUMO and L10n.
He was a local community builder, that helped to build a healthy local community in his country while lately he had also taken the role of a Resources Rep, helping his fellow Mozillians on organizing local initiatives.
[252x448]
His passing is finding us sadden and shocked. His contributions helped our community intensively and while we have a heavy heart, we know that his passion and inspiration will sustain with us.
Our condolences to his family and friends.
Bellow are some words about Diomande and his work from his community members in French
Puisse Dieu t’accueillir dans son royaume Diomande. Mes Condol'eances `a toute la famille.
Diomand'e a 'et'e un de mes meilleurs mentor'es, il a aim'e et est toujours rest'e fan de Mozilla , avec le coeur il a su toujours selon sa facon conduire sa passion pour Mozilla.
Tu n’a pas souffert, que la terre te soit l'eg`ere et tu puisse trouver la paix. Repose en paix Diomand'e.
Mes condol'eances `a toute ta famille, tes amis qui t’aimaient et toute la famille Mozilla.Rip Cher ami , le passage est obligatoire , Puisse Dieu te reserver un acceuille c'eleste digne de tes apports volontaires , Mozillians from Pigier
Courage, oui grand courage `a la famille, un genie ne meurt jamais. Abbackar n’est pas mort, il nous attend juste de l’autre c^ot'e de la rive. Abbackar n’est pas mort, Abbackar vivra toujours.
Diomand'e 'et'e un des contributeur de Mozilla, `a travers tous ses ateliers ou actions men'ees pour la communaut'e, ses traces resterons `a jamais, elles continueront de parler de lui. Je retiens `a lui, un grand homme plein de valeurs, son 'epoque sera marqu'e par des traces ind'elibiles. ( Wilfried N’Guessan )
Diomand'e 'etait un bosseur, un battant qui a aim'e trop le d'eveloppement d’applications. Il a propos'e des solutions innovantes . Mes respects pour chaque bonne action qu’il a fait pour ce monde. (Ange Bagui)
Un MozBoy est pati. Un arbuste qui avait toutes les aptitudes pour devenir une grande arbre avec de grande branches et un gros spectre d’ombre. La communaut'e a perdu un v'eritable passionn'e. YAKO A TOUS !!!
Cher ami, c’est avec les larmes aux yeux et une grande tristesse que je redige cette note. Tu vas nous manquer!
https://blog.mozilla.org/mozillareps/2018/07/18/in-loving-memory-of-abbackar-diomande/
We are excited to announce that Mozilla is partnering with Women Who Tech on the Women Startup Challenge Europe. Mitchell Baker will be one of the in person judges evaluating the startup finalist pitches and Mozilla will award a $25,000 grant to the startup focused on building privacy, transparency and accountability into their work.
The Women Startup Challenge Europe will connect women technology innovators from cities across Europe to compete for $60,000 in cash grants. In addition to the funding, all finalists will also receive: pitch coaching, one on one meetings with investors the day after the Women Startup Challenge, and other crucial startup friendly services. The Startup Challenge, co-hosted by the Office of Paris Mayor Anne Hidalgo, will feature 10 finalists pitching their ventures before a panel of judges on October 25, 2018 at Paris H^otel de Ville.
Women Who Tech is a nonprofit organization on a mission to close the funding gap and disrupt a culture and economy that has made it incredibly difficult for women entrepreneurs to raise capital. At Mozilla, we are committed to an internet that catalyzes collaboration among diverse communities working together for the common good. Promoting diversity and inclusion is core to our mission, so working with organizations like Women Who Tech furthers our commitment to create more diversity in innovation.
“I’m looking forward to meeting the best early stage women-led startups from across Europe and highlighting the startup most focused on building privacy, transparency and accountability into their work,” said Mitchell Baker, Mozilla Chairwoman and Co-Founder. “Recent research shows only 12 percent of founders at EU companies that received VC funding in 2017 are female, so I hope challenges like this will create more opportunities for a diverse future of entrepreneurs.”
The post Mozilla Partners with Women Who Tech to Offer Startup Challenge Europe Award for Privacy, Transparency & Accountability appeared first on The Mozilla Blog.
As we announced last week, SeaMonkey and Thunderbird add-ons will now reside on https://addons.thunderbird.net. Add-ons for Firefox and Firefox for Android will remain on https://addons.mozilla.org (AMO). We wanted to let you know that the split is now done and the new site is live.
If you run into any issues on the new site, you can file them here. For AMO, use this link instead. We’ve also set up an FAQ on the Mozilla Wiki explaining the reasons behind this move and providing some guidance for people looking for help on it.
The post The New Thunderbird Add-ons Site is Now Live appeared first on Mozilla Add-ons Blog.
https://blog.mozilla.org/addons/2018/07/17/the-new-thunderbird-add-ons-site-is-now-live/
Today, Representative Mike Coffman (R-CO) took two important steps towards protecting net neutrality. First, he’s signing the discharge petition that could force a vote on the Congressional Review Act (CRA) that negates Chairman Pai’s disastrous rollback of net neutrality protections. But he’s going a step further, too: he announced a bill that would codify net neutrality in law. The bill is straightforward: it bans blocking, throttling, and prioritization with clear authorization for FCC rulemaking and enforcement. Both of these actions are important, all the more so because Rep. Coffman has recognized that protecting net neutrality isn’t a partisan issue. This is an issue that the vast majority of Americans agree on, which makes it all the more confusing that it has become a partisan issue in Washington.
Mozilla has been working for a decade to protect net neutrality in the U.S. and around the world. Around the world, including in India, Europe, and Latin America, net neutrality policies are being adopted while the U.S. is moving backwards. We were saddened that Chairman Pai chose to roll back strong consumer protections in order to advance a partisan agenda, especially when survey after survey makes it clear that the vast majority of Americans want net neutrality protections to ensure that their ISPs aren’t quietly discriminating against their favorite services
Rep. Coffman joins Sen. Murkowski, Sen. Kennedy, and Sen. Collins – who similarly moved to protect their constituents access to the entire internet by voting for the CRA in the Senate. We hope that more Republicans listen to their constituents and move to protect net neutrality.
The post A bipartisan step for net neutrality appeared first on Open Policy & Advocacy.
https://blog.mozilla.org/netpolicy/2018/07/17/a-bipartisan-step-for-net-neutrality/
As we all know, measuring things is a good way to get concrete information. Now that Firefox CI is fully on Taskcluster this was a good opportunity to measure and see what we can learn about timing in localization tasks.
The code that generated the following charts and data is viewable in my Github repo, though as of this writing the code is rough and was modified manually to help generate the related graphs in various configurations. I’m working on adjusting them to be more general purpose and have better actual testing around logic.
One of the first things I looked at was per-task duration for the actual nightly-l10n task on beta/release by Gecko version per platform. [Note: Android is missing on these graphs because we do not do Android Single Locale on Beta/Release anymore, so we don’t have metrics to compare] (graphs and takeaways after the jump)
With this graph, it is clear both, that we made some general improvements between Gecko 59 and Gecko 60, and that Windows takes significantly longer than OSX/Linux (both of the latter are performed on linux hosts).
Nothing in this graph was all that surprising to me, and it meshed with my preconceived understanding of the current state.
Next I was wondering if the data would be different if I split the tasks down to “per locale” timing because the number of locales run in a single task, while roughly uniform for a given release could vary from release to release, especially as we add new locales or change chunking values, etc.
This was interesting in that it shows the per locale time is amounts to just a bit under 10 minutes per locale for linux, and at least double that for windows, and it appears there is a slight regression for windows on beta, but with the variability in earlier windows tasks it’s hard to conclude much (though we did reduce some of that variability in 61/62 releases)
Now over to the Nightly side of things to look closer, I realized that using plot.ly public charting wouldn’t let me do the nightly graphs for all platforms at once (too many data points!) I resorted to a bit of back and forth locally. But eventually made a full-nightly graph of all windows, split by week, per task. [This eventually was able to publish to plotly public api]
With this one you’ll notice the obvious task regression near the end of 2017 and the smaller one near the end of the Gecko 62 cycle…
I spent a bit of time, and looked into what happened at the end of 2017, but turns out this wasn’t really a regression so much as a stabilization. Prior to that, we had done 2 locales per task to work around some signing timing issues we hit early in the tc-migration work, and decided it was ok to bump to ~5 locales per task. This, of course, bumps our per-task time up relatively significantly, however as you can see on my next graph, it doesn’t actually change the real metric much… (per Locale graph)
Unlike the first regression (end of 2017), the “just before Gecko 62” regression is still present in this graph. In offline mode (sorry no plotly link for these) I dug in deeper to see what could be causing this… (the following Graph has all platforms as my own mini sanity check)
Once I did some data-mining on my raw data, I found the changesets and taskIDs involved and traced it down to an actual regression in hg clone/update times, and filed Bug 1474159. That resulted in the OCC (Open Cloud Config) Pull Request that is currently awaiting landing and deployment.
If I had to take one thing away from this mini exercise is that there is certainly value in doing these types of graphs, (and more)
Firefox is available in over 90 languages, giving millions of people around the world access to the web in words they understand. Our community of translators and localizers do this … Read more
The post Popular Firefox extensions now available in 7 new locales appeared first on The Firefox Frontier.
https://blog.mozilla.org/firefox/popular-firefox-extensions-now-available-in-7-new-locales/
You might have noticed that while Firefox supports 90 languages, many extensions and their listings on addons.mozilla.org (AMO) are only available in English.
At present, we don’t have a way to connect extension developers with the translation community at scale, and Pontoon, Mozilla’s tool for localizing products and websites, currently only supports translating the AMO site itself.
What we do have, however, is a desire to make translation resources available, a longstanding and active community of localizers, and friends on Mozilla’s Open Innovation team who specialize in putting the two together. Part of Open Innovation’s work is to explore new ways to connect communities of enthusiastic non-coding contributors to meaningful projects within Mozilla. Together with Rub'en Mart'in, we ran a campaign to localize an initial group of top Firefox extensions into the 7 most popular languages of Firefox users.
More than 100 multilingual Mozillians answered the call for participation and submitted more than 140,000 translated words for these extensions using CrowdIn, a localization platform most recently used for Mozilla’s Common Voice project. These translations were reviewed by a core team of experienced localizers, who then provided approved translations to developers involved in the campaign to include in their next version update.
Now, you can enjoy this collection of extensions in Chinese (simplified), Dutch, French, German, Italian, Portuguese (Brazilian), and Spanish:
1-Click Youtube Download* · Adblock for Firefox · Download Flash and Video
Greasemonkey · New Tab Override · NoScript Security Suite
Pinterest Save Button · signTextJS plus · To Google Translate
While this campaign is limited to a small group of extensions, we hope to roll out a localization process for all interested extension developers in the near future. Stay tuned for more information!
If you would like to participate in future campaigns at Mozilla, subscribe to Mission-Mozillians-Campaigns tag on Discourse to learn how to get involved. If you are specifically interested in localizing other content for Mozilla, check out the L10n wiki to learn how to get started.
Many thanks to the extension developers and localizers who participated in this campaign.
* Coming soon! If you would like a localized version of this extension in one of the languages listed above, install the extension now. During its next update, you will be automatically switched to the version for your locale.
The post No Longer Lost in Translation appeared first on Mozilla Add-ons Blog.
https://blog.mozilla.org/addons/2018/07/16/no-longer-lost-in-translation/
This blogpost was authored by Daniele Scasciafratte
What we have done
In the first half of the year, our focus was to align the program with Mission Driven Mozillians and prepare the mandatory Reps onboarding course to ensure it aligns with the D&I work. We have also started improving the understanding of issues of different Reps roles like Mentors and Alumni.
We also worked on administration issues like the transition of inactive Reps to Alumni, the cleanup of old Reps applications still open after years and wrong mentors assigned to profiles and the improvement of our reporting system. Last but not least, we moved to the creation of expertise teams that took over everyday work day tasks from the Council (newsletter and onboarding).
We’ve chosen to split our ideas and tasks in 3 different areas for the next half of the year (with percentage):
- Prepare the ground for Mission Driven Mozillians: 45%
- Visible wins: 45%
- Miscellaneous: 10%
Prepare the ground for Mission Driven Mozillians
The Reps program is working to prepare the ground for Mission Driven Mozillians and there are different tasks and issues to face for that.
The most important point for the Reps Council is the Roles of Reps inside the communities. We know that in Mozilla there are a lot of international communities, local community and project specific communities, and we need to understand and be ready to support all of them.
We gathered different ideas that we will investigate soon:
- Role of Reps
- Update all the Reps about the last updates of the Mission Driven Mozillians program
- Understanding and agreement on Leadership Agreement
- Start conversations on where Reps belong/Reps Role
- We are already working on:
- Restart Newsletter with a new team
- Discussion about migrating the Reps mailing list to Discourse
- Create courses for various roles
- Review Team and Mentors already have a course
- We are working on a new onboarding course
- Skills criteria for various roles
- Every role has a skillset and we are working to improve them as requirements
- Update all the Reps about the last updates of the Mission Driven Mozillians program
- Mozilla Groups (MDM)
- How they fit inside the Reps program
- This is an experiment and we need to understand how the program can fit to be part of this initiative
- How they fit inside the Reps program
- Onboarding
- New SOPs for various roles/teams
- We updated SOPs in the past and we need to define where we need to update them
- Courses inside the program
- Few roles have courses but for Reps we need to define if we can do general courses or if we can find them already available
- CPG Alignment (update the Reps with updated CPG information, add it as mandatory part to the onboarding course)
- New SOPs for various roles/teams
Visible wins
The program also needs to be more visible inside Mozilla and the others communities, so we’ve chosen to focus on 3 different areas:
- Communication
- Discover new areas where Reps are missing
- There are a lot of communities where we don’t have a large representation or there is no interest
- Reps news to all Mozilla
- Share what Reps are doing, for example during the Weekly Monday Project Call
- Discover new areas where Reps are missing
- Statistics
- Showcase events inside Mozilla
- Improve the sharing of statistics about what volunteers are doing
- Showcase events inside Mozilla
- Campaigns
- Plan for more than 3 weeks out
- Let the community be aware of a new campaign in advice
- Pocket involvement
- Part of Mozilla but there is no involvement of volunteers right now
- Create an event asset repository
- Events often require the same resources such as graphics or links, we need to gather them
- Plan for more than 3 weeks out
Miscellaneous
The last area that we chose are the miscellaneous ideas, something that does not block the program’s goals but can improve it, at the same time this has low priority:
- Improving mentee/mentors relationship
- Improving understanding of Alumni role
- Improve reps-tweet social usage
- Style guidelines for the community
- Reporting activities
- Encourage Reps to report activities
- Without reports it’s difficult to do data-driven decisions
- Understand issues Reps face with reporting
- Encourage Reps to report activities
This list of ideas will be evaluated in the next quarters by the Council and as usual we are open to feedback!
I read the news of Guido van Rossum announcing his retirement as BDFL of Python and it made me a bit sad.
I've been programming in Python for almost 20 years on a myriad of open source projects, tools for personal use, and work. I helped out with several PyCon US conferences and attended several others. I met a lot of amazing people who have influenced me as a person and as a programmer.
I started PyVideo in March 2012. At a PyCon US after that (maybe 2015?), I found myself in an elevator with Guido and somehow we got to talking about PyVideo and he asked point-blank, "Why work on that?" I tried to explain what I was trying to do with it: create an index of conference videos across video sites, improve the meta-data, transcriptions, subtitles, feeds, etc. I remember he patiently listened to me and then said something along the lines of how it was a good thing to work on. I really appreciated that moment of validation. I think about it periodically. It was one of the reasons Sheila and I worked hard to transition PyVideo to a new group after we were burned out.
It wouldn't be an overstatement to say that through programming in Python, I've done some good things and become a better person.
Thank you, Guido, for everything!
http://bluesock.org/~willkg/blog/dev/python/guido_retiring_bdfl.html