Current Scheduling Plan!
- First Issue: Nov 26, 2007 (Monday morning)
- Deadline for Submissions: Nov 22, 2007 (Thursday!)
More details to come (I'll blog all about it).
The Mozilla Project is a vast and sprawling beast. At any given time there are dozens of things to follow: projects, meetings, events, blogs, newsgroups, bugzilla tickets, forums, mailing lists, irc channels, and so forth. Where we are absolutely blessed with one of the most active, passionate, and vibrant contributor communities in the world, we are also cursed with a surfeit of communications channels. Thousands of contributors, it turns out, generate a lot of information.
It can be overwhelming. Even those of us at the heart of it, who have the fortune to be in the thick of it all day, every day (and night, and weekend, and sometimes holidays) get behind. We get way behind. There's simply no possible way for any one person to be aware of whats going on in all parts of the Project all the time. And it's infinitely worse for someone who is new to the Project, whether they be interested in contributing, just looking for more information about Firefox, or trying to get news about Mozilla itself. Even figuring out where to start is difficult if you don't have a personal guide or a helping hand.
Thus, the Newsletters Project.
The fundamental purpose of the Newsletters Project is to help make sense of the madness. By gathering, sorting, distilling down, and publishing regular summaries about various aspects of the Mozilla Project, the newsletters will make it easier to figure out what's going on and where. They will also provide that kinder, gentler "starting place" for people who are new to the project to get their feet wet, instead of making them drink directly from the Mozilla information firehose.
- Periodical (ie: not a blog that's updated continually)
- Pushed to interested audience (people forget to check non-push channels)
- Not mixed with other information channels -- needs to be a single-purpose channel (one-stop shopping, no extraneous information)
- Online/electronic delivery (that's what we do)
- Tightly distilled content with links to more information
- Archived and searchable
- Open standards only
- Submissions solicited and accepted from the community-at-large
- Full and strict compliance with the CAN-SPAM Act: Requirements for Commercial Emailers
Active contributors; interested potential contributors; the larger Mozilla community; tech-savvy observers, bloggers, and journalists.
- Ensuring that the look and feel of the newsletter is attractive enough to catch readers' attention and actually be read
- Ensuring that the content of the newsletter is consistently useful and interesting enough to grow the subscriber base and hold readers' interest
- Ensuring strict compliance to the CAN-SPAM Act: Requirements for Commercial Emailers
HTML email, while still relatively restricted, will give us the flexibility to do a custom and branded look + feel for the newsletters, while also meeting the "pushed to users" requirement. In addition, however, we must offer a plain-text fallback and option for those users who do not or cannot use HTML mail.
At this time I am leaning heavily towards using the MailChimp service for a wide variety of reasons (CAN-SPAM compliance, anti-spam policy, privacy policies, tools, list export/deletion ability, stats reporting, etc.). This needs to be finalized and approved, so is currently just a recommendation.
For those users who do not want to sign up for a newsletter delivered via email, we will use the Mozilla Blog as a secondary delivery mechanism. With a unique category for the newsletter posts, we will also be able to offer users a newsletters-only RSS feed.
Localised versions of the newsletters will be posted to localised blogs that will be provided by Mozilla and set up when localisation teams request them. Given the legal complications surrounding email newsletters (see the CAN-SPAM Act), however, we will not offer email-delivery of localised versions of the newsletter until there is significant sustained demand for them and the "email newsletter" experiment has been proven to be successful and useful.
Three Month Plan
- Come up with an actual name for the newsletter
- Do an internal test run or three to ensure that the email system works, that formatting is OK, plain-text works, etc.
- Write up and post an "About [Mozilla Newsletter]" page somewhere (mozilla.com) outlining what the newsletter is, what it will contain, how often it will be published, privacy issues, information about the service provider, anti-spam assurances, CAN-SPAM compliance, etc.
- Check with Marketing re: Mozilla Store promos
- Sort out Mozilla Developer Calendar stuff (see below)
- Gather information for the premiere issue (10 item minimum)
- Start with newsletters going out every 2 weeks on Monday morning PST
- After 3 issues, evaluate available stats and do a short reader survey about content, frequency, etc. Solicit detailed feedback and suggestions.
- Evaluate and revise project where necessary (increase/decrease frequency, modify content, etc)
- After 6 issues do a full evaluation of the project and decide whether it is successful and worth continuing in its current incarnation
Mozilla Developer Calendar
- Check with Shaver/Beltzner about Mozilla Dev Calendar maintainership
- Ensure all relevant information is added to the Mozilla Dev Calendar (meetings, events, call-in info, conferences, development schedules, etc)
Not every issue will include news from all of the following sections, but these are the general news topics we want to be sure to communicate out when information is available:
- Firefox development
- Gecko/platform development
- Trunk news
- Mozilla Labs
- AMO (addons.mo)
- Quality Assurance
- Mozilla 2
- Friends of the Tree
- Air Mozilla
- Community Giving
- Mozilla Developer Calendar