With the release of Firefox 47, we are pleased to welcome the 41 developers who contributed their first code change to Firefox in this release, 33 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:
We’ve been looking for the right home for Firefox browser development Q&A for a while now. It’s taken longer than it should have, but after a lot of discussion and experimentation with different tools and forums, we’ve finally come to a conclusion.
In retrospect the decision was obvious; hindsight is like that. But here it is; if we want everyone in the community to be a part of making Firefox great, then we should be where the community is: part of the Mozilla Community Discourse forum.
Things are a bit thin on the ground there now; I’ll be migrating over some questions and answers from other forums to stock that pond shortly. In the meantime if you’re new to Discourse it’s a very civilized piece of forum software. You can keep track of discussions happening there by logging in and taking a look in the upper right-hand corner, where you’ll see “Watching”, “Tracking”, “Normal” and “Muted”. Set that to “Watching”, and you’ll get a notification when a new topic comes up for discussion. Set it to “Tracking”, and you’ll also get a note when you’re called out by name. You can also watch or track individual threads, which is a nice touch.
Alternatively, if you’re a fan of syndicated feeds you can grab an Atom feed as follows:
I hope you’ll join us in helping build Firefox into everything it can be, the best browser in the world and the cornerstone of a free, open and participatory Web. And as always, if you’ve got questions about that, please email me directly.
This post was written by Fauzan Alfi.
It was not an ordinary Friday 13th for Mozilla Indonesia because on May 13th, 2016, it was a very big day for us. After months of planning and preparation, the Mozilla Community Space Jakarta finally launched and opened for the community. It’s the 4th volunteer-run physical community space after Bangalore (now closed), Manila and Taipei and another one is opening soon in Berlin. Strategically located in Cikini – Central Jakarta, the Space will become a place for Mozillians from Greater Jakarta and Bandung to do many activities, especially developer-focused events, and to build relationships with other tech communities in the city.
Invited to the event were many open source and other communities around the city. Mozilla Reps, FSAs and Mozillians also joined to celebrate the Space opening. On his presentation, Yofie Setiawan (Mozilla Rep, Jakarta Space Manager) hopes that Jakarta Community Space can be useful for many people and communities, especially to educate anyone who comes and joins events that take place in the space.
Also joining the event, Brian King from Participation Team at Mozilla. During his remarks, Brian said that the reason behind the Jakarta Community Space is because “the Mozilla community here is one of the most active globally, with deep roots and a strong network in tech scene”. He also added that “Indonesia is an important country with a very dynamic Web presence, and we’d like to engage with more people to make the online experience better for everyone.”
The Jakarta Community Space is around 40 square meters in area that fits 20-30 people inside. On the front side, it has glass wall that’s covered by frosted sticker with some Mozilla projects wording printed on it. Inside, we have some chairs, tables, home theater set, food & drink supplies and coffee machine. Most of the items were donated by Mozillians in Jakarta.
One area where the Jakarta Community excelled was with the planning and design. All the processes are done by the community itself. One of Reps from Indonesia, Fauzan Alfi – who has a background in architecture, helped design the space and kept the process transparent on the Community Design GitHub. The purpose is to ignite collaborative design, not only from Indonesian community but also from other parts of the globe. More creativity was shown by creating mural drawings of landmarks in selected cities around the world – including Monas of Jakarta.
Jakarta Community Space means a lot for Mozilla community in Greater Jakarta and Indonesia, in general. Having a physical place means the Indonesian community will have their own home to spread the mission and collaborate with more communities that are aligned with Mozilla, especially developer communities. Hopefully, the Space will bring more and more people to contribute to Mozilla and help shape the future of the Web.
Re-post from George Roter’s blog, “Reinventing Mozilla on Campus” .
Throughout history, University students, staff and professors have often shaped the leading edge of change and innovation. The history of the web is no different: the student-built Lynx browser was one of the first and Mosaic (Firefox’s distant ancestor!), pioneered by students and staff, opened the graphical web to millions.
I saw the impact that students and professors can make through my own experience at Engineers Without Borders Canada. Engineering students and professors on campuses across Canada and in Africa built remarkable ventures, reshaped curriculum, changed on-campus and government policy, and taught hundreds of thousands of young people about global development.
I fully believe in the potential of students, staff and professors on campuses around the world to have massive impact on Mozilla’s mission. As innovators, contributors and open web advocates. Engineers, scientists, lawyers, social scientists, economists and designers.
From what I know about my past experience and have heard in the past year working for Mozilla, our mission resonates tremendously with students and professors. The range of impact and involvement is considerable. Until now, we’ve only just scraped the surface of this potential.
We need to reinvent Mozilla on campus.
Our existing engagement on University campuses around the world is an assortment of largely disconnected programs and people. Firefox Student Ambassadors and Firefox Clubs. Mozilla Clubs. Code contribution by individual contributors. Maker Party. Mozilla Science Lab. Various professor and lab partnerships. Employee recruitment. Many of these are successful in their own right; there’s an opportunity learn from each of them, find connections, and imagine opportunity to scale their impact with a more coordinated approach.
Photo credit: Tanha Islam and Trisa Islam
The largest of these by student involvement, Firefox Student Ambassadors (FSAs) and Firefox Clubs, has been constrained by limited and variable employee support and a focus on marketing. Our student leaders have already been “hacking” this program to introduce advocacy, code contribution, support, localization, teaching and many other activities; official support for this has lagged.
Our team came into this year with a key hypothesis as part of our strategy: That we can supercharge participation with a reinvented campus program.
The Take Back the Web campus campaign focused on privacy and security has been our first effort to test this hypothesis. Already it’s showing great promise, with over 600 campus teams signed up (including hundreds of FSAs) to have impact in 3 areas. We’re focused on learning as much as we can from this campaign.
The campus campaign is a step toward reinvention. But I think it’s now time to take a step back to ask: What impact can we imagine with a coordinated effort on campuses around the world? What do students, staff and professors want and need to be involved with Mozilla’s mission? How might we evolve our existing programs? What programs and structures would we design, and how do they relate to one another? How can we invite people on campus to innovate with Mozilla?
These are the broad questions that will guide a process over the next 9 weeks. By July 15th we aim to have a clear articulation of the impact we can have, the programs we’ll invest in and how they relate to one another, and the opportunities for students, staff and professors to participate.
We’re hoping that this process of reinventing Mozilla on campus will be participatory, and we’re inviting many voices to contribute. Lucy Harris on the Participation Team will be stewarding this process and shaping the final options. Mark Surman, Mitchell Baker, Chris Lawrence, Katharina Borchert and I will be involved in making a final decision on the direction we take.
You can read more about the details of the process in this post, but let me summarize it and the opportunities you have to be involved:
Phase 1: Listening (May 16-27)
→ provide thoughts on existing programs and opportunities you see
Phase 2: Synthesis and options (May 27-June 10)
→ we’ll frame some tensions for you to weigh in on
→ we’ll shape a set of options for conversation during the London All Hands
Phase 3: Final input (June 10-24)
→ we’ll articulate a set of options for you to consider as we move forward, and will be diving deep into these and key questions during the Mozilla All Hands in London
Phase 4: Final Decision and Disseminate (June 24-July 15)
→ we’ll take all the input and decide on a direction for moving forward
Let me finish by reiterating the opportunity. University campuses are a hotbed of innovation and a locus for creating change. Mozilla can tap into this energy and catalyze involvement in unleashing the next wave of openness and opportunity in online life. Finally, our team is excited about helping to shape a direction we can take, and investing in a robust program of participation moving forward.
I’m excited for this journey of reinventing Mozilla on campus.
With the release of Firefox 46, we are pleased to welcome the 37 developers who contributed their first code change to Firefox in this release, 31 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:
- chikoski: 1179627
- leper: 1236373
- sakshivaid95: 1207185
- simon: 1231806
- AJ Kerrigan: 1132556
- Abdulla Alkaabi: 1219920
- Alex Jordan: 1106353
- Andy McKay: 1214007
- Brad Kotsopoulos: 1228676, 1239488
- Brendan Good: 1111701
- Brian Armstrong: 987186
- Brian J Murray: 1232486
- Bryce Van Dyk: 1239096
- Daniel Vucci: 1236864
- Giorgio Maone: 1215197
- Gordon Su: 1214169
- Haik Aftandilian: 1232374
- Jacobo Aragunde Pérez: 939496
- Julian Descottes: 1157469, 1198326, 1214177, 1224201, 1238467, 1238639, 1238941, 1239670, 1239673, 1239730, 1240344, 1240368
- Kartikey Agrawal: 1234131
- Kevin Atkinson: 1238031
- Louis Christie: 524109, 864780
- Mohamed Hammoud: 1156252
- Nico Grunbaum
- Phil Booth: 1227527
- Ross Lovas: 1190093
- SUN Haitao: 1234544
- Samuel Mendes: 1228037
- Shakthi Wijeratne: 1232669
- Shane Tomlinson: 1233668
- Shivin: 1197163, 1207273
- Shruti Jasoria: 1097676
- Thomas Kuyper: 1184550
- Tim: 1164569
- Tony Mechelynck: 1236937
- Wilmer Paulino: 1237668
- Ya-Chieh Wu: 1216148
- raunaqabhyankar: 1149780, 1164307
Over the past few months you might have heard about a growing community called the Community Design Group. What sets this group apart from many of the other communities at Mozilla is that it does not exist in a region, club, or wiki page. It has only the loosest “membership” and you can come, participate, and leave without ever sharing your name.
The Community Design Group is a sort of transactional marketplace that lives primarily on GitHub. Requests for design can be made by contributors and staff, likewise anyone can tackle or contribute to any design problem that emerges into the Repo.
As Elio Qoshi, the community-side driver of the Community Design Group writes in his blog post:
This allows for a quick contribution path for new contributors in a decentralized manner. Different labels determine what kind of context issues have, neatly sorted in UX, IX, UI and general Graphic Design, to allow contributors from various backgrounds to jump in.
Since it’s inception in mid-January 25 design problems have been closed ranging from the design of full websites, logos, and style guides. In the past 30 days alone the Repo has received over 2,000 views and 1,000 unique visitors and it exists and flourishes with only minimal staff and community-leader involvement.
Despite this early success there is still a great deal to be learned about this model. One of the early realizations about the Community Design Group was the tendency of the community to focus on the creation of logos. These fun and creative projects are excellent opportunities for designers to show their skills and learn from each other, but could potentially dilute the already somewhat crowded logo-sphere of Mozilla.
Rather than put any stop-energy into the community, we are experimenting with sharing more high-impact opportunities for contribution, initially in the form of a challenge related to the re-branding of Mozilla. In this challenge we’re asking the design community to suggest a new iconic symbol for Mozilla that will shape the thinking of the Creative Team.
In contrast to the well-defined, quick victory, of logos this challenge is ill-defined and complex.
This challenge will close at the end of April and we will have the opportunity to see not only what emerges from the creative pool, but how this work is integrated into the work of the staff team.
The basis of the Community Design Group project was to see what would come of a simple place with minimal rules, where a decentralized community could come to share and create. It is a testament to the power of minimal restriction and functional tools. Over the next quarter I look forward to seeing how far it will grow, and what amazing contributions will emerge from this new community.
A wave of new contributors have been asking how they can help Firefox without (necessarily) having strong coding skills, and just at the right time. I’m writing this because Firefox engineering needs exactly that kind of help, right now.
There are a lot of ways you can help Firefox and the Mozilla project, and most of them don’t involve writing code at all. Living in our nightly builds of Firefox is a big deal, and using the Beta release of Firefox on Android, if you happen to be an Android user, helps improve the mobile experience as well.
There’s a lot that needs doing. But one thing we’re really looking for – that Firefox engineering could use your help with today – is bug triage and component ownership.
Developing Firefox in the open with a user base of our size means we get a lot of bug reports. A lot. Hundreds every day, and they come in all shapes and sizes. Some of them are clear, tightly-scoped reports that come with clear steps to reproduce, and those are great. Others are a vaguely-described, hard-to-interpret mess. Most of them are somewhere in between, real problems that are difficult to act on.
Whatever condition these bugs arrive in there’s always a passionate Firefox user behind them with a real problem they care about solving. We know that Bugzilla is not an easy mountain to climb; to respect those users’ efforts we want to give all our incoming bugs enough care and attention to get them from “a user has a problem with our product” to “an engineer has the information they need to make the right decision.”
This is where you come in.
We know what makes a bug a capital-G, capital-B Good Bug from an engineering standpoint – It’s assigned to the right component, it’s steps to reproduce or a regression range if it needs them, and its clear what the next steps are and who needs to take them. For the most part getting bugs from “new” to “good” doesn’t mean writing code – it’s all about organization, asking questions, following up and making sure things don’t get lost.
This kind of work – de-duplicating, cleaning up and clarifying where these bugs are and what’s next for them – is incredibly valuable. We’ve had a handful of people take up this work in the past, often growing into critical leadership roles at Mozilla in the process, and its hard to overstate how much their work has mattered to Mozilla and driven forward the Open Web.
We need people – we need you – to help us keep an eye on the bugs coming to different components, sort them out and ask the right questions to get them into actionable shape. This may seem like a big job, but it’s mostly about organization and persistence.
In the beginning just setting the right flags and ask some questions will help. As you gain experience you’ll learn how to turn unclear, ambiguous bug reports into something an engineer will be excited fix. In the long term someone who really knows their component, who can flag high-priority issues, clean them up and get them to the right engineers, will have an dramatic impact on the product, helping Mozilla make Firefox and the Web better for hundreds of millions of users.
You don’t need much more than a bugzilla.mozilla.org account and a computer than can run Firefox Nightly to get started. If you’ve got that, and you’re interested in taking this up, please email me so that we can match you up to one of the components that needs your help.
Thank you; I’m looking forward to hearing from you.
In 1968, Martin Conway noted that “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”
Today that’s called Conway’s Law, and to quote Wikipedia:
“The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.”
Like any metaphorically double-edged sword, Conway’s Law is either a dangerous hazard or a powerful tool; it all depends on which end you grab.
Over the last few months the Firefox Desktop Engineering team has been refining a two-week onboarding program for engineers who’ve recently joined Mozilla. Firefox is a big project with a long history and like Mozilla (and like the Web we’ve made) the codebase and the processes around it can be as clean, streamlined and brilliant in some places as they are confusing and weirdly baroque in others.
One upshot of that is that even for full-time employees it can be hard to know where to start.
So for the last few months we’ve planned and run a series of training sessions. The’re aimed at new Firefox Desktop engineers, to help get them from New-To-Mozilla to Awesome-At-Mozilla as quickly as possible. And they’ve been very successful, not just for new hires, but for veterans and people who work with engineers as well.
But we pride ourselves on working in the open, and we’d like you to be Awesome At Mozilla too. So we’ve put them on Air Mozilla.
Here’s Nick Alexander, taking people through their first Firefox build and bugfix in the Build And Go session:
(Video compression is incredibly unforgiving, when it comes to text. We’re working on that for our next round.)
Other sessions include an introduction to Bugzilla, JS and the DOM, C++ and Gecko, Architecture & Product and more. They’re available on Air Mozilla, in the Onboarding channel, and more will be added as we record them.
If you’re interested in learning about the nuts and bolts of how Firefox is built, structured and shipped, take a look.
With the release of Firefox 45, we are pleased to welcome the 38 developers who contributed their first code change to Firefox in this release, 30 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:
- giles: 1222537
- sjw: 1216654
- steinbrecher.johann: 1211656
- vnicolas: 1212321
- Adam Farden: 1227544
- Alex Johnson
: 1106903, 1210989, 1216051, 1220556, 1228414
- Andi-Bogdan Postelnicu: 1192982, 1226549, 1227119, 1227481, 1228339, 1228342, 1228346, 1228497, 1228510, 1230106, 1230118, 1230135, 1230149, 1230902, 1230929, 1230939, 1231107, 1231124, 1231309, 1231633, 1231635
- Andrew Krawchyk: 1124185, 1173583
- Andrzej Hunt: 1219819
- Andy Chen: 1225566, 1225590
- Chih-Yi Leu: 1227030
- Chris H-C: 506815, 1107782, 1163971, 1198196, 1198209, 1211599, 1220376, 1222044, 1223800, 1228435
- Eduard Hanu: 1210879, 1218189, 1218746, 1218870, 1220193
- Harshit Bansal: 1216955, 1220080
- Hugo: 1198073
- Johan Lorenzo: 1226581
- Jomy: 1169884
- Jordan Lund: 1220763
- Julian Hector: 1215303
- Luís Miguel: 1198465, 1228980
- Madhurima: 1197313
- Matt Coles: 558566
- Michael Bebenita: 696630
- Nicholas Parkanyi: 1223652
- Nicholas Parmar: 842356
- Nicolas Chevobbe: 1225236
- Pablo Almenar: 770156
- Patrick: 1217458
- Paul Bignier: 1188186
- Penh Lenh: 1223018
- Stuart: 1224135
- Sunny Sidhu: 1210563, 1220873, 1224196, 1225782
- Tom Zhang: 1223423, 1225103
- Varun Joshi: 1203345, 1214811
- Vidhuran Harichandra Babu: 1227105
- chaithanya: 1226178
- huangwenjun06: 1218681
- jignesh: 1216704
- philipp: 1222819
With the release of Firefox 44, we are pleased to welcome the 28 developers who contributed their first code change to Firefox in this release, 23 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:
- mkm: 1208124
- Aditya Motwani: 1209087
- Aniket Vyas: 1197309, 1197315
- Chirath R: 1216941
- Christiane Ruetten: 1209091
- Fernando Campo: 1199815
- Grisha Pushkov: 994555
- Guang-De Lin: 1150305
- Hassen ben tanfous: 1074804
- Helen V. Holmes: 1205046
- Henrik Tjäder: 1161698, 1209912
- Johann Hofmann: 1192432, 1198405, 1204072
- Kapeel Sable: 1212171
- Manav Batra: 1202618, 1212280, 1214626
- Manuel Casas Barrado: 1172662, 1193674, 1200693, 1203298, 1205684, 1212331, 1212338, 1214582
- Matt Howell: 1208626
- Matthew Turnbull: 1213620
- Olivier Yiptong: 1210936, 1210940, 1213078
- Piotr Tworek: 1209446
- Rocik: 1070719
- Roland Sako: 1207733
- Ronald Claveau: 1207266
- Sanchit Nevgi: 1205181
- Shaif Chowdhury: 1185606, 1208121
- Shubham Jain: 1208470, 1208705
- Stanislas Daniel Claude Dolcini: 1147197
- Stephanie Ouillon: 1178533, 1201626
- Tim Huang: 1181489
- simplyblue24: 1218204