Watch mconley livehack on Firefox Desktop bugs!
I’m writing to let you know that Tuesday, September 1st, we’ll be hosting the Firefox 41.0 Beta 6 Test Day. The main focus of this event is going to be set on verify Windows 10 bugs and make firefox crash on windows 10. Detailed participation instructions are available in this etherpad.
No previous testing experience is required so feel free to join us on the #qa IRC channel and our moderators will make sure you’ve got everything you need to get started.
Hope to see you all on Friday! Let’s make Firefox better together!
At the very end of June, we added a “Pledge to Teach” action to teach.mozilla.org. After people complete the pledge, they are able to take a survey that allows us to find out more about their particular context for teaching the Web, and their needs.
I’d like to share results from the first month, during which 77 people completed the survey, out of 263 users who took the pledge (29% response rate).
First, we asked what people are interested in, in terms of teaching the Web, and provided some options for people to choose from (people could choose as many as they liked).
- Starting a Mozilla Club: 57%
- Getting access to Digital Literacy curriculum: 79%
- Running learning events (Maker Party, Hive Pop-Ups, etc.): 61%
- Professional Development to help me get better at teaching digital skills: 81%
- Connecting with a network of peers: 77%
- Exploring tools to make the Web: 66%
The results from this question align with our strategic plans to develop more curriculum, provide more professional development offerings, and build tools to help people connect with one another.
We asked about the age range of learners:
- 6-13: 40%
- 14-24: 78%
- 25-34: 44%
- 35-44: 26%
- 45-54: 17%
- 55+: 19%
These findings align with the age-range that most of our existing curriculum is optimized for (14-24). That said, we know our audience is broader, and that content can be adapted for different audiences. Certainly we have community members that work in the K-12 space and higher ed. Given the numbers for learners over 24, we may consider more intermediate/advanced web literacy content, and/or address this audience with more in-depth Teach Like Mozilla and MDN content.
We asked how many learners people expect to reach this year:
- 0-50: 32%
- 51-100: 22%
- 101-200: 26%
- 201-500: 5%
- More than 500: 14%
This data speaks to the fact that survey participants are more likely individuals who have direct interactions with learners, vs larger partners with wider networks. The survey was intended to reach individual educators/mentors, but we might consider a similar survey directed to partners, too.
Note: we’ve since added a question to the survey that will allow us to know how many learners people reach at any one time. This will inform our curricular design process.
We asked about the contexts in which people teach (again, respondents were able to choose multiple answers):
- At standalone events (for example, a one-day workshop, hackathon or Maker Party event): 51%
- In a classroom during the school day: 52%
- As part of an afterschool or summer program: 31%
- With my friends and family at home: 56%
- At professional meet-ups or training events with other adults/mentors/educators: 51%
- At a college or university: 27%
- At a library or other community space: 26%
Some of these results surprised us. For example, the responses for teaching at home and with friends is higher than we’d expected, as were the number of people teaching in professional meetups. If these trends continue, they will inform our curricular and professional development content offerings. We are also having a Web Literacy Training Fellow join us later in the year, and she will specifically address these contexts.
These findings also show that people are teaching across various contexts, which may speak to some leadership pathways (e.g. classroom teachers also hosting standalone events to reach more people).
Finally, we asked people about their motivations for teaching the Web. Here is a sample of those responses:
- The Internet is a place where any information is available, and people ought to know how to access the best of the information they seek, and know how to protect themselves beyond anti-virus programs. I want the opportunity to teach and engage with learners and peers outside of the classroom. (Canada)
- I always believe that I should never wait for opportunities to help other people rather I should let myself open doors to help others. I want to share a part of what I know to people who wants to learn more about the digital world. (Philippines)
- I think technology especially the Web could be a wonderful facility to awaken and support children being creative and using free thought as a positive means of fully participating in communities, society and the world. (UK)
- Am driven by the passion to make the world a better place. I want students from my school to have extra skills apart from the normal curriculum taught in school. (Kenya)
This is a very small sample so far, but we’ll look at results for the second month soon and see if trends continue.
In the meantime, the results of the survey will inform several of our next steps, including:
- Consider iterations on site information hierarchy and calls-to-action
- Create content strategy that reflects community needs—this includes everything from site copy to blog content to curricular content to social media
- Advance partner strategy given these insights
We are also starting a new research effort with support from the Webmaker product team, to complement the survey. The project hasn’t been fully designed yet, but will likely help us dig deeper into questions about our community’s assets, needs, and contexts.
Sometimes, after we close a bug because we fix it, or because it is a duplicate of another bug, or because the symptoms have gone away — invalid and wontfix bugs are a little different — people come along that have a problem that they believe is identical to the original bugreport. Quite often, they end up commenting on the “old” bugreport and say something along the lines of “hey, this is not fixed yet” or “this broke again” or “why did you close this bug, I’m still seeing this”!
In 99% of cases, I (and many other people) ask people in this situation to file a new bug.
The reasons why we do this vary a little, but on the whole they tend to be pretty similar, and so I figured it would be worth documenting them. In no particular order, we prefer new bugs over reopening closed ones because:
- More often than not, issues with similar symptoms can be caused by different factors. In Firefox’s case, these can be the version of Firefox, add-ons, different preferences/options that people have selected, third-party software, network setup, hardware and drivers, the OS people are using (Mac, Linux, Windows (what version?), …), changes in public web pages involved with the bug, … it’s a pretty long list. Different causes will require different fixes, and tracking them in the same bug will lead to confusion very quickly.
- We close bugs as fixed when we land patches. We track the uplift of the patches that landed for a bug in that bug. Reopening a bug that has already had patches landed in the tree, especially once they’ve been uplifted and released, confuses tracking the state of those patches, and any new patches that we write to fix the same issue.
- The old bug will have investigation and discussion of the problem as originally reported. If we now start investigating the new issue in the same place, with the old summary and the old comments, testcases, attachments, steps to reproduce, reporter, etc., we will eventually get confused. This relates to the first point: quite often there are subtle differences. Keeping track of those once we have two reports in a single bug, and ensuring we address the issue fully is difficult, often impossible.
- Bugzilla sends a lot of email, and is geared towards communication with flags and email. If you report an issue by commenting in another one, the “reporter” role of that bug is still the old reporter, and the CC list includes all the reporters of the duplicate bugs that were filed, the assignee will be the person who landed the last few patches (but they might not be able to fix the newly-reported thing, or might even have left Mozilla altogether), and so on and so forth. This confuses the “needinfo” flag, spams all those people about an issue they might no longer be seeing, and generally leads to still more confusion.
- People track open bugs they are assigned to, and new bugs in certain components. New comments (on closed bugs) are much, much more likely to get lost in the daily bugmail avalanche – which means your issue won’t get fixed.
- Comments are almost always low on details. Comments are often “this still doesn’t work”, with no indication of any of the environmental factors that impact where and when people see bugs (see the earlier point). When people file new bugs, we immediately get more information, normally at least the operating system and version of Firefox involved, and if people are careful about how they file the bug and describe its symptoms or steps to reproduce, we might learn about differences in the steps they’re using, compared to the old bug.
- New bugs are cheap! Bugzilla has more than 1.1 million bugreports in it. Another one won’t hurt. Worst case scenario, we can mark it as a duplicate of the old one…
It might be interesting if we had an easy way to split a comment into a new bug, though that would still defeat some of the points raised earlier. In the meantime though, think twice before commenting on older, closed bugs with a “this is still broken” comment!How do I get attention for my newly filed bug? Email to all the people on this old bug seems much more likely to get attention!
Second, we get a lot of bugreports. We’re working on ensuring they get triaged effectively. This should already be a lot better than it was a few months ago (see this post by Benjamin Smedberg), and will continue to improve.
Finally… if you file a bug that is extremely similar to an old bug, it seems fair to me to leave a comment in the old bug, mark the new bug as blocking the old bug, and/or set the needinfo flag for the assignee (if available) of the fixed bug, to draw their attention to this new bug.
I’ve been running a keylogger on my main Linux box for exactly one year now. The keylogger logs every key-press – its scan code together with a time stamp. This now allows me to do some analyses and statistics of what a year worth of using a keyboard means.
This keyboard being logged is attached to my primary work machine as well as it being my primary spare time code input device. Sometimes I travel and sometimes I take time-off (so called vacation) and then I usually carry my laptop with me instead which I don’t log and which uses a different keyboard layout anyway so merging a log from such a different machine would probably skew the results a bit too much.
What did I learn?
A full year of use meant 6.76 million keys were pressed. I’ve used the keyboard 8.4% on weekends. I used the keyboard at least once on 298 days during the year.
When I’m active, I average on 2186 keys pressed per hour (active meaning that at least one key was pressed during that hour), but the most fierce keyboard-bashing I’ve done during a whole hour was when I recorded 8842 key-presses on June 9th 2015 between 23:00 and 24:00! That day was actually also the most active single day during the year with 63757 keys used.
In total, I was active on the keyboard 35% of the time (looking at active hours). 35% of the time equals about 59 hours per week, on average. I logged 19% keyboard active minutes, minutes in which I hit at least one key. I’m pretty amazed by that number as it equals almost 32 hours a week with really active keyboard action.
Zooming in and looking at single minutes, the most active minute occurred 15:48 on November 10th 2014 when I managed to hit 405 keys. Average minutes when I am active I type 65 keys/minute.
Looking at usage distribution over week days: Tuesday is my most active day with 19.7% of all keys. Followed by Thursday (19.1%), Monday (18.7%), Wednesday (17.4%) and Friday (16.6%). I already mentioned weekends, and I use the keyboard 4.8% on Sundays and a mere 3.6% on Saturdays.
Separating the time-stamps over the hours of the day, the winning hour is quite surprising the 23-00 hour with 11.9% followed by the more expected 09-10 (10.0%), 10-11 and 14-15. Counting the most active minutes over the day shows an even more interesting table. All the top 10 most active minutes are between 23-00!
The most commonly pressed keys are: space (10%) and backspace (6.5%) followed by e, t, a, s, left control, i, cursor down, o, cursor up, n, r. 29 keys were pressed more than 1% of the times. 30 keys were pressed less than 0.01%. I used 99 different keys over the year (I believe my keyboard has 105 keys).
Never pressed keys? All 6 of the never touched keys are in the numpad: 2, 3, 5, 6, 9 and the comma/del key.
I’ll let the keylogger run and see what else I’ll learn over time…