O'Reilly Network: Mozilla DevCenter

Planet Mozilla is a long-standing and incredibly important source for news and information about the Mozilla Project and community. For years, Planet has operated under a slowly evolving set of unwritten-but-generally-understood policies. In an effort to avoid potential misunderstandings and issues, however, The Planet Mozilla team has finally taken the time to write up and post these policies to the Mozilla Wiki:

The policies are minimal and relatively straightforward, but if you have any questions please feel free to leave a comment here or to email any/all of the Planet Mozilla team (listed on the wiki page).

Thunderbird 3 RC 2 has been released. Release notes are available. This post lists the improvements in Thunderbird 3 RC 2 over Thunderbird 3 RC 1. This list encompasses almost every single known fix that went into this release, but excludes platform-wide fixes. Do check out the known issues as well.

Outstanding bugs (marked blocking-calendar1.0+) with [needed beta] in whiteboard: (1)

The following lists include both bugs that are being fixed in TB3 final as well as bugs fixed in the next version of Thunderbird (3.0.x or 3.1?).

No outstanding bugs (marked blocking-thunderbird3+ with Target Milestone of Thunderbird 3.0rc1).

Outstanding bugs (marked blocking-calendar1.0+) with [needed beta] in whiteboard: (1)

The following lists include both bugs that are being fixed in TB3 final as well as bugs fixed in the next version of Thunderbird (3.0.x or 3.1?).

No outstanding bugs (marked blocking-thunderbird3+ with Target Milestone of Thunderbird 3.0rc1).

I’m currently working on putting together a draft plan for Mozilla Education activities in 2010. I’m a bit blocked on coming up with a coherent plan, so I thought I’d try to unblock myself by blogging my thoughts on the subject. These are informed by the recent feedback on Mozilla Education I solicited from several Mozilla folks, as well as the Mozilla Education 2009 report I wrote earlier. Note that I’m thinking out loud here, so this will be somewhat long and rambling.

Based on the feedback, the first point to address is: What is Mozilla Education, and what are its goals? The people I asked were familiar with what Dave Humphrey has been doing at Seneca College in terms of introducing students to Mozilla, but weren’t clear on what was going on beyond that. So, some explanation: “Mozilla Education” as a program started out as an effort by the Mozilla Foundation to take what was going on at Seneca and try to replicate it at other schools, on the assumption that the Seneca approach was worth replicating. (There seems to be general agreement on this, though as discussed below there are some limitations to this approach.)

The primary goal of Mozilla Education now and going forward is to help grow a new generation of Mozilla contributors by working with students and educators around the world. In the original Mozilla Education planning document we outlined another broader goal around promoting general innovation in education (“help to drive a new wave of participatory, student-led learning in fields like computer science, design and business”). As discussed in the progress report, we’ve since deemphasized that second goal and are now focusing Mozilla Education efforts primarily on the Mozilla project proper.

In the context of this discussion the term contributorcovers anyone who makes a significant positive impact on Mozilla worthy of recognition; this includes both technical and non-technical contributions, anything from doing heavy-duty Gecko hacking to helping out with marketing Firefox. Thus there are multiple types of students and educators who might participate in Mozilla Education, and multiple types of activities directed toward them. To provide a bit more focus, let’s follow the advice of one of the people who provided feedback and discuss 1) what has worked (and not worked) in the past and 2) how we might take what’s worked and establish scalable processes for the future.

The first thing to note is that the Seneca approach–integrating teaching of Mozilla technologies and practices directly into college and university courses–is proving to be somewhat replicable, with several schools and professors now teaching or planning to teach such courses. (See the progress report for a full list.) However the pure Seneca-style approach has some limitations, at least from the point of view of producing core Mozilla contributors: It has been successful in producing good contributors in such areas as build infrastructure and release engineering, but less so in terms of producing contributors who are hard-core Mozilla hackers.

In my opinion this is not so much a failing of the approach as it is a failing of academia: The schools that have been most open to integrating open source development work into the classroom (like Seneca) are the schools that focus more on practical instruction for job-seeking students. The high-end research universities that attract top-quality computer science students are the ones least interested in anything that smacks of vocational education.

Until and unless this situation changes, I suspect that the most realistic approach to growing full-time core Mozilla contributors (i.e., people who are good candidates for employment at the Mozilla Corporation or Mozilla Messaging) is as follows:

Continue to promote the Seneca approach to schools that are most likely to be receptive to it, and in particular try to target schools interested in teaching topics like quality assurance through automated testing, continuous integration, and other software engineering practices needed in large-scale projects like Mozilla.
For research-focused institutions, pursue a more lightweight approach of encouraging professors to have students do Mozilla-related senior projects and independent study, either based on self-generated ideas or based on tasks previously identified as being good student projects. Note this is lightweight only in the sense that it demands less of the school and its faculty; in practice this approach will be limited by the amount of effort existing Mozilla contributors can devote to helping students.
For recruitment of hard-core hackers continue to rely on recruiting students from top schools as Mozilla Corporation or Mozilla Messaging interns, outside the context of the Mozilla Education program proper. In this context it’s easier to justify the amount of time needed to bring such students up to speed.

