Doug Belshaw: Some ideas for Webmaker from the Web Literacy Map 2.0 interviews |
Over the past few weeks I’ve been interviewing stakeholders and community members as we begin to plan a Web Literacy Map v2.0. I wrote a post earlier this week outlining 21 themes emerging from that data.
The Web Literacy Map itself is a list of skills and competencies that’s currently well-integrated with webmaker.org. As this can make it difficult to consider it in isolation, I encouraged interviewees to talk about both the Web Literacy Map and the things we’ve built on top of it.
There were lots of suggestions and, in the main, people were very positive about both the Web Literacy Map and the Webmaker site (including the tools). To help make sense of the feedback relating to things built on top of the map, I’ve organised suggestions using the SWOT (Strengths, Weaknesses, Opportunities and Threats) technique.
I also asked interviewees who we should be reaching out to in order to promote the adoption of an updated version of the Web Literacy Map:
Questions? Comments? I’m @dajbelshaw or you can email me: doug@mozillafoundation.org
|
|
Arky: Micro SIM card adapter |
Eating your own dog food or Dogfooding in technical parlance means the software maker uses their own software thus appreciate its strengths and weaknesses (and hopefully improve on those.)
Usually I dogfood multiple mobile phones running early releases of Cyanogenmod and Firefox OS. Doing this is easy when you have multiple SIM cards. But if you have to swap your SIM card between Nexus 4 (micro-SIM) and Firefox OS device (mini-SIM) then you'll love this inexpensive Nano SIM adapter from NooSY.
http://playingwithsid.blogspot.com/2014/10/micro-sim-card-adapter.html
|
|
Mozilla Reps Community: Reps Weekly Call – October 2nd 2014 |
Last Thursday we had our regular weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.
https://air.mozilla.org/reps-weekly-20141002/
Don’t forget to comment about this call on Discourse and we hope to see you next week!
https://blog.mozilla.org/mozillareps/2014/10/03/reps-weekly-call-october-2nd-2014/
|
|
Soledad Penades: Using a Flame as my main phone, day 3 |
Days that take Sole to want to get rid of the stable build and want to go to Nightly so she can fix the little things here and there that annoy her: 1.
Days that she spends “distracted” with a Jewels-style game: 1.
Hence the jump from day 1 to 3.
I went and compared the stable version with the Nightly version I had flashed on the other Flame and most of the bugs were gone. So I figured that since what I actually want is to “scratch my itches” (another terrible software metaphor) what I’ll do is flash a recent Gecko and work with my custom build of Gaia where I can do whatever I want. WHATEVER. I. WANT. YES.
(Sending a patch and getting it accepted will be an entirely different matter, but maybe I’ll convince everyone that using .ANI files on the home screen is a good idea)*.
I’m kind of getting acquainted to the one-button navigation, but sometimes I sorely miss Android’s BACK button. I’m not sure if that’s because the apps don’t open new links in the right way or why it’s that, but I find that going back to where I was takes me more time than I’d like it to take. I’m not sure how will new users find this workflow–maybe I’m conditioned to find it not as cool but new people love it, so I’m not complaining much about it until I investigate on the best way to open links… but before that, I need to update Gaia!
* Hi, if you thought I was serious, you’ve just been trolled.
http://soledadpenades.com/2014/10/02/using-a-flame-as-my-main-phone-day-3/
|
|
Benjamin Smedberg: How I Hire at Mozilla |
As a manager, one of my most important responsibilities is hiring. While I’m hiring, I spend a lot of time sifting through resum'es, screening candidates, and eventually doing interviews. This is both fun and depressing at the same time, because you get to meet and learn a lot about some interesting people, but you also have to wade through a lot of terrible resum'es and phone screens. I want to share some things that I look for during the hiring process, and some tips for potential job-seekers about how to deal with recruiting:
Please read the job description before applying for a job! I put a lot of effort into writing a job description, and I try very hard to describe both the job responsibilities and the necessary and desirable skills. Your cover letter should show some evidence that you’ve thought about applying for this particular job.
Periodically, I see articles advising job-seekers to ditch the cover letter. This is terrible advice. I read cover letters carefully. In fact, the cover letter sometimes gives me a better sense for your skill level and ability to do the job than your resum'e.
Every job I’ve ever posted has required good communication skills, and your cover letter is the first evidence of your communication skills. It doesn’t need to be more than a paragraph or two; I’d love to know why you think that this job is a good fit, and some evidence that you read the job description. Spelling and grammar are important.
The last time I posted a job position, I screened more than 800 resum'es, did almost 100 phone screens, and did five interviews before I found the right person. It took six months. It’s better for Mozilla if I’m too picky and reject a qualified candidate than if I’m not picky enough and accept a bad candidate. Please don’t take rejection as a comment on your personal worth. I’m going to reject many people during this process.
Joel Spolsky is right: I’m primarily looking for somebody who is smart and gets things done. When I’m scanning through resum'es, I’m looking for evidence that you’ve gotten things done in the past. If you’re just coming out of school, internship and open-source project experience helps. If you’ve been working, I want to see some description of the things you’ve gotten done. Be specific: “Led multiple projects to completion” is meaningless. You can expect phone-screen questions about your prior projects. Be prepared to talk about what worked, what didn’t, and how you solved problems.
It may seem obvious, but assholes need not apply. I will reject a technically-qualified candidate for even a whiff of assholery. I use reference checks to try and guard against assholes.
At Mozilla we get a lot of applicants who are passionate, either about the open web in general or about Firefox. Passion is great, perhaps even necessary, but it’s not sufficient.
In phone screens and interview panels, I try very hard to base my questions on the things that you already know. If your resum'e says that you are a master of C++, you should expect that there is at least one person on the interview panel who will grill you on C++ in excruciating detail. If you say that you know statistics, you had better be able to answer detailed questions about statistics.
Don’t overstate your skills. If you have written a couple scripts in Python, you are familiar with Python, not proficient. More than once I’ve rejected people because they claimed to be a master of C++ debugging but didn’t know how a vtable is structured in memory. Knowing vtable layout isn’t usually a job prerequisite, but if you are a master of C++ debugging you’d better know how that works in detail.
If you claim to be a master of both Python and JavaScript, expect me to ask you detailed questions about how Python and JS closures and methods work, how they are different in JS and python, how JS this-binding is different from Python bound methods, and other details of the language. I will be impressed if you can discuss these questions intelligently, and reject your application if you can’t.
I value people who can learn new code quickly. You’re going to need to be comfortable learning new systems, libraries, and languages. My team in particular often touches large swaths of the Mozilla codebase; you will be expected to be able to read and understand new code quickly. You can expect an interview session entirely dedicated to reading and explaining a piece of code that you’ve never seen before. Perhaps it will be reviewing a patch, or trying to find a bug in a piece of code. I’ll try to find a problem in a language that you are already comfortable with, so see above about keeping your resum'e honest!
Every good programmer has a toolbox. I don’t care whether you use vim or emacs or Visual Studio or Eclipse or XCode, but I do care that you have an editor and use it productively. I also care that you are proficient using a debugger (or two, or three) and hopefully a profiler (or two, or three). If you can’t tell me why you love your editor or your debugger, it’s likely that you won’t be a successful software engineer.
You need to be proficient in a scripting language. I expect you to be able to use at least one scripting language to process text data, read CSV files, write JSON, and that kind of thing. Mozilla has gravitated toward Python for scripting, and you’ll probably be expected to learn Python if you don’t know it already.
Also, can you type? I’m constantly surprised by applicants who are unable to type quickly and accurately. A significant portion of your job is going to be writing code, and not having mastered the act of typing is probably not a good sign.
When I conduct a phone-screen, it is usually over Skype video. Please make sure that you have a decent headset and that I will be able to hear you. During a phone screen, I try to include at least one coding question which is typically conducted via etherpad. You should be at a computer with access to the web in order to do this successfully.
By the way, did I mention I’m hiring?
http://benjamin.smedbergs.us/blog/2014-10-02/how-i-hire-at-mozilla/
|
|
Alex Clark: Pillow Runs Itself! |
As of Pillow 2.6.0, the Pillow project almost completely runs itself!
Of course when I say "runs itself" I mean "runs without me", which is what every open source project lead hopes for. For the first time ever, I was able to:
Kudos to these gentlemen for making my life easier and for continuing to provide the Python community with a featureful, modern & secure Python Imaging Library. Additionally thanks to all the contributors from all over the world who continue to develop and improve Pillow. I used to keep a list, but now there are too many to keep track of. Oh and lastly, 2.6.0 is out! Enjoy the release & please report issues here.
| [1] | Eric Soroos & Hugo respectively. Additional thanks to Christoph Gohlke for Windows Eggs, Exes, Wheels, Matthew Brett for OS X Wheels, and Steve Johnson for Sphinx Documentation. |
P.S. New theme! Thanks Pure Pelican Theme.
|
|
Jennie Rose Halperin: A new look for our Community Newsletter |
This post was featured on the Mozilla Community Blog
If you’ve been wondering why you haven’t received the best in Mozilla’s community news in some weeks, it’s because we’ve been busy redesigning our newsletter in order to bring you even more great content.
Non-profit marketing is no easy feat. Even with our team of experts here at Mozilla, we don’t always hit the bar when it comes to open rates, click through rates, and other metrics that measure marketing success. For our community newsletter, I watched our metrics steadily decrease over the six month period since we re-launched the newsletter and started publishing on a regular basis.
It was definitely time for a makeover.
Our community newsletter is a study in pathways and retention: How do we help people who have already expressed interest in contributing get involved and stay involved? What are some easy ways for people to join our community? How can communities come together to write inspiring content for the Web?
At Mozilla, we put out three main newsletters: Firefox and You (currently on a brief hiatus), the Firefox Student Ambassadors newsletter, and our Mozilla Communities Newsletter (formerly called about:Mozilla)
It was important to me to have the newsletter feel authentically like the voice of the community, to help people find their Mozillian way, and to point people in the direction of others who share their interests, opening up participation to a wider audience.
A peer assist with Andrea Wood and Kelli Klein at the Mozilla Foundation helped me articulate what we needed and stay on-target with the newsletter’s goal to “provide the best in contribution opportunities at Mozilla.” Andrea demonstrated to me how the current newsletter was structured for consumption, not action, and directed me toward new features that would engage people with the newsletter’s content and eventually help them join us.
I also took a class with Aspiration Tech on how to write emails that captivate as well as read a lot about non-profit email marketing. While some of it seemed obvious, my research also gave me an overview of the field, which allowed me to redesign the newsletter according to best practices.
Here’s what I learned:
1. According to M & R, who publishes the best (and most hilarious) study of non-profit email campaigns, our metrics were right on track with industry averages. Non-profit marketing emails have a mean open rate of 13% with a 2.5% deviance in either direction. This means that at between 25% and 15% open rate we were actually doing better than other non-profit emails. What worried me was that our open rate rapidly and steadily decreased, signalling a disengagement with the content.
I came up with similar findings for our click through rates– on par with the industry, but steadily decreasing. (From almost 5% on our first newsletter to less than 1.5% on our last, eek!)
2. While I thought that our 70,000 subscribers put us safely in the “large email list” category, I learned that we are actually a small/medium newsletter according to industry averages! In terms of how we gain subscribers, I’m hoping that an increased social media presence as well as experiments with viral marketing (IE “forward this to a friend!”) will bring in new voices and new people to engage with our community.
3. “The Five Second Rule” is perhaps the best rule I learned about email marketing. Have you captured the reader in three seconds? Can you open an email and know what it’s trying to ask you in five seconds? If not, you should redesign.
4. Stories that asked people to take action were always the most clicked on stories in our last iteration. This is unsurprising, but “learn more” and “read more” don’t seem to move our readers. “Sign this petition” and “Sign up” were always well-received.
5. There is no statistically “best time” to send an email newsletter. The best time to send an email newsletter is “when it’s ready.” While every two weeks is a good goal for the newsletter, sending it slightly less frequently will not take away from its impact.
6. As M & R writes, “For everything, (churn churn churn) there is a season (churn, churn, churn)…” our churn rate on the newsletter was pretty high (we lost and gained subscribers at a high rate.) I’m hoping that our new regular features about teaching and learning as well as privacy will highlight what’s great about our community and how to take action.
And now to the redesign!
The first thing you’ll notice is that our newsletter is now called “Mozilla Communities.” We voted on the new name a few weeks ago after the Grow Mozilla call. Thanks to everyone who gave feedback.
An overview of the newsletter’s new look.
While the overall feel remains the same and is in line with other Mozilla-branded newsletters, the new look incorporates a few “evergreen” opportunities and actions you can take before the fold as well as features a contributor in their own words. (For the draft of the new design, that contributor is me!) The easy actions on the left hand side will rotate out as needed and increase in commitment level as you read down the page. Also, take a look at the awesome logo from Christie Koehler!
The next section presents rotating features on our privacy and educational initiatives. Privacy and education span a variety of functional areas, so this section could be populated by a variety of community endeavors. At the bottom of these sections, there’s a Facebook post and Tweet that you can post to easily take action, promote our communities, and get social to protect the Internet.
The next section features a story that engages the reader to take action! (In this case it invites readers into our awesome new gear store…) This story about Mozilla communities will rotate out according to the content that you submit. It will also be action-oriented, easy, and fun.
This last story is optional and will be rotated in and out according to testing during the first few issues. (Early feedback feared that there were too many stories.) In the draft design, we’re announcing a new contribution area. This will be a place for new community contribution areas, pathways, and opportunities to connect. The new photo section, “Mozillian Moments,” replaces our “Photo of the Week” section from the last iteration.
Finally, the footer reminds the reader that this newsletter is community-created and community-supported. It also invites readers to join us on social media. In the upcoming issues, the newsletter will also link to the new “Guides” forum that will help contributors find mentorship opportunities and connect with their fellow Mozillians.
What we need from you:
1. We need writers, coders, social media gurus, copy editors, and designers who are interested in consistently testing and improving the newsletter. The opportunity newsletter is a new contribution area on the October 15th relaunch of the Get Involved page (under the “Writing –> Journalism” drop down choice) and I’m hoping that will engage new contributors as well.
2. A newsletter can’t run without content, and we experimented with lots of ways to collect that content in the last few months. Do you have content for the newsletter? Do you want to be a featured contributor? Reach out to mozilla-communities at mozilla dot com.
3. Feedback requested! I put together an Etherpad that asks specific questions about improving the design. Please put your feedback here or leave it in the comments.
The newsletter is a place for us to showcase our work and connect with each other. We can only continue improving, incorporating best practices, and connecting more deeply and authentically through our platforms. Thank you to everyone who helped in the Mozilla Communities redesign and to all of you who support Mozilla communities every day.
|
|
Zack Weinberg: Programming languages and transportation |
Last week there was a gag listicle making the rounds entitled “If programming languages were vehicles” and I lol’d along with the rest of them, but then I kept thinking about it and a bunch of the entries just seemed to miss the mark. And I’m in a silly sort of mood, so here is MY version: slightly different language selection, just as opinionated, 100% more Truth™.
All images from Wikimedia Commons.
Mercedes V6 DTM Rennmotor 1996C is an internal combustion engine: it’s changed only incrementally since it was first invented, and it’s still an essential component of nearly everything else on this list, but if you’re in need of a vehicle you’ve got a shit-ton of additional work ahead of you. And there are those who would say that essential aspects of its design are dangerous to the general public.
Warehouse aisle full of unidentifiable itemsC++ is an auto parts warehouse. Dig around in there long enough and you’ll find everything you need to construct whatever sort of vehicle you want, especially if you don’t mind a side trip to the even bigger “Boost” warehouse next door. You’ll still have to put it all together, though, and be careful which boxes you open: rumor has it this warehouse was once used to store … other things.
1971 Ranchero SquireJava is a fully operational vehicle! Unfortunately, it’s one of those big American clunkers from the 1970s; breaks down a lot, lousy gas mileage, and aggressively styled in a way that just looks tacky nowadays.
1972 Cadillac de VilleC
https://www.owlfolio.org/possibly-useful/programming-languages-and-transportation/
|
|
Fr'ed'eric Harper: Building web mobile app that don’t suck at Web Unleashed |
Copyright: http://j.mp/1vcIaaN
Two weeks ago, I was in Toronto for the last day of Web Unleashed from FITC. I was giving a talk on how to build web mobile app that don’t suck. It turns out that those tricks were good for all web applications, but my primary target was to help mobile developers create better applications. I thought a long time about how to approach the topic, and which content I would share with the audience in a short forty-five minutes talk. Since part of my role at Mozilla is to help developers to be successful with Firefox OS, and I saw many struggling with the market as the devices, it was a good start for my content. The emerging markets don’t have the same internet connection speed as us, and this usually cost a lot more. Firefox OS devices, even if amazing, are still low entry level devices (just check the CloudFX – 33$ in India): it mean lower hardware than we used to as mobile developers. For me, it was all about getting back to basic: give a great experience to users, no matter where they are or which platform they use.
So during my presentation, I introduced the concept of mobile first, and responsive web design. I also shared a couple of tips, and tricks on how to optimize your application by thinking about speeding up the loading time, saving on the data transfer, getting better performance, and more.
I’m quite happy with the result as I even got congratulations from the organizers from being in the top rated speakers at the event: it’s always nice to get praise for your work. Despite the good feedbacks, I still feel it’s only the beginning! There is a lot more that we, developers, can do to optimize our mobile web applications, and give a better experience to our users…
--
Building web mobile app that don’t suck at Web Unleashed is a post on Out of Comfort Zone from Fr'ed'eric Harper
Related posts:
http://outofcomfortzone.net/2014/10/02/building-web-mobile-app-that-dont-suck-at-web-unleashed/
|
|
Henrik Skupin: Firefox Automation report – week 33/34 2014 |
In this post you can find an overview about the work happened in the Firefox Automation team during week 33 and 34.
To make sure that our weekly meetings will be more visible to our community, we got them added to the community calendar. If you are interested in what’s going on for Firefox Automation you are welcome to join our Monday’s team meeting.
In regards of the Mozmill project, Henrik landed his patch, which makes Mozmill more descriptive in terms of unexpected application shutdowns. Especially in the past weeks we have seen that Firefox does not restart as expected, but simply quits. There is bug 1057246 filed for the underlying problem. So with the patch landed, Mozmill will log that correctly in the results. Beside that we can also better see when crashes or a not by Mozmill triggered quit happens.
For Mozmill CI we landed a couple of enhancements and fixes. The most important ones were indeed the addition of 20 new locales for testing beta and release builds of Firefox across supported platforms. That means we cover 30 of about 95 active locales now. To cover them all, a good amount of follow-up work is still necessary. Immediately we stopped to run add-on tests for all branches except Nightly builds to save more time on our machines.
Henrik also continued on PuppetAgain integration for our staging and production CI systems. One of the blockers was the missing proxy support, but with the landing of the patch on bug 1050268 all proxy related work should have been done now.
Also on the continuous integration for TPS tests we made progress. The implementation got that far for Coversheet that we made the Jenkins branch the active master. There are still issues to implement or get fixed before the Jenkins driven CI can replace the old hand-made one.
For more granular updates of each individual team member please visit our weekly team etherpad for week 33 and week 34.
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 33 and week 34.
http://www.hskupin.info/2014/10/02/firefox-automation-report-week-33-34-2014/
|
|
Dustin J. Mitchell: PuppetConf Talk: Infrastructure as Software |
I gave a talk at PuppetConf last week entitled "Infrastructure as Software". The gist of it is that Puppet is a programming language, and in order to grow our "Infrastructure as Code" beyond a few thousand lines we need to adopt techniques from software development. I used PuppetAgain as an example throughout (both of good practices and areas for improvement).
The slides are hosted here. As usual with my talks, the slides themselves may not be very useful to you, as they serve only as touchstones for the interesting stuff that I say. Puppet Labs will have a full recording of the presentation up soon; see the notification signup for now.
http://code.v.igoro.us/posts/2014/10/infrastructure-as-software.html
|
|
Hal Wine: bz Quick Search |
With the new developer services components, I find myself once again updating my Bugzilla Quick Search search plugin. This time, I’ll document it. :)
Here are the steps:
|
|
Amy Tsay: Nice hanging out with you, Hangouts |
I began using Google Hangouts on my Android phone over a year ago. To me, it was the same as text-messaging, with the added benefit of having my conversations archived in Gmail. Since then, the app has evolved in a way that has me looking for an alternative.
A few months ago after an update, I tried to send a photo. I was told I had to have a Google Plus account to do so. Wait, I thought: to send a photo through a messaging app, I had to sign up for a different product? That’s like being told your toaster oven will only take bread, so if you want to reheat pizza, you’d have to buy a gas range.
Annoyed, but without a ready alternative, I signed up so I could send the photo through. Over the next few weeks, I was bombarded with Google Plus emails notifying me that people had added me to their Circles. Still, I lived with it because by now, I had begun to appreciate having conversations on my computer continue on my smartphone when I step away.
Then a few days ago, I received a photo in Hangouts that I wanted to save. When I long-tapped it, I was given two choices: Save media or View details. That seemed strange. Sure, I wanted to save the photo and I was given the option, but what if I had wanted to delete the photo? Curious, I asked my friend if she could delete her own photo; she couldn’t either. It turns out, photos you send through Hangouts are automatically added to an album on Google Plus. You’d have to go to Google Plus, find the photo in the album, and delete it there. It’s a five-step process, and it occurs inside an entirely different product than the one you’re using.
But deleting your photo in the Google Plus album doesn’t delete it from your Hangouts conversation. In other words, a photo sent through Hangouts is automatically stored in an album on Google Plus, but deleting that photo from Google Plus does not remove it from Hangouts.
After some investigation, I found three ways to delete a photo from a Hangouts conversation (after it has already been deleted from Google Plus):
The first option nullifies the benefit of message archiving, and the remaining options put unreasonable burden on the user, to say the least.
Also, they only apply to photos sent by you. Go to a Google Plus album associated with one of your Hangouts conversations, and you’ll see that you can’t delete any photo that was sent by the other person.
The entire experience has left me feeling like I have little control over the content I send, and no control at all over the content I receive. It’s an unsettling relationship, and it may be time to call it quits.
https://mozamy.wordpress.com/2014/10/01/nice-hanging-out-hangouts/
|
|
Scott Johnson: git transfusion |
Recently, I’ve been working a lot with git, a version control system. My current company decided that it would be useful to switch from Bitbucket to GitHub. Given that we had a number of repositories already in Bitbucket, it became necessary to move each of these repositories from one source to another. Obviously, we wanted to keep all branches and history intact. It’s not very hard to search Google and find the easiest way to accomplish this1, but I, being of the persuasion that enjoys pain, decided to ignore this simple prerequisite and instead push on with the benefit of only my experience. I accomplished, generally, a satisfactory result, but I thought I would document for posterity both how I should have done it, and how I did do it.
The easiest way to move from one repository hosting service to another is answered in this stackoverflow post. Basically, you perform the following2:
git clone --mirror git@bitbucket.org:yourrepository cd yourrepository.git git remote rename origin bitbucket git remote add origin github:yourgithubusername/yournewremoterepo git push origin --mirror
This is slightly more difficult, but the reason I’m posting this is because, if you did like I did, which is move the repository initially, then make a few commits against the new repository (that, of course, weren’t in the old repository, since you now consider that one dead to you), and then realize that there were items that you neglected to transfer over, then this is for you.
First, move the repository over (I assume you’ve probably already did this step):
cd yourrepositoryworkingdir git remote add github github:yourgithubusername/yournewremoterepo git remote rename origin bitbucket git remote rename github origin git push origin master
So, now your master branch is in the new origin, but what about the other branches? Let’s move them over3:
cd yourrepository
# Temporarily remove reference to new remote
git remote rm origin
git remote rename bitbucket origin
# Now, track all remote branches [3]
remote=origin; for brname in `git branch -r | grep $remote | grep -v master | grep -v HEAD | awk '{gsub(/^[^\/]+\//,"",$1); print $1}'`; do git checkout $brname; done
# Remove master temporarily (as that branch has already been pushed). You'll want to do this
# For any other branches you've moved over, as well.
git branch -D master
# Add back the origin
git remote rename origin bitbucket
git remote add origin github:yourgithubusername/yourgithubrepo
# Push all branches
git push origin --all
# Push all tags
git push origin --tags
While this is slightly more difficult than simply doing it the “easy” way, it does give you a bit more knowledge about the inner workings of git. A colleague of mine, L. David Baron, once told me, “Good judgement comes from experience. Experience comes from exercising poor judgement.”4 I gained a modicum of experience here, but it was worth it. Hopefully, this saves you from making the same mistakes I did, and if you do make those mistakes, it gives you an easier out to correcting them than searching Google for a couple of hours to collect all the pieces of what you need to do.
[url "git@github.com:"] insteadOf = "github:"
|
|
Hannah Kane: Kayaks, Nachos, Pipelines, and Funnels, or: The Mofo Engagement Fall Work Week |
Last week, the Mofo Engagement Team and Friends (terrible band name) met in Toronto for some some serious boating, eating, and hacking.
On to the work-y part!
The agenda was ambitious. We had four concurrent tracks, each with their own projected outcomes:
Did we achieve what we wanted to achieve?
All that, and more.
The End of Year Fundraising team was on fire. The project had been well-prepped in advance, so the team was able to use the work week as a sprint and deliver a slew of prototypes and designs. They tackled the snippet, optimized donation forms including a brand new sequential flow, localization, the fundraising.mozilla.org website redesign, overarching branding, and even an awesome community marketing idea.
The Partnerships team had several rich conversations where they identified possible partners, clarified roles, and simulated the entire sales flow using human props, sticky notes, and impressive improv skills. (I left that session with a post-it note on my laptop that read, “Why would clown mentors come back to the site?” A question for the ages.)
A centerpiece of the Fall Webmaker Campaign is the post-sales funnel which includes custom partner landing pages and a choose-your-own-adventure style event wizard to help people get started with one of three easy/fun Maker Party events. The entire funnel got spec’ed and wireframed and the Event Wizard got some design love during the work week.
Phew.
Does this seem like a lot of stuff? That’s because it is a lot of stuff! But never fear, it’s all summarized on the Engagement Team Workbench. (You can also see a complete list of what we delivered during the work week here.)
|
|
Fr'ed'eric Harper: L’'etat de l’Open Source en 2014 au Salon du Logiciel Libre et des technologies ouvertes du Qu'ebec |
Il y a deux semaines, je me dirigeais `a Qu'ebec pour pr'esenter au Salon du Logiciel Libre et des technologies ouvertes du Qu'ebec (S2LQ). Lorsqu’on m’a approch'e pour pr'esenter, je ne savais trop de quoi parler: l’audience vis'ee 'etant moins technique que lorsque je pr'esente habituellement, soit aux d'eveloppeurs. J’avais pens'e parler de Mozilla, mais la structure 'etant tellement diff'erente d’autres entreprises vivant des technologies ouvertes que je me suis abstenu. Je pensais pr'esenter Firefox OS comme je le fais souvent, mais j’aurais par d'efaut tanguer trop souvent vers un discours technique. J’ai donc d'ecid'e de retourner aux bases du pourquoi, mais aussi d’o`u vient l’Open Source et o`u on se dirige: une pr'esentation plus haut niveau pour sensibiliser les gens sur place, qui fut ma foi, fort bien recu.
|
|
Henrik Skupin: Firefox Automation report – week 31/32 2014 |
In this post you can find an overview about the work happened in the Firefox Automation team during week 31 and 32. It’s a bit lesser than usual, mainly because many of us were on vacation.
The biggest improvement as came in during week 32 were the fixes for the TPS tests. Cosmin spent a bit of time on investigating the remaining underlying issues, and got them fixed. Since then we have a constant green testrun, which is fantastic.
While development for the new TPS continuous integration system continued, we were blocked for a couple of days by the outage of restmail.net due to a domain move. After the DNS entries got fixed, everything was working fine again for Jenkins and Mozilla Pulse based TPS tests.
For Mozmill CI we agreed on that the Endurance tests we run across all branches are not that useful, but only take a lot of time to execute – about 2h per testrun! The most impact also regarding of new features landed will be for Nightly. So Henrik came up with a patch to only let those tests run for en-US Nightly builds.
For more granular updates of each individual team member please visit our weekly team etherpad for week 31 and week 32.
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 32. There was no meeting in week 31.
http://www.hskupin.info/2014/10/01/firefox-automation-report-week-31-32-2014/
|
|
Jay Patel: Grow Mozilla discussion this Thursday |
If you’re interested in helping new people get involved with Mozilla, join us Thursday for an open community building forum.
https://blog.mozilla.org/community/2014/10/01/grow-mozilla-discussion-this-thursday-46/
|
|
Daniel Stenberg: Good bye Rockbox |
I’m officially not taking part in anything related to Rockbox anymore. I’ve unsubscribed and I’m out.
In the fall of 2001, my friend Linus and my brother Bj"orn had both bought the portable Archos Player, a harddrive based mp3 player and slightly underwhelmed by its firmware decided they would have a go at trying to improve it. All three of us had been working with embedded systems for many years already and I was immediately attracted to the idea of reverse engineering this kind of device and try to improve it. It sounded like a blast to me.
In December 2001 we had the first test program actually running on the device and flashing a led. The first little step of what would become a rather big effort. We wrote a GPLed mp3 player firmware replacement, entirely from scratch without re-using any original parts. A full home-grown tiny multitasking operating system with a UI.
Fast-forwarding through history: we managed to get a really good firmware done for the early Archos players and we managed to move on to follow-up mp3 players too. After a decade or so, we supported well over 60 different mp3 player models and we played every music format known to man, we usually had better battery life than the original firmwares. We could run doom and we had a video player, a plugin system and a system full of crazy things.
We gathered large amounts of skilled and intelligent hackers from all over the world who contributed to make this possible. We had yearly meetups, or developer conferences, and we hung out on IRC every day of the week. I still hang out on our off-topic IRC channel!
Over time, smart phones emerged as the preferred devices people would use to play music while on the go. We ported Rockbox over to Android as an app, but our pixel-based UI was never really suitable for the flexible Android world and I also think that most contributors were more interested in hacking devices than writing Android apps. The app never really attracted many users or developers so while functional it never “took off”.
mp3 players are now already a thing of the past and will soon fall into the cave of forgotten old things our children will never even know or care about.
Developers and users of Rockbox have mostly moved on to other ventures. I too stopped actually contributing to the project several years ago but I was running build clients for a long while and I’ve kept being subscribed to the development mailing list. Until now. I’m now finally cutting off the last rope. Good bye Rockbox, it was fun while it lasted. I had a massive amount of great fun and I learned a lot while in the project.
|
|
Robert O'Callahan: Upcoming rr Talk |
Currently I'm in the middle of a 3-week visit to North America. Last week I was at a Mozilla graphics-team work week in Toronto. This week I'm mostly on vacation, but I'm scheduled to give a talk at MIT this Thursday about rr. This is a talk about the design of rr and how it compares to other approaches. I'll make the content of that talk available on the Web in some form as well. Next week I'm also mostly on vacation but will be in Mountain View for a couple of days for a planning meeting. Fun times!
|
|