For a year now the Systems and Data Working Group of Mozilla has been meeting, brainstorming about community building systems, designing and implementing them and pioneering new ways to measure contribution activity across Mozilla.
In the process of evaluating existing systems (like mozillians.org) and creating new ones (like Baloo) it was obvious that we needed a common set of principles to apply on all systems that are in service of community building within Mozilla. That would enable Mozillians to easily access tools and contribute in a way that maximizes impact. We as the Systems and Data Working Group recommend these principles be adapted for all tools used by Mozilla.
The principles written in buckets are:
- Unified Identity
- Tools should have single source of truth for people data
- Integration with HRIS
- mozillians.org already has staff and volunteer information, so it is a good candidate at the single source of tr
- Tools should de-duplicate people information by integrating with a single source of truth
- e.g. Reps: Not integrated with Mozillians.org, lots of duplicate information on two profiles
- Tools should have single source of truth for people data
- Unified Authentication and Authorization
- Tools should use a single identity platform that provides permissions-based access to tools (like Mozillians.org)
- e.g Reps: add people to the Reps group on mozillians.org to give them permission to use rep.mozilla.org as a Rep
- Accessible Metrics
- Tools should track each contribution a Mozillian makes and provide it in an accessible way to create a holistic view of contributions
- Tools should be localized so they are accessible to our global community
- Tools should teach the user how to use the tool, answer common usage questions, and have general documentation
- Tools should recognize the contributions that they enable
- Tools should enable anyone to improve the tool by filing bugs, suggesting ideas and bringing those ideas to life
- Content de-duplication
- Tools should de-duplicate the content that is created in those tools, making it accessible to other systems
- Tools should be personal and written in the Mozilla voice
This has been a collaborative effort involving various stakeholders of tools within Mozilla that have been reviewing those and providing feedback during our meetings. We are seeking more feedback moving forward especially with regards to how those impact the Roadmap of various tools and translate to actual features. Feel free to comment here or join our discussions in the community-building mailing list.
If you’ve been following my blog, you know that there has been a long on-going project to rewrite Firefox’ preferences and move them to a page within the browser.
Work has continued on that front, but it has been moving at a slow pace. Today, representatives from engineering, user experience, and project management met together to form the remaining list of bugs that are blocking us from shipping in-content preferences to the Release channel.
In total, we have 20 bugs blocking the release. There are five different categories that the bugs fit in. Bugs that should be easy to pick up and finish for a new-comer are italicized.
- High-contrast mode
- Bug 1022578: Can’t tell what category is selected in about:preferences when using High Contrast mode
- Bug 1022579: Help buttons in about:preferences have no icon when using High Contrast mode
- Bug 1022582: Checkboxes and radio buttons in about:preferences lack any indication they’re checked/selected when using High Contrast mode
- Session restore
- Bug 1056478: Resizer of sub-dialog follows only half of the movement of mouse pointer
- Bug 1055973: Navigating by TAB key, it should be only in between the browser UI and the sub-dialog
- Bug 1044600: in-content preferences: empty dialogs after pressing backspace or the Back button
- Bug 1044597: in-content preferences: resized dialogs should not push buttons into overflow
- Bug 1043346: in-content subdialog cut off on bottom and right. Unrelated subdialog size changing affect the other one.
- Bug 1043612: Persist the size of resizable in-content subdialogs
- Bug 1012410: Can’t close in-content cookie exceptions dialog
- Bug 1089812: Implement updated In-content pref secondary dialogs
- Bug 1014208: Updated InContent Preferences Design Based on Project Chameleon
- Bug 1036434: In-content preferences doesn’t show the complete scrollbar
- Bug 1008171: No focus for elements except textboxes (and buttons, on Windows and Linux) inside in-content preferences
- Bug 1008172: Scrolling up and down on pages with scrollbars in about:preferences will change subgroups
If you’d like to work on one of the above bugs, please click on the bug and read the details. If you have any questions, please post the question in the bug and someone will get back to you. Thanks!
Tagged: firefox, planet-mozilla, ux
One of the problems we've been facing with Mozilla's release cycle is that it takes a relatively long time for code to get from commit to the mozilla-central repository to get into the hands of our users. It's currently 12-18 weeks, because the current process has four repositories (central, aurora, beta, release) with most code landing on central, and with code shifting from one repository to the next every six weeks, and shipping to Firefox release users when it reaches the release repository:
In addition to being slower than we'd like, we're not getting quite as much feedback as we'd like since the population of aurora users is relatively small and have habits much more similar to our nightly users than our release users. This means that we don't get feedback about many real-world problems until code reaches the beta channel.
One alternative that's been discussed a few times is to have one fewer channel. People have brought up some drawbacks with that approach, such as that code pulled from mozilla-central the previous day isn't necessarily ready to be shipped to large population of users on the beta channel.
To address that, I'd like to propose an alternative that shortens the path by six weeks (and removes one of the four repository stages), but keeps the four separate populations:
This model differs from what we do now by eliminating the mozilla-beta repository, and thus removing six weeks from the cycle. Users on the nightly, aurora, and release channels would get code like they do now, tied to one repository. Users on the beta channel, however, could get code from the release repository for the first week or so of the cycle (right after we ship that release), and then get code from the aurora repository (which will become the next release) for the rest of the cycle. In other words, users on the beta channel won't change the version that they're running on merge day, but instead a week (or maybe two) later.
Having the beta users switch repositories has two advantages. First, it means that beta users will be able to beta-test any point releases that we ship in the first week or so of the cycle. Second, it means that we'll have a week or so to fix any serious stability problems in the aurora repository before updating all beta users to it.
To be clear, this is just my proposal for what I think we could do, not something that anyone is already planning to do. But I think it could be a good way to get us a faster release cycle that would allow us to get our work faster into our users' browsers.
buildbot assigns jobs to machines (aka slaves) through hosts called buildbot masters.
All the different repositories and packages needed to setup buildbot are installed through Puppet and I'm not aware of a way of setting my local machine through Puppet (I doubt I would want to do that!).
I managed to set this up a while ago by hand  (it was even more complicated in the past!), however, these one-off attempts were not easy to keep up-to-date and isolated.
I recently landed few scripts that makes it trivial to set up as many buildbot environments as you want and all isolated from each other.
All the scripts have been landed under the "community" directory under the "braindump" repository:
The main two scripts:
- It creates a build, try and test masters under a directory called "masters"
- It creates a build, try and test slaves under a directory called "slaves"
- cd /path/to/your/own/workdir
- source venv/bin/activate
- buildbot start masters/test_master (for example)
- buildslave start slaves/test_slave
I hope this is helpful for people out there. It's been great for me when I contribute patches for buildbot (bug 791924).
As always in Mozilla, contributions are always welcome!
PS 1 = Only tested on Ubuntu. If you want it to port this to other platforms please let me know and I can give you a hand.
PS 2 = I know that there is a repository that has docker images called "tupperware", however, I had these set of scripts being worked on for a while. Perhaps someone wants to figure out how to set a similar process through the docker images.
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
In this post you can find an overview about the work happened in the Firefox Automation team during week 35 and 36.Highlights
Due to a lot of Mozmill test failures related to add-on installation and search, we moved from the addons-dev.allizom.org website to the staging website located at addons.allizom.org. Since then we experiencing way lesser test failures, which are most likely network related.
In order to keep up with all test failures, and requests for new tests we started our Bug triage meeting on a weekly basis on Friday. For details we have created an etherpad.
Because of the app bundle changes on OS X, which were necessary due to the v2 signing requirements, we had to fix and enhance a couple of our automation tools. Henrik updated mozversion, mozmill, and mozmill-automation. We were close to releasing Mozmill 2.0.7.Individual Updates
If you are interested in further details and discussions you might also want to have a look at the meeting agenda, the video recording, and notes from the Firefox Automation meetings of week 35 and week 36.