Moving beyond the issue of growing new core contributors, a second topic is that of encouraging students to make technical contributions outside the context of the core Mozilla code. This could include working on Firefox or Thunderbird add-ons, developing web applications that make use of new Firefox features, working with the various technologies being prototyped by Mozilla Labs, and so on.

In the context of Mozilla Education the Processing for the Web project (based on processing.js) is the primary project of this type thus far, and is proving to be quite successful. Projects like this are somewhat peripheral to the core Mozilla activities around shipping new releases of Firefox, Thunderbird, etc. However they do get more people involved in working with Mozilla technologies and code, help to promote adoption of Mozilla products, and help support other Mozilla activities, whether technical or not. (For example, the Processing for the Web work could be used in the context of the “visualize the (open) web” project proposed as part of Mozilla Drumbeat.)

In my opinion doing projects like Processing for the Web is a useful and scalable approach for two reasons. First, it provides a common focus for lots of student work, so that the limited time of mentors can be leveraged across more people: A mentor can help many students at once, and students can help one another. Second, it leverages the time and expertise of people outside the project (in this case people like Al MacDonald who were already working on processing.js), further lessening the burden placed on core Mozilla contributors.

Are there other possible projects like Processing for the Web that could serve as a focus for student contributions? One possibility is a project around Dehydra, Pork, and similar code analysis and rewriting tools designed for large code bases like Mozilla’s. Like the Processing for the Web project, such a project could leverage an existing community of people outside of Mozilla, including developers working in the GCC project and others developing or working with advanced code analysis tools.

Another way to engage students is the design challenge approach pioneered by Mozilla Labs and then adopted in a Mozilla Education context for the Jetpack for Learning Design Challenge. Design challenges and similar contest-like events have proved successful at attracting student participants, including design students and others who are not programmers at heart. Keys to success include have a fairly tightly focused challenge, along with one or more expert mentors who can help the students realize their ideas.

Because they’re focused on leading-edge work not yet ready for incorporation into standard shipping products, the Mozilla Labs folks have some freedom and time available for running design challenges that other Mozilla core contributors don’t necessarily have. In the context of Mozilla Education running a design challenge would typically finding third party subject matter experts to help with the challenge, which in turns means that challenges would typically require additional funding over and beyond what the Mozilla Foundation spends on the basic Mozilla Education program.

With that in mind, here are my thoughts on how Mozilla Education should approach engaging students to contribute outside the context of the core Mozilla codebase:

Sponsor at least three projects in 2010 that can each serve as a focus for engaging larger groups of students:
- continuation of the Processing for the Web project
- a new project around tools for analyzing and/or rewriting code, leveraging existing work by Taras Glek and others and done in loose cooperation with the GCC project or others
- at least one other new project in an area yet to be determined.
Start at least one new Mozilla Education design challenge project in 2010, if (and only if) there is a suitable problem (e.g., one that doesn’t overlap with planned Mozilla Labs challenges) and funding can be found.
coordinate with Mozilla Labs to cross-promote Labs design challenges to the students involved in Mozilla Education activities, and vice versa.

Thus far I’ve primarily discussed engaging with CS students and others in related IT-centric programs. What about students in other areas, such as design or marketing? My feeling is that in 2010 at least Mozilla Education won’t play a major role in terms of growing core contributors in those areas, primarily because they’re outside the expertise of the main people working on Mozilla Education activities.

