On the 28th of January we, the Mozilla Switzerland, community held another community meetup to organize ourselves for the next few months in 2017.
We did a start/stop/continue analysis of our work in 2016. Here’s the result:
With that in mind, we came up with a few goals for the first half of the year. Since we all agreed on stopping to do unrealistic goals we focused on the most voted ones from above. Of course this doesn’t mean that we will only do those, so everyone is encouraged to also do their own initiatives and we will still have our monthly meetups to bring topics forward.
These are our goals for the first half of 2017. Our motto is: Complete goals and do more instead of running after goal completion and not succeed like we did in the past year.
Experiment: Organize Bootcamp/Barcamp style conference (community proposes talks and votes on them to be done at the beginning) with a broader Web topic. If successful this can be done more frequently and maybe even be adapted to fit into an evening, or be expanded to two days. Our hypothesis is that this brings in more interested people than the talks we regularly organize without clear call-to-action.
Owner: Marc and Michael
We continue to ask Mozilla to make its decision process more transparent, so community members can feel more involved.
This was a major concern during our community meetup. This goal is not fully defined and we will work together to phrase our scope accordingly. Also this goal definition is a “working draft”, therefore not perfectly phrased.
On June 20th the Swiss Mozillians met in Zurich to discuss the second half of the year. The goal was to come up with objectives for mozilla.ch that are aligned with the current Mozilla strategy and the Participation Team and Mozilla Reps goals.
At first we did a retrospective, here are the key results:
What should we stop doing?
Discussions on the mailing list
posting “meta” discussions on Github
focusing on initiatives we don’t have time for
excluding people from discussions (see “meta discussions”)
focusing on Zurich
creating single point of failures
missing to provide clear pathways to contribute when we have a talk
What should we start doing?
Create a central hub for all resources MozillaCH-related (in terms of “Get involved”)
Focus on a few single strengths we have instead of a lot of single initiatives we can only go so far for
Start non-linear discussions on discourse
Have more event locations to get to people that can’t come to Zurich or Lausanne
Be more clear about the strengths of single community members and support them with initiatives that fit into the general direction of Mozilla
Start using communication channels specific to the audience we want to reach
What should we continue doing?
Event organization works well
Github issues for tracking
Team work at meetups
Keeping things simple (not having a lot of bureaucracy hassle)
With that in mind, we came up with two objectives. Both are aligned with overall Mozilla strategy pieces. The first one is Core Strength, the second one is Prototyping the Future. None of these Key Results are easy to achieve, but we think that with these we can achieve a good base for the upcoming years.
Objective 1: Grow our core contributor strengths and be amazing at being visible in Switzerland
Key Result 1: We have at least 5 core contributors that are active on Discourse
The Janitor was started by Jan Keromnes, a Mozilla employee. While still in an alpha state, Jan gave us access to it so we could test run it at our hackathon. Many thanks to him for spending his Saturday on IRC and helping us out with everything!
Once you’re signed up, you can click on “Open in Cloud9” and directly get to the Cloud9 editor who kindly sponsor the premium accounts for this project. Cloud9 is a pure-web IDE based on real Linux environments, with an insanely fast editor.
At the hackathon we ran into a Cloud9 “create workspace” limitation, but according to Jan this should be fixed now.
After an initial “git pull origin master” in the Cloud9 editor terminal, you can start to build Firefox in there. Simply running “./mach build” is enough. For me this took about 12 minutes for the first time, while my laptop still needs more than 50 minutes to compile Firefox. This is definitely an improvement. Further you won’t need anything else than a browser!
I had my environment ready in about 15 minutes if you count the time to compile Firefox. Comparing this to my previous setups, this solves a lot of dependency-hell problems and is also way faster.
Running the newly compiled Firefox
The Janitor includes a VNC viewer which opens a new tab and you can run your compiled Firefox in there. You can start a shell and run “./mach run” in the Firefox directory and you can start testing your changes.
For some of the bugs we tackled at the hackathon, we needed to run ESLint (well, would be good to run this anyway, no matter what part of the code base you’re changing). The command looks like this:
user@e49de5f6914e:~/firefox$ ./mach eslint --no-ignore devtools/client/webconsole/test/browser_webconsole_live_filtering_of_message_types.js
0:00.40 Running /usr/local/bin/eslint
0:00.40 /usr/local/bin/eslint --plugin html --ext [.js,.jsm,.jsx,.xml,.html] --no-ignore devtools/client/webconsole/test/browser_webconsole_live_filtering_of_message_types.js
8:1 warning Could not load globals from file browser/base/content/browser-eme.js: Error: ENOENT: no such file or directory, open '/home/user/firefox/browser/base/content/browser-eme.js' mozilla/import-browserjs-globals
8:1 warning Definition for rule 'mozilla/import-globals' was not found mozilla/import-globals
8:1 error Definition for rule 'keyword-spacing' was not found keyword-spacing
18:17 error content is a possible Cross Process Object Wrapper (CPOW) mozilla/no-cpows-in-tests
✖ 4 problems (2 errors, 2 warnings)
0:02.85 Finished eslint. Errors encountered.
As you might see from the input, running this in the Janitor environment results in not finding the Mozilla-specific rules. The reason here is that the eslint npm package is installed globally. Globally installed eslint can’t find the locally installed mozilla-eslint-plugin. In my opinion the easiest fix would be to not install it globally, just within the firefox directory (running “./mach eslint –setup”) while spinning up the instance should be enough here.
We could circumvent this problem by changing the global npm prefix and then running it with “/new/path/eslint …” so it doesn’t call the other one. In hindsight, we could just have installed it to the directory and then call it through node_modules.
Update, May 5, 15:09: Jan has has fixed this plugin issue :)
Creating a patch
Creating a patch is really easy, following the tutorial on MDN is enough. We were very happy to see that the moz-git-tools are already installed by default, so you can just create your own branch, checkin your changes and run “git format-patch -p -k master” to get a Git patch file. Since we need a Mercurial patch, you then run “git-patch-to-hg-patch” and you can upload the resulting file to Bugzilla and you’re set!
Those two commands could maybe be aliased by default so running “create-patch” or similar would directly do this for you to further decrease the work you need to do manually.
Seeing it in action
After some initial account problems, we didn’t really find any other bugs apart from the ESLint situation. Again, thanks a lot to Jan for providing us the environment and letting us test it. This will change the live of a lot of contributors! For now The Janitor supports contributions to Firefox, Chrome, Thunderbird, Servo and KDE. There is also a GitHub repository for it.
Before the hackathon we created a list of “good first bugs” that we could work on. This was a great thing to do, since we could give the list to the attendees and they could pick a bug to work on. Setting up the environment to hack was pretty easy. We’ve used “The Janitor” to hack on Firefox, I’ll write a second blog post introducing you to this amazing tool! We ran into a few problems with it, but at the end we all could hack on Firefox!
We worked on about 13 different bugs, and we finished 10 patches! This is a great achievement, we probably couldn’t have done that if we needed more time to set up a traditional Firefox environment. Here’s the full list:
Thanks to everybody who contributed, great work! Also a big thanks to Julian Descolette, a Dev Tools employee from Switzerland who supported us as a really good mentor. Without him we probably couldn’t have fixed some of the bugs in that time!
At the end of the hackathon we did a round of feedback. In general the feedback was rated pretty well, though we might have some things to improve for the next time.
40% of the attendees had their first interaction with our community at this hackathon! And guess what, 100% of the attendees who filled out the survey would be joining another hackathon in 6 months:
For the next hackathon, we might want to have a talk about the Firefox Architecture in general to give some context to the different modules. Also for the next hackathon we probably will have a fully working Janitor (meaning not alpha status anymore) which will help even more as well.
Janitor will be great for hackathons (though still Alpha, so keep an eye on it)
The mix of talk + then directly start hacking works out
The participants are happy if they can create a patch in a few minutes to learn the process (Creating Patch, Bugzilla, Review, etc) and I think they are more motivated for future patches
All in all I think this was a great success. Janitor will make every contributor’s life way easier, keep it going! You can find the full album on Flickr (thanks to Daniele for the great pictures!).
We started to organize the Hackathon on Github, so everyone can participate. Geoffroy was really helpful to organize the space for it at Liip.ch. Thanks a lot to them, without them organizing our events would be way harder!
We expected more people to come, but as mentioned above, this is our first self-organized event in the French speaking part of Switzerland. Nevertheless we were four persons with an interest in hacking something together.
Geoffroy and Paul started to have a look at Vaani.iot, one of the projects that Mozilla is currently pushing on. They started to build it on their laptops, unfortunately the Vaani documentation is not good enough yet to see the full picture and what you could do with it. We’re planning to send some feedback regarding that to the Vaani team.
In the meantime Martin and I set up my Raspberry Pi and started to write a small script together that reads out the temperature from one of the sensors. Once we’ve done that, I created a small API to have the temperature returned in JSON format.
At this point, we decided we wanted to connect those two pieces and create a Web app to read out the temperature and announce it through voice. Since we couldn’t get Vaani working, we decided to use the WebSpeech API for this. The voice output part is available in Firefox and Chrome right now, therefore we could achieve this goal without using any non-standard APIs. After that Geoffroy played around with the voice input feature of this API. This is currently only working in Chrome, but there is a bug to implement it in Firefox as well. In the spirit of the open web, we decided to ignore the fact that we need to use Chrome for now, and create a feature that is built on Web standards that are on track to standardization.
After all, we could achieve something together and definitely had some good learnings during that.
Organizing a hackathon for the first time in a new city is not easy
We probably need to establish an “evening-only” meetup series first, so we can attract participants that identify with us
We could use this opportunity to document the Liip space in Lausanne for future events on our Events page on the wiki
Not all projects are well documented, we need to work on this!
After the Hackathon
Since I needed to do a project for my studies that involves hardware as well, I could take the opportunity and take the sensors for my project.
You can find the Source Code on the MozillaCH github organization. It currently regularly reads out the two temperature sensors and checks if there is any movement registered by the movement sensor. If the temperature difference is too high it sends an alarm to the NodeJS backend. The same goes for the situation where it detects movement. I see this as a first step into my own take on a smart home, it would need a lot of work and more sensors to be completely useful though.
Back in November we had a Community Meetup. The goal was to get a current status on the Community and define plans and goals for 2016. To do that, we started with a SWOT-Analysis. You can find it here.
With these remarks in mind, we started to define goals for 2016. Since there are a lot of changes within one year, the goals will currently only focus on the first part of the year. Then we can evaluate them, shift metrics if needed, and define new goals. This allows us to be more flexible.
Objective 1: The community is vibrant and active due to structured contribution areas
Objective 2: MozillaCH is a valuable partner for privacy in Switzerland
Objective 3: There is a vibrant community in the “Romandie” which is part of the overall community
Objective 4: The MozillaCH website is the place to link to for community topics
Objective 5: With talks and events we increase our reach and provide a valuable information source regarding the Open Web
Objective 6: Social Media is a crucial part of our activities providing valuable information about Mozilla and the Open Web
We know that not all of those goals are easily achievable, but this gives us a good way to be ambitious. To a successful first half of 2016, let’s bring our community further and keep rocking the Open Web!