i’m now over 10 Years a Mozillian and Part of the Mozilla Community (and now about over 6 years employee at Mozilla) and it still rocks.
I’m sure everyone involved into Mozilla has his own story how he/she got involved and here i my story:
How i got involved:
First, i never actively planned to join the Mozilla Community it just happened I worked back in 2001 at a German Email Provider as 2nd Level Support Engineer and as part of my Job (and also to Support Customers) we used different Email Programm’s to find out how to set-up the Programm and so.
Some Friends already involved into OpenSource (the Linux Community) pointed me to this Mozilla Programm (at that time M1 or so) and i liked the Idea with this “Nightly”. Having everyday a brand new Program was something really cool and so started my way into the Community without even knowing that i’m now Part of the Community.
So over the years with Mozilla i finally filed my first bug and and was scared like hell (all this new fields in a non-native language) and not really knowing what i signed up when i clicked up this “submit” button in bugzillla (was not even sure if i’m NOW supposed to fix the bug
So over the years with more involved into Mozilla and (in my case) with QA and Testing i got the offer to work at my favorite OpenSource Project and Browser in Full-time. And still super excited to work as part of this super great team.
And its still great to show new Community Members how to got involved
What i learned
Being a Community Member at Mozilla is something very special. Even from the first more active days in the QA Community i felt more than welcome and people are very thankful and helpful to show you the way and how stuff works.
I was never planning or hoping to get rewards etc when getting started, but contributing to a OpenSource Project like Mozilla is no one-way thing where you donate something to the Project. You get a lot back like interacting with a lot of people from different locations and maybe from around the world.
Also i learned a lot about Software Engineering like how stuff works and also about Teamwork and Co-working and also somehow improved my language skills a lot Also you meet and work at least online with a lot of new friends. Thats all something you never get at one place in your normal day job (at least was my experience)
The most important lesson i learned over the years is “never afraid to ask questions”. Nobody is expecting you that you know everything. So never afraid to ask questions – its much better to ask someone instead of getting stuck on something where the answer might be a “mouse-click away” on IRC Also this might also result in new insights into the Problem and Solution and maybe result in a way better solution than you were thinking.
Learn to accept that there will be mistakes – nobody is perfect – and there might be situations where you are on the wrong track or you made an error/ mistake. Happened as example to me too when i was verifying a bug wrongly in a Firefox Release that caused in the End a Re-Release of a Firefox Version. I can tell you i was super sad that day when i realized that i could have catched the Regression if i were digging deeper and with more testing etc…So yeah was a super bad feeling but then someone i got of motivation from other Team Members telling me that Errors can happen and thats its not the end of the world. So yeah that was super great at that day and reminded me that Mozilla is also not a one-man show its TEAMWORK!
We need YOU!
Open-Source lives from Contribution to the Project by the Community. So its never too late or bad timing to join the Project. There is always a place for you to join the Mozilla and also its a super great place to do you very own impact to make the web a better place to everyone. You don’t need to be a super code expert, there are a lot of Areas at Mozilla where you can contribute.
So yeah get started today!
What i do currently:
Like i said i started in QA and now working as Sheriff at Mozilla. Its part of the Auto Tools Team at Mozilla.
The primary responsibility of the Sheriffs is and will always be to aid developers to easily, quickly, and seamlessly land their code in the proper location(s) and ensure that code does not break our automated tests. In the service of this objective, the Sheriffs work closely with the larger engineering organization to create and enforce landing policies that increase productivity while maintaining an efficient and robust automated testing system. Beyond the policy role, they have also become shepherds of automation quality by monitoring intermittent failures, performing uplifts and merges, and identifying poorly performing automation machines.
And we are also looking for new Community Members!
Why not Community Sheriff
A Community Sheriff is working the other Sheriffs to keep the Code-Trees in a good shape and also working with Developers and also filing bugs for failing tests etc.
We are working currently on creating documentation to get new Community Members. So when you are interested in becoming a Community Sheriff let us know in the #ateam Channel on IRC (irc.mozilla.org).
So the web site for the Patient Protection and Affordable Care Act (Obamacare) didn't go so well. That's not really surprising, a web site for that many government departments, agencies and states is destined to failure. Everything will have to be RFP'd to different contractors and bidders. It will get so insanely complex that even getting the main job done will be next to impossible. I'm pretty impressed it launched at all.
I've done plenty of those RFPs and they aren't fun. My favourite was one for the BC Government for a very simple site. But the amount of project management overhead was amazing. Three meetings a week to three different departments in two different cities, in person over the course of the project. I didn't apply for that RFP.
But what's more interesting is that it is just a web site. A lowly old web site is able to be the centre of attention and to be the corner stone of a Government policy to fix the US insane and dysfunctional health care system. A registration portal for millions upon millions of people to actually get health care. That's pretty cool and not something you see every day.
It won't fix the US health care system though.
Firefox is now multi-process, and not just for the plugin-container process. For example, there is now (present but disabled in Firefox 25, and likely to be released in Firefox 27) a separate process that is used to update the thumbnails shown in a new tab.
As a result, sometimes you might want to test something in the presence of multiple processes. Here’s how I’ve been doing it.
- Delete the images in the thumbnails/ directory within the profile’s temporary directory.
- On Linux it’s ~/.cache/mozilla/firefox/<profile>/thumbnails/.
- On Mac it’s ~/Library/Caches/Firefox/Profiles/<profile>/thumbnails/.
- On Windows it’s C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\thumbnails\.
- I’m not sure about Android.
- Open about:newtab. This triggers a thumbnails process. It’ll live for about 60 seconds. (If you’ve configured about:newtab to be blank rather than showing thumbnails, this might not work, though I’m not sure.)
Please let me know if there’s a better way!
(And if anyone can give me extra info on the things I’m not sure about, I’ll update the text above accordingly. Thanks!)
This blog is now running Ghost, and so far things are going quite well. Glooging is up in frequency $infinity % over last month!
I ran into some minor deployment issues that initially confused me:
- Image uploads weren't working! This is because I used an upstart script to start ghost, and the current working directory or CWD of upstart scripts is '/'. Ghost assumes that the current working directory is instead the ghost root, so it was merrily uploading everything to /content/... instead of /data/apps/ghost/content/. All I needed to do was make sure the upstart script cd'd to the ghost directory before starting the site up. Here is a link to the now-corrected upstart script.
- Ghost relies on the NODE_ENV variable being set in its environment, and doing this was a little difficult using upstart. You'll notice in the script I set it several times in various ways - that's just me flailing until it works. I need to trouble-shoot a bit more with a dev server to see what the right thing is.
- It took a little hacking around to get a working Nginx proxy configuration that would find images in the right folder, re-map my rss feed, etc. Here's the one I'm using right now.
Fundamentally I'm doing more work and poking around more than I really need to. All you need to do to self-host ghost is sign up for a $5/month Digital Ocean VPS account - they provide a ready-to-go Linux VPS configured to run Ghost right out of the box. ( And yes, that's my referral code on the linked URL :)
We are even making these postcards to announce this.
An Invitation to InnovationBadgeKit will not only make it simple to get started with badging, but it also will provide lightweight, modular and open options for the community of badgemakers. So now that I have your curiosity, I want to gain your attention. We are framing badgekit around a set of action verbs. Each verb represents an invitation to innovation around defining and refining the user experience for the particular action that the user is attempting to do. Here are the verbs: Build, Assess, Issue, Collect, Share, Discover and Use. You can read what Sunny Lee wrote more about the verbs here.
BadgeKit evolved out of several years of work in this field as well as LOTS of user testing and research. Our initial goal will be to develop proofs of concept for experiences for each of the actions. In order to develop a vision for this work, I looked at the work that we have been doing for the Chicago Summer of Learning, the Connected Educators Month and for the Mozilla Summit. Each project helped us to produce some great open source solutions for distinct badging experience ranging in size from one badge to thousands of badges being issued. With each project, we user tested, got feedback and iterated - so just think of BadgeKit as our next big iteration on our offering. If you are familiar with the tools that we currently offer through openbadges.org - it might be easier for you to digest this information through recipes.
Click here to see all the recipes
What makes something "Badgeriffic"?So now you know - what we are building and a little bit of why - but let me tell you a bit about how we are building it. As a team of Mozilla and community designers, developers and people who have tried spinning up our own instance of badges - we have been trying to find our voice. Specifically, we asked ourselves "What makes something Badgeriffic?" Over the years we've had a hunch about what the answer is and over the past few weeks, I've done a bunch of initial exercises to help us to start to identify what our design values are. Even as I write this post, I don't have a definitive answer, but I am going to share with you our current thinking and ask you to give me some feedback and thoughts about what you value.
We kicked this off with a virtual sticky note activity:
After people filled in what they thought made something "Badgeriffic," we clustered like-minded notes and came up with overall statements that we are calling values. Values give us a chance to say, "we did all of these things so we feel that ethically and aesthetically, this is a product that we can stand behind". So, what I am starting to believe is that our values are aligning perfectly with the
Firefox Design Values
This makes sense because well, we are one Mozilla - and behind all of our work we have that heart connection that motivates us to work for a non-profit and we want to build things that make the web better. On a high level, the BadgeKit offering will help to shape environments, build products, empower communities as well as teach and learn: the four pillars of our work at Mozilla that our Chief Lizard Wrangler Mitchell Baker recently presented at the Mozilla Summit.
In the next few weeks there will be an announcement about this work and we will be working on the action verbs proof of concept. In the meantime, I would like your help: what do you value and what makes something "Badgeriffic" to you?
[This is a re-post of a post that originally appeared on the Mozilla about:community blog]
Mozillians, imagine an awesome, fun, concrete way to show the world the thousands of people who contribute to Mozilla. The more the better! Your name can be added to a Mozilla monument, and we need your help to get the names of other Mozillians added too. That’s right, it’s true. We’re working to construct a 14 foot (4.26 meters) structure that will sit outside of our new San Fransisco space (check out the concept photos). Onto this monument, oh yes, we will attempt to include the names of every Mozillian.
Action Required: If you are a current or past contributor and would like to be a permanent part of Firefox, your name etched, literally, on the structure, you need to tell us by October 31. To do that:
If you have a vouched mozillians.org profile, sign-in and click the ‘Join Group’ button on the SF Monument group page. Joining that group means you would like your name, as it appears on your profile1, to appear on our public art installation.
If you don’t have a vouched mozillians.org profile or are unable to access it, fill out this form and we will help you get added to the monument.
And while you are adding your name for the monument, we also encourage you to add your name to about:credits. It’s a great way to show the world you have contributed to Mozilla, and the easy directions can be found at the bottom of the about:credits page.
We will include the names of contributors listed in about:credits, though you can opt-out by October 31. Just fill out the form below.
Spread the word to Mozillians: We know there are many Mozillians, past and present, who will not see this post on their own. Please share this post with those people. We ask that contributors who do not have a vouched mozillians.org profile fill out this form and we will help them get added.
1 We are using the Open Sans font to print the names on the monument, so there are limits to which characters can be printed. Take a look at the characters available, and if your mozillians.org profile name is not printable in Open Sans, please email the characters you would like printed for your name to firstname.lastname@example.org.
It’s been many months since my last status report on the state of Kuma. There are many reasons for this; some technical, some personal. I’ll be trying to do this more regularly again going forward. Obviously, the big project is the redesign of MDN. Most of our fixes apply directly to that project right now.
Here’s a quick list of the things that landed in the last few days:
- The new search results page has a big search box on it.
- Menu font sizes have been improved on search results pages.
- Fixed a bug that caused double vertical scroll bars to appear on zone landing pages with short content areas.
- Use of the content space within the body of articles is improved.
- Performance of the localization dashboard is improved.
- Other improvements for the wiki and home page, including fixes for RTL and text overflow problems.
- KumaScript warning messages now use preformatted styling for easier reading in the redesign.
Also, several internal fixes building up toward upcoming big features have been committed.
We should be getting the ability to delete and move pages very soon. The code is finished and committed; I’m trying to sort out why it’s not enabled yet so we can fix whatever remains to be done so it can be switched on, at least for a few people to test.
What inspires you to teach the web? We asked Webmaker community members for their answers — then invited them to share their stories using this remixable Webmaker template. What’s your story? We’d love for you to make and then share your own using the #teachtheweb hashtag on Twitter.
I want users of the web to understand it better, so they can have better control over their online lives. Teaching the web also helps me learn something new every time.
Ankit is a Master’s student in Computer Science, Webmaker Mentor and Mozilla Rep.
Yoe One Ariestya Niovitta, Surabaya, Indonesia
I love sharing knowledge and skills. I’m always very happy every time I see the cheerful, enthusiastic faces of young people when they teach and learn the web.
Yoe One is a student in System Information, blogger and journalist.Chad Sansing, Waynesboro, Virginia
The future should be something our kids can make for themselves rather than have to buy or go without.
Chad is a language arts teacher, National Writing Project teacher consultant and connected learning ambassador.
Ibraahiima Saar, Paris, France
I want to empower everyone to become the makers of the web that we as citizens of the world need.
Stephen Fortune, London, United Kingdom
Stephen is a interactive media artist and visiting research student at the Centre for Cultural Studies in Goldsmiths University. He using Webmaker tools like the X-Ray Goggles to remix pages like the one below.
“The three Webmaker tools – X-Ray Goggles, Thimble, and Popcorn Maker – each promise methods for snapping and reshaping the web — website remixing, website building and cloud based video remixing,” he says in this article. “They channel the playful anarchy of punk hacktivists and opens up their methods so everyone can remix the web and share the results with one another.”
Jeannie Crowley, New York City
I teach the web because a teacher once said to me, “I can’t learn that.”
Jeannie is the Manager of Digital Media & Learning at Bank Street College of Education, and loves teaching about “Hip Hop, Remix & Political Discourse.” She was one of the first-ever Webmaker mentors, and created data visualizations and social media analysis of our “Teach the Web” open online course. She also created a Webmaker music video response to the NSA Prism scandal, and made this Rihana mash-up.
Why do *you* teach the web? Hit the “remix” button to make and share.
Dopplr.com goes offline on 2013-11-01. It was an awesome service in its day, unfortunately neglected by Nokia post-purchase. If you have / had an account on Dopplr, you should go login and download your data.
From their home page:Dear Dopplr user,
As of November 1st, 2013 we will be discontinuing the Dopplr service.
What does this mean for you as a Dopplr user? You will continue to have access to your data until November 1st, 2013, after which the service no longer will be available.
Nokia apologizes for any inconvenience, and we thank you for using Dopplr.
Dopplr's home page has a login box, however if you use OpenID, use their OpenID specific login page:
I had trouble with OpenID login from the home page so use this instead.Export your data
Once you've logged in, you can go directly to the "Download an export of your data" page:
Click the [ Send me my data ] button and within moments you should get a download of a ZIP archive with your trips, answers, and places in various formats.Save your Dopplr connections
One of Dopplr's most innovative features was how they designed connecting with fellow travelers. Dopplr introduced an asymmetric follow model long before Twitter, and interestingly enough, in reverse. You gave people permission to view your trips ("Share trips"), rather than asking to follow theirs.
Dopplr also introduced a "mute" feature, a way to temporarily hide updates from a specific person (e.g. if someone you didn't care to follow had shared their trips with you).
Unfortunately Dopplr's data export does not contain your connections: the people that have shared their trips with you, those you share trips with, and mutually so.
However, you can save your Dopplr connections by doing the following:
- Use Firefox to go to: http://www.dopplr.com/account/connections
- From the File menu, choose Save Page As...
- Be sure Web Page, complete is selected in the popup menu
- Save and you'll get an HTML file with a directory next to it of its resources (images etc.) made offline accessible.
If you want to save the raw HTML source of the page as well, repeat the above but set the popup menu to Web Page, HTML only and perhaps rename the saved file to include _source at the end to distinguish it from "complete" version you saved above.Others you might know
If you want to save a bit of Dopplr's inferred data about you, repeat the above steps, with the "Others you might now" URL in Firefox:
And that's it.What next?
There are no sites I know of that are able to import Dopplr's data exports, but even if there were such a site, it would just be one more silo you'd have to export from once it announces a shut down.
The IndieWeb approach would be to instead figure out how do you want to save, host, and optionally publish your past/future trip information on your own site, and then import your Dopplr data into your personal site to save and display it however you like.
Regardless of future plans, don't delay. Dopplr shuts down in less than two weeks. Go get your data. Figure out what to do with it later.Addendum: Screenshots
Exercise for the reader:
- Save screenshots of all the interesting user interface screens and flows in Dopplr
- Publish them somewhere with a Creative Commons license
Beyond "your data", the logged-in-only user interface in Dopplr was a big part of the experience, and is worth archiving in some way. Screenshots may be particularly useful for anyone redeveloping Dopplr-like functionality for their own site, or for an aggregator of trips across indieweb sites. If you do publish such screenshots, let me know and I'll link to them here.
I was invited to the last two Mozilla Summits but I always missed it. This year, I finally be able to attend the Summit.
So what is Mozilla Summit? The apparent approximation of the Summit would be to think of it as a three-day festival, to celebrate what we want to achieve and also to reaffirm our Mission; however, Summit is way, way more than that. I am humbled and comforted by the fact I got to engage in many high-level, philosophical conversations about Mozilla and the Mission itself, in a lot of breakout sessions. Some of the questions being bought up were fundamental questions like what is a Mozillian, challenges of communicate the vision to the boarder audiences like the general users (kudos to @potch on many of his insight comments), to practical questions like how to work with closed mobile industry partners, and our challenges with our current position in the mobile market, and internal organization.
These are all important conversations that I have little chance to talk about in the office, given the fact we are all caught up in daily work. To my embarrassment, I feel I should ask forgiveness on being cynical in conversations. Nonetheless, to me, it’s more important to know how we are doing than why. The summit shouldn’t be a three-day religious or self-reinforcing event where only the good news were told; I am really glad it didn’t being hold like this for the majority of the time spent. To my relieve, I am also happy to find out most of people are much more energetic and optimistic about how we are doing, and much more hopeful on whether or not we will getting there, and devoting their thoughts on what we could do more to get there.
During the keynote, the main message of the Summit given was “We’re here to build an Internet the world needs.”. I totally agree that Mozilla should expand it’s mission from simply Open Web to Open Internet, although my question about Open Hardware being the foundation of Open Internet and another eventual goal of the project was not being picked up during the QA session. I’ve also heard little discussions (expect DRM) on some of our seemly conflicting means to reach the end, which, arguably, is a good thing (because that means most of us in the Summit agrees the Mozilla way — making concessions in order to gain future influences).
On topics unrelated to the Summit directly: I found that Toronto is a really lucky city, being gifted to have the off-shore Toronto islands that serves as a getaways and an “central park”. The city itself is a bit chaotic though as they were constructions around the Union station. However the 12 hours time difference stuck me hard; I missed a few night events because I was so tired that I had to crush to bed.
By the way, best wishes to Margaret and Gavin They were call up to the stage by Jay during closing in Toronto on their #MozLove: they first met on Summit 2010 and got engaged last week. I am pretty sure they weren’t the first ones and they won’t be the last ones.
That’s us, we are the hopelessly idealistic, happy, and innocent, Mozillians.
UPDATE: This change has been reverted for now. It will take a couple days for the blocklist to be updated on everyone’s machine.
A while back, Mozilla had announced a plan to block all versions of Java by default. While that didn’t happen when Firefox 24 shipped, it has been done via an update to the blocklist. See bug 914690.
It’s unfortunate that this happened on the ESR, since Java is still essential for some enterprise applications (and apparently the entire country of Denmark).
I don’t have any information yet if you can use the permissions API to enable Java for necessary sites. For now, you might just have to turn off the blocklist by setting extensions.blocklist.enabled to false.
UPDATE: You can also use the Click-To-Play Manager add-on to update the domain whitelist. I’ll be adding support for this into CCK2.
we recently pushed a small change to bugzilla.mozilla.org to make things slightly easier for teams using bugzilla to track github pull requests. when an attachment contains just a github pull request url, bugzilla will redirect to that url when the attachment is viewed.
the easiest way to do this is to use paste text as attachment:
paste the url, provide a description, and ensure patch is not checked.
after you submit the attachment, bugzilla will change the content-type to x-github-pullrequest.
clicking on the attachment will redirect you to github.
- currently only github pull requests are supported
- the attachment content cannot contain anything other than the url
- any existing text/plain github pull request attachments should already have their content-type adjusted
- html files with a meta-redirect to github have not been altered, nor will they trigger bugzilla’s redirection mechanism
Filed under: bmo
Before actually heading over to the Summit, Myk Melez and Nick Desaulniers were kind enough to show me around the Mozilla Mountain View office! (Thanks to Daniel Holbert for setting that up!)
The GSoC Mentor Summit is run as an "unconference", the open sessions were chosen by conference attendees and run as discussions with no keynote speakers. This was an interesting experience and how good each session was varied quite a bit by who was taking part in the discussion, but overall it was great to hear the experiences of other projects with their GSoC students, as well as to hear about lots of projects I had never heard of before! In general the session I attended were about community building and managing GSoC students, I took lots of notes and will digest all of this in further detail at some point.
I was able to meet lots of great people from different projects, just a few of which were: Pidgin, Debian, Buildbot, the Open Lighting Project, the Tor Project, phpBB, etc. Unfortunately being from Mozilla, most people already know what you do...or they think you do at least! Many people were surprised when I said I work on Thunderbird and Instantbird. I heard "Thunderbird is dead" at least twenty times, which was quite disappointing that those in the open source community don't even understand the current status of Thunderbird. Many were happy to hear that it is still being maintained and developed by the community, however. I even had some people thank me (which I don't really deserve) for helping to continue maintain Thunderbird! It was great to hear things like this at the Mozilla Summit, but it was really invigorating to hear people outside of the Mozilla community excited that their favorite email client was still being developed.
People were further surprised to hear that Thunderbird now includes instant messaging / chat (since Thunderbird 15 or 17) and that there is a Gecko based instant messaging client: Instantbird. It seemed like some people were excited by this and hopefully they'll try it out!
Anyway, I've gone a little off-topic, but overall the Mentor Summit was great and I'd like to thank both Mozilla and Google for giving me this opportunity. If I find any really great gems in my notes I'll write further blog posts about them.
FirefoxOS grew quickly to be a super active project under constant global development by hundreds of people around the world (employees and volunteers in Mozilla). Over the past two years we developed a fully fledged open source mobile operating system based on web technologies. Naturally the least thing you could do as a Mozilla contributor is to try to keep track of what is happening, and arguably this has been really difficult from the start.
On one hand this is understandable. The pace the project is moving is lighting-fast, with requirements and dates changing constantly. On top of that, our partnership with companies of the industry (OEMs, OBs, chipset manufacturers etc) has made the tracking of things even more complex.
On the other hand, the successful end result (and engagement of new people) is a hind (or a proof?) that there might be a way to track things for us mere mortals. With this post I will try to describe the discovery and tracking procedure I am using to keep myself engaged and updated about FirefoxOS. The info I am looking for are one or all of those: dates, owners, projected ETA, code, specs, mockups.
Disclaimer: This is by no means an official guide to feature-tracking but rather a documentation of my personal experience and definitely tailored to my tracking needs. Hopefully this can be proven useful to other people and I will get some suggestions in comments, so comment away!
Let’s start with the basics. Bugzilla is your central source of information about everything happening in Mozilla-verse. But we will need more than that to be successful. We need to be able to understand how things are tracked within Bugzilla. My focus has been Gaia (as the most FxOS-unique part of FxOS stack) so let’s say for the sake of this guide that we are looking for more info on a Gaia feature. (e.g. Custom ringtones)
Our first stop is Gaia wiki. Wiki.mozilla.org is used for all high-level tracking of FxOS features (and pretty much for all other Mozilla projects too)
Navigate through the page and you can find all different major areas of Gaia (Apps, System and their sub-parts) Once you locate the section that your feature is under (in our case System>Sound) click through to land in the wikipage specific to the area of the project. Although the Gaia (and generally FxOS) team has done a fantastic job of updating the wiki with status of features and roadmap you might end up in a not-so-helpful wiki page (like in our example).
Stepping back a bit, our goal is to find more info about a feature. For every feature you might think of there are three different scenarios:
Scenario 1: Feature is a planned, detailed and committed one.
If the feature is something that the Gaia team is committed to deliver (approved in meetings) then one of the following can happen:
- The easiest case is that all the info you need is on the wikipage we just explained how to find. Boom you are done!
- A slightly trickier case is that the info is not yet on the wiki so you need to search bugzilla for it. Before you do that make sure to check out the UX specs making sure that your feature is part of the committed ones. (Bonus: get lost in the fantastic work that UX team has done!) Searching bugzilla you should use “Advanced Search” with “Boot2Gecko” as the Product and make sure you search for both NEW-ASSIGNED(generally open) *and* RESOLVED status. FxOS team is delivering like crazy and your feature might be already delivered! You can easily identify the “official” commited bugs by their title ([User Story] something_here) and/or their priority/severity (P1/blocking etc)
Once you find the bug you are looking for you can get all the info you want or cc your self to get more info as they come (m0Ar bugmail please!)
Scenario 2: Feature is a proposed one.
In this scenario the feature is something already proposed by someone and there is an active (or not!) discussion around it. Bugzilla is your only help here. Follow the instructions above on Bugzilla search. Most of those bugs will be UNCONFIRMED or NEW (definitely not ASSIGNED and hardly RESOLVED as INVALID or WONTFIX) so tweak the bugzilla search accordingly. Make sure to be constructively involved in the discussion around the feature (based on your expertise) so you can make sure that your lovely FxOS device will soon have your killer feature!
Scenario 3: Feature is not even a proposed one. (It’s all in your head!)
You know the story… File a BUG! But wait! Before you go ahead and file a bug, opening the flood-gates of bugmail, make sure to do the following: Check with UX guidelines to see if you missed something. There might be a case that something is already spec’ed out in UX designs but not translated to a bug. In that case ping UX people on IRC channel #gaia for follow-ups. If UX designs prove to be unaware of your awesome idea you might want to have a look at project Haida. Project Haida is the UX project for proposed features and designs for future versions of Gaia.
If everything fails and you are the sole person in the world thinking about this cool feature, you might as well go ahead and file a bug (following bugzilla guidelines and etiquette) under Boot2Gecko Product and the Component that fits your proposed feature category.
Extra channels: As always make sure to drop by Mozilla IRC on #gaia (or #b2g if that’s suitable) and ask for help if you are stuck. Mozillians there as *awesome* and super responsive.
Hopefully this over-view of my workflow as a non-member of FxOS team will be useful to some other Mozillians out there Please go ahead and comment with ideas and enhancements (or corrections!) of the process. Special thanks to Fredy for his countless hours standing by me navigating through FxOS code, and asuth for his responsiveness on any Gaia related questions we had
The Mozilla Developer Network is currently doing a public beta of a new design and information architecture that features, amongst other things, a new logo featuring an understated sillouette of the 'Dino' logo:
How do you get to see the rest of the design? Just log in with your Persona account under preferences check off the 'Beta User' option.
Many people in the project are already aware of this, but the dino was orginally created by world-renowned street artist Shephard Fairey in 1998 and was used in all of the original Mozilla.org branding:
Aside: if you want more details, I refer you to an old post by Jay Patel on, of all things, the previous re-branding of the original MDC site over to MDN.
It is also well known within the project that for a while some Moco leadership were not fond of the dino. I am instead a huge fan - it's subversive, deeply non-cuddly, with a nod to the Soviet-era 'Socialist Realist' style of art that I think is one of the great legacies of 20th Century comnunist regimes (it's certainly more compelling than their automobile design). While Firefox branding is perfect for the reach of a top-3 web browser and top-10 worldwide brand, I think the dino is the branding that resonates with open web hackers everywhere.
My favourite story around the 'hack' / dino branding is from earlier this year at the excellent TXJS conference in Austin. My co-worker Anton had printed off a stack of 'hack mozilla' stickersout of his own pocket. TXJS had a huge table for stickers and other swag in the front of the theatre, and every so often Anton would put another stack of 'Hack Mozilla' stickers out. People snatched them up like rare hot appetizers in a room otherwise filled with bland cheese & stale crackers.
What's the lesson? For developers, the dino works. The dino rocks. In my opinion it's an iconic piece of art created for a world-changing project by an essential and amazing artist. We'd be crazy not to use it. :)
The second annual Stability workweek (2013) was held in Mountain View during August 19 – August 23. Along with the core Stability team, several folks across Mozilla’s functional areas participated in this workweek. The goal of this workweek was to revisit current stability processes, fill gaps (if any), improve tooling to help with the ongoing browser stability efforts and to discuss integration of Firefox OS.
Two differentiating things at this workweek :
- Diversity of participants – The cross-functional group consisted of members from stability group, socorro (back-end and front-end), core developers (folks from the java script team, memory management and graphics), quality assurance, security, user advocacy, user interface, project managers, release managers, technical account manager (TAM), mobile, Firefox OS etc making it an interesting mixed audience which led to diverse input and a lot of great ideas
- Workweek format – Alex Keybl and Robert Kaiser designed the workweek in such a way that, the first half of the week concentrated heavily on discussions and the second half was more hands-on to give us time for :
- Analyzing all the goodness that came out from the initial brainstorming
- Filing necessary bugs
- Assigning owners to each action so we don’t drop the ball on items that were prioritized
Key Discussions and Take-aways :
- Met with the graphics team and discussed on efforts that can be taken to improve crashes that are peculiar to certain graphics cards (Example : Build specific AMD Radeon Crasher)
- OutOfMemory(OOM)/Empty crashes – we get around 15-20% of Empty crash reports most of them being OOM’s. Below are some thoughts on attacking this problem :
- Annotation on OS,build architecture,”how many tabs were open” etc - bug 838061
- Annotate the slow script dialog – bug 907993
- Annotate or show events like Firefox or Microsoft releases on the crash chart
- Narrow down the cause of crash by correlating signature summary to the hardware information – graphic chipset and driver, hardware, cpu etc
- Met socorro end-users to get feedback on crash-stats that we have today, understand their pain points and consider proposals to improve socorro to further benefit them. Below are a few planned actions in this area :
- Benjamin Smedberg to come up with a flowchart explaining : how to get complex data (core dumps) that you need for crash investigation which may not be readily available, tips on next steps useful when debugging
- Look up output (bug 818069 ) and a lot more improvements on stack-walking when investigating complex crash scenarios
- Making elastic search queries more flexible for customized results
- Met with the security team and discussed ideas on different ways we could incorporate fuzzer test cases
- Integration of crash data to Firefox Health Report (FHR) and correlate this data to provide useful tips to our users who may be experiencing crashes
- Rethinking “Socorro” – Interesting discussion on how we store crashes, querying the database, running better analytics and evaluating the need for HBase and the problems around it
- Revisit “TopCrash” criteria – we currently classify a bug as a topcrash based on the criteria. Discussion on tweaking the existing metric to incorporate crash-volume, number of impacted users, type of crash, startup crash, bug comments etc
- Coalescing signatures associated with the same bug # in socorro and determine the topcrash ranking based on that information (bug 717797)
- Improving user support for our users who are experiencing crashes by trying some of the following :
- Embed support article in the crash report
- Sending custom emails to the user with information on resolution to their issue
- Develop a magic 8 ball API in socorro which will help determine crash reasons, process 100% of crashes etc to better improve overall support – bug 915667
Discussion & Take-aways for Firefox OS (Fx OS) :
- Creating a per-partner view for crash-stats which will aid in giving a clear picture in the stability efforts. This will also help get partner attention on debugging/investigating key crashes
- Ability to detect OutOfMemory (OOM’s) situation that lead to hangs vs crashes
- Simplifying the current upload symbol process to a web based tool so partners can easily upload symbol files
- Improving Fx OS crash-reporting to have per-device and per-build reports that are readily available via crash-stats
- Having a CrashMeNow app for easier testing of end-end crash reporting
- Implement about:crashes, about:gaia-crashes
Phew ! that’s a lot. I’ve tried to limit this post to a high level overview of all the interesting topics discussed at the workweek. You can find all the details on each session on this wiki.
The Thunderbird Team is interested in knowing what your favorite add-on’s for Thunderbird are, and we will be restarting the “Thunderbird Add-on for the week” across all of our social media channels. If you have an add-on that you know of that you think deserves highlighting please leave a comment on my blog, ping me on IRC (bkerensa in #Thunderbird on Mozilla IRC) and I will be sure to check it out.
Recently, hundreds of Mozillians from all over the world gathered in three different locations for the Mozilla Summit. I had the opportunity to attend the summit in Toronto.
While I was there, I attended a couple sessions where the Firefox UX team talked about Firefox User Types in North America. The UX team did an incredible job framing the various types of Firefox users. It made me realize that the same thing is important to do for the types of people that need an “enterprise Firefox.”
When I say “enterprise Firefox,” the only use case that most people think about is big companies limiting what end-users can do. But there are very valid reasons why someone would need to configure Firefox in a very specific way.
Sometimes the reason is physical safety. Think about a browser on medical equipment or a factory floor.
Sometimes the reason is online safety. Think about a browser at an elementary school or shared by members of a family with different ages.
Sometimes the reason is legal or regulatory. Think about a browser at a bank or a securities firm.
Sometimes the reason is simply that the computer is shared by a lot of people. Think about a browser at a library or a nursing home or a web cafe or a homeless shelter.
I think for a lot of us, we tend to see other computer users exactly like ourselves. We need to realize that people (and organizations) use computers in completely different ways, ways that most of us don’t even know about. As long as we build software primarily for ourselves, we’re going to completely miss out on opportunities for Firefox.
Sometimes the user of Firefox is not the end-user. It’s the administrator or company that wants to deploy Firefox to their end-users. We need to make sure that Firefox is a great browser for them as well.
We need to balance end-user desires with administrator constraints.
Maybe what we need here is a new word? Enterprise doesn’t really capture the spirit of what I’m trying to do. Anyone have any ideas?
Somewhat surprisingly given that I’ve been “around” for “a while”, this year’s was the first summit I went to. I’d been to several FOSDEMs, a EuroOSCON/EuroFoo, and several other conferences as a Mozillian, but somehow the invitations for Summits/MozCamps/Add-on events had always come at a time when I had already planned other international travel for whenever they were happening (once more my apologies to Will, who I think has never had any other response to invites than apologetic “erm, I’d love to, but I can’t make it — maybe next time?” emails).
Anyhow, this was the first time announcements came so early (and my traveling had somewhat quietened down) that I was still free. And what an event it was! I met a whole bunch of folks that I’d never seen before, despite interacting with them online for years now (I would add a list but I’d be sure to forget someone…). It’s great to have faces (and some stories) to the names. Then there were some of my Firefox MoCo teammates that I met for the first time. I also had a chance to hang out with a wide range of people, volunteer and employee alike, active in totally (or only slightly) different areas of the project than me (MoCo “people team” folks, documentation writers, reps, devtools team members, add-ons developers, Paris office workplace resource people, and the list goes on…) both during sessions as well as in bars, when walking through random bits of Brussels, or in the hotel lobby / breakfast room.
Session-wise, I first went to the excellent session about Privacy, Security and Data. Thanks Garrett, Stacy, Curtis, Crystal, etc. for a fascinating session about what we can do and how our biases about privacy as technically adept folks are different from most other people, who worry about completely different things.
The next day I spent a bunch of my energy showing off Australis and answering questions about it at the Innovation Fair together with Jared, Matt, and many of the UX team people (who had a bunch of other stuff to show off, not just Australis). At the Brussels booth, we had a good selection of questions and worries from people about add-on compatibility, Linux (sadly, our booth table was big enough for two laptops, on which we showed OS X and Windows builds, which probably prompted many of the questions), customizability, and how to test the builds. Hopefully we did a good job answering those questions, and we’re getting ever closer to shipping Australis on Nightly!
We then had a hurried lunch and I went to the “Developing empathy for your users” session. I met some more amazing people there, and we had an interesting time thinking through the motivations and interests of the people that our UX team met doing field research, and trying to see how and why they made decisions the way they did. Thank you Larissa and Maureen for an excellent session!
Afterwards I had a quick conversation with Blake about an idea that I’d been mulling over for a while now, and spent the rest of the afternoon hacking. Not that idea, but related, is now slowly progressing on bugzilla: create source maps for preprocessed chrome files. Otherwise, if I find some extra hours in my week (unlikely) I may try and produce something else to ease hacking on the front-end of Mozilla products.
Finally, on Sunday, there was a bunch more hacking, and I went to the excellent session on DRM, where we had a somewhat depressing discussion about what we as Mozilla can do about the EME proposal in the W3C HTML spec.
On Monday, we all went home again! I think what I took away from the summit most of all was an increased awareness of the size and diversity of our community and its goals, as well as how the mission unites us. Kudos to the organizers for coordinating a complex and large event as well as they did!