However that doesn’t mean that those areas have to be (or can be) ignored from a Mozilla Education point of view. One of the things we discussed in 2009 was the role of the proposed education.mozilla.org web site (currently instantiated as a set of pages on wiki.mozilla.org. We’ve pulled back on some of the more expansive ideas for what that site might become. However I do think it makes sense to use it as a central point from which students can find information on Mozilla activities of potential interest to them. That leads to my final Mozilla Education proposed activity for 2010:

Establish and actively maintain a single high-profile page (e.g., www.mozilla.org/education) that can serve as a portal to information about Mozilla activities of potential interest to students, including not only Mozilla Education material but also links to Mozilla Labs design challenges, student internship opportunities, etc.

Those are all my thoughts for now. If you have comments or questions about the above, please let me know. I’ll next boil this down into an actual plan.

Posted in education, mozilla

What's your favorite Mercurial extension?� Mine is the color extension!
It does all sorts of amazing syntax coloring for you, right on your consoles.� It basically makes all the diff outputs from hg colorized, and also modifies the status and qseries commands output to print the patch names in color based on their status.� And enabling it is as easy as putting the following two lines in your ~/.hgrc.� Of course, you can go all crazy and customize it all, but I find the default choice of colors mostly good (except for underlining stuff which makes them harder to read in my opinion.)

Yes, it doesn't simplify your workflow, and it doesn't really do anything cool, SCM-wise, but trust me, once you enable it and get used to it, you can never go back to the usual dull hg output on your console.

There are two items in my long todo-list that I can’t address properly before KompoZer 0.8 is released:

I won’t be able to work on these items before January 2010, so here’s a very quick how-to for add-on developers. I’ll suppose you’re already familiar with Firefox add-on development, or that you can read the related documentation on MDC.

Install DOM�Inspector

I’ve taken the Mozilla 1.8.1 DOM Inspector and adapted it for KompoZer 0.8. You can download it here: inspector-20091201.xpi

I’ve tried to make a quick port of Venkman but I’m not sure it works on KompoZer 0.8 (I confess I don’t use it at all). If you can help me with this, that would be very appreciated.

If you need other developer add-ons for KompoZer 0.8 (Console�, Event Spy, Extension Developer…), just let me know. If you can take the time to port these add-ons to KompoZer 0.8, that’d be even better. :-)

Set up a development profile

You should add these two lines in the prefs.js file in your profile directory:

The first one will show the output of dump() commands to the console. The second one will save you some significant time if your extension is in a separate window or in the sidebar, as you won't have to restart KompoZer to see your changes: modify your code and reopen your window/sidebar, your changes are reloaded.

UUID / install.rdf

As you may know, KompoZer 0.8 now has a specific UUID:
{20aa4150-b5f4-11de-8a39-0800200c9a66}

This new UUID will prevent many compatibility issues we had with Nvu add-ons. If you know some Nvu extensions that should be ported to KompoZer 0.8, just let me know and I’ll port them as soon as possible.

You can (should) use a readable identifier for your add-on, i.e. something like “myextension@website.tld” instead of a UUID.

Unlike Nvu / KompoZer 0.7.10 extensions, you can use chrome.manifest files instead of contents.rdf ones.

Overlay

If you want to add your extension to the “Tools” menu, I recommend to insert it after the “JavaScript console” item in your overlay file:

Warning: the ID “javascriptConsole” is case-sensitive. I realized recently that the ID is “javaScriptConsole” for Thunderbird, but it’s too late to change this ID now that KompoZer 0.8 is shipped in most Linux distros.

Getting started: LoremIpsum

This extension is the simplest I can think of: no locales and 10 lines of JavaScript. As such, playing with LoremIpsum should be the easiest way to get started if you want to develop your own add-on for KompoZer.

Another way to get started would be to adapt a Firefox or Thunderbird extension to KompoZer. Beware, KompoZer 0.8 is still based on Gecko 1.8.1 (= Firefox�2 / Thunderbird�2)…

Getting Help

As usual, the #kompozer channel is the best place to get some help for KompoZer-related issues. I’m usually online from noon to midnight, GMT.

In case you want to see, I took some screenshots of the interesting bits of installing and setting up Adblock Plus in Firefox on an N900. Here they are (they've all been scaled down by flickr - you can click and get the large size if you want the full resolutions ones):

When you tap on the most recent .xpi file, Firefox confirms that you want to install.

You get a couple of transient alerts over the course of installation, but this is the one the browser shows when it's done. You can tap on this to go immediately to the add-ons manager, or go later, at your convenience.

Firefox 3.6 & Mobile are just around the corner. Join us for an open house at Mozilla to get your existing add-ons 3.6 and mobile ready. We’ll have desktop and mobile add-on developers on hand to answer questions and help brainstorm new add-on ideas. And no worries, it won’t be all work and no play!

When: Next Thursday, December 10, 2009
Time: 6-9pm
Where: Mozilla Headquarters
What: Join us for food, drinks, pool and add-on fun!

We will have a scheduled maintenance window tonight from 5:00pm to 11:00pm PST. The following changes will take place:

Please let me know if you have any reason why we should not proceed with this planned maintenance. As always, we aim to keep downtime to as little as possible, but unexpected complications can arise causing longer downtime periods than expected. All systems should be operational by the end of the maintenance window.

Murali Nandigama: Please take time to show your 'Appreciation' when it is due ... Have you ever felt that you could have been appreciated for that big thing or the little thing you have done either because you are obligated to do it or because you volunteered to do it out of your own good will?

Did you take time to stop for a second and appreciate the people that surround your life .. be it your partner, kid, friend or colleague for what they are doing to make your life easier OR more importantly ... what they are NOT doing to make your life more miserable than what you are capable of doing all by yourself?

A little bit of appreciation goes a long way ... some times in ways that you never know could have existed .

Don't believe what I a said !!! then please LOOK at this beautiful example

APPRECIATION MAKES A DIFFERENCE

Trackback URL for this post: