The roads I take...

As mentioned earlier, I recently stopped contributing to the progress dialog code that I wrote myself. Based on things I experienced and learned there and in other cases, I decided to write a guide for losing contributors. Completely losing someone like me is unfortunately hard, I did step back from this part of code but that's all.

It's much easier to completely get rid of non-core contributors or people working on only one part of the project, and those are what this 10-point guide is about.

1. When the contributor works on a major feature (like, says a download manager frontend rewrite on a new backend), make sure you require all dependent feature parts (like progress windows) to be implemented before any of the work of that contribution can land. People hate to have their code sitting in Bugzilla patches for a long time and needing to do a lot of additional work, especially on parts of code they usually do not use themselves. You need to take advantage of that.
2. If the contributor blogs or otherwise write messages about his work, make sure you have people around who take every attempt of humor (e.g. "Progress Dialogs? Eww!") as dissing the feature, criticize every single change to previous behavior as destroying that feature, the project and possibly the whole world. Take down any motivation he has to do further work in that area - that's imperative.
3. Have users bitch heavily about the work, esp. about the shortcomings the contributor himself knows about and make sure no alternatives, short of killing the contributions and going back to old code, are provided.
4. Very importantly, do care that no single appreciative word - let alone a "thank you" - is ever being mentioned about that specific contribution. Also don't make constructive comments about how to further improve things by staying true to the made contribution. Both could encourage the contributor to stay with the project and do further work on this code, which is exactly what you want to avoid.
5. If he is starting work on further improvements even after all that, make sure people post in the bug about all kinds of problems they have with the general approach, have people post patches to at least partially revert the work the contributor did in the first place and ones that go against his overall design, and refrain from having any constructive proposals on how to do actual improvements in line with the overall design.
6. If he makes multiple suggestions on how to improve things, chose the one he states to like least and successively criticize what he stated to not like as a problem in reviews.
7. If a constructive suggestion for improvements comes up nevertheless and is a graphical mockup, it should contain some icons that are not available in a license compatible to the MPL/GPL/LGPL tri-license used in code. The Public Domain Tango icons (which could be used) should be as far as possible from the wanted look, and the well-matching ones from the mockup should be from e.g. Crystal (LGPL-only) or Oxygen (CC-by-sa/LGPL/CC-by-nc-nd) icon sets to make sure they can't just be integrated the way they are in the proposal. Don't make it easy for the contributor to follow a suggestion.
8. If he decides to re-draw the icons himself to follow licenses and some icons already available in your application, and even contributes the SVG his drawing software did spit out (even if the code itself doesn't work with the SVG), then it's imperative to nitpick the source markup of those images, ignoring that only their rendering to bitmap images appears in the application. Ideally, have someone from your team rewrite them with said-to-be-better markup and different colors so any of his artistic creation is disregarded, his contribution mostly neglected and you make sure he can't take pride in any of his creation.
9. When the patches come together - if you can't get rid of him before that - and get their first rounds of review, make sure someone comes in with a comment about how much he likes the previous design that had been agreed to be flawed and need improvements up to that point.
10. In reviews, be as nit-picky as possible, don't let code in that isn't almost perfect, require coding standards that are different to everyone else around, esp. from usual Mozilla platform code, and never say thanks for the done work.

In short, make it as inconvenient as possible for the contributor to work in this environment, the Mozilla code base surely isn't scary enough by itself. The contributor should never have fun, and if he would at some point, make sure it subsides fast. Make sure he wants to cry over every single comment made about the area he is trying to work on.

Note that many of those factors may happen by themselves and you as core developer in the project may not be able to influence all or many of those factors. Also note that this is not supposed to be a rant about what happened to me in the progress window project, if it would be, I would write it differently, and some of the points above would be exaggerated. This is supposed to be a guide on how to get rid of outside contributors - or an ironic view of things to try to avoid if you don't want to lose them - whatever version you like or applies to you better.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 07/2010 (February 15 - 21, 2010):

• Releases:
  Released SeaMonkey 2.0.3 on Wednesday - finished up release notes, pushed files, updated the website, created and sent announcements, pushed update snippets to the release channel. Everything seems to have worked fine there and people should have a better SeaMonkey 2 now.
  Unfortunately, my website updates caused a temporary website glitch but I could fix it fast when it happened.
• Build Infrastructure:
  After we dropped 1.9.2 and I turned off the experimental builds we had running with that tree, I turned on Mac and Windows debug builds instead, I found a slight infrastrcuture issue with this and created a patch for that issue.
  Most of the new Mac machines are here and working now, I integrated them into the build pool and they are working really fine - faster than any other Mac machines we have!
  I could also turn on the first few tests on trunk after those machines joined, and it looks like Mac is (mostly) consistent with Linux there.
  One of the new machines still is not really available, once that is online, we'll drop the old VMs and replace them with more Linux and Windows machines on Parallels.
• Places:
  As I did the initial work to get places history to work in SeaMonkey, I feel some affinity with this module. I had done a patch for the new expiration changes earlier, and now as we're only supporting 1.9.3 and higher on trunk, I could land that patch finally.
  I also started to look into places bookmarks support and promptly found that HTML import/export is Firefox-specific code right now, but me and places developers agreed that it should move to toolkit. My current local work is mostly ripping off large portions of Firefox code, the cleanup parts will come once things mostly do actually work.
• Build System:
  I filed bugs on killing 1.9.2 support after we made that decision, and like so many other build system work recently, Serge came up with patches for those. I also reviewed a few build system patches, most of them again from Serge, but including a few others, like OS/2 packaging support.
• German L10n:
  Michael Opitz did another help fix which I could check in.
• Various Discussions:
  2.1 decision for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, upgrade to 2.0.3, web form management, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, (not) branching comm-1.9.2, "human-readable" pushlog feeds, etc.

After the SeaMonkey 2.1 Gecko decision, I think we're now on a good way to getting actual progress on our code for this next version. Following the platform, we unfortunately will have to drop support for Mac OS X 10.4 "Tiger" as well in that release, but we hope that Mozilla 1.9.1 and therefore SeaMonkey 2.0.* will be maintained long enough to get a large amount of those users transition to newer systems - if they can't afford new hardware, they should possibly look into converting their system to Linux, which is being maintained and which we can support more easily as well.
While we can't change those platform decisions, we can change our own code, and we are currently starting to work on more and more parts of it for this future version - and your help is wanted to improve it even further!

I reported on SeaMonkey 2.1 planning earlier and also about the fact that we have been unsure if we should go 1.9.2 or 1.9.3 in terms of the platform there.

I sent mails to the SeaMonkey Council and a few quite active developers in the last days, and asked for opinions on dropping support for 1.9.2 and going for firmly basing SeaMonkey 2.1 on Mozilla platform 1.9.3 instead.

Nobody was really against that, and most people were firmly or mostly supportive, so that we decided to go for this.

With this, the suite directory and application on comm-central will only support 1.9.3 from now on, and SeaMonkey will not support 1.9.2 at all.

We will be erroring out for --enable-application=suite builds when a Mozilla 1.9.2 tree is in use, and also remove 1.9.2 ifdefs from the suite/ directory in comm-central.

This only affects SeaMonkey-specific code, of course, and Thunderbird will be going for 1.9.2 as main target from the same comm-central tree, so any shared code needs ifdefs to deal with 1.9.2 vs. 1.9.3 until we branch comm-1.9.2 some time in the future.

We hope we can work towards a good SeaMonkey 2.1 release with improvements in features and be able to close the gap to Firefox by releasing closer to their next final release. Scheduling for both those releases is still a bit unsure, but we'll see more about that once we get a clearer picture of what features we can get in and what state we're in for delivering something stable to users (that's true for both Firefox and SeaMonkey).

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 06/2010 (February 8 - 14, 2010):

• Releases:
  SeaMonkey 2.0.3 preparation moved along with copying builds to the right locations, creating checksums, etc.
  We haven't heard of anything bad from beta-testing this release, so we are on course for a release on Tuesday, February 16.
• Build Infrastructure:
  This week it was mostly maintenance of the build pools, but it looks like data on graphs server and new Mac machines are coming near to getting finished now, esp. the latter should give us a good boost in what our pools can do (moving Macs from VMs to real machines frees up some space for Linux and possibly even a Windows machine, which we can put up then).
• Download Progress Windows:
  I put a number of additional hours of work into improving progress windows, but finally threw everything away after I encountered just too much stop energy. I felt an obligation to finish the job on those progress windows after I started it and saved their lives in the needed rewrite for 2.0 when the old implementation wouldn't work with the new download manager backend and we needed a new one. After being cursed, damned and nitpicked up to a point where it not only was no fun any more but also was starting to really depress me, I decided that someone else should care about it.
  I had done some work on a further progress window bug but also unassigned that from myself following that decision as I have wasted all my potential to deal with stop energy regarding that part of the application.
• Build System, Packaging:
  I verified or marked two more bugs as fixed that have been resolved by my package manifests merging. Good to see that this went well.
  As a followup, the OS/2 people are getting the manifest for SeaMonkey to work as well, I had some discussions about review and improvements for their patch in the bug.
• Various Discussions:
  Out-of-process-plugins for SeaMonkey, 2.1 planning discussions, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, KompoZer integration work, official listing for comm-central build system module, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, (not) branching comm-1.9.2, automatic delivery of SeaMonkey statistics from Mozilla Metrics, etc.

As told above, progress windows have been a quite disappointing story for me, putting in many, many hours of work for saving a feature in SeaMonkey that nobody else still has and getting almost nothing but stop energy in return. I've been thinking about writing a "how to lose contributors" guide as a blog post, as right in that work we nicely did sum up a number of good mistakes to make if you want to get rid of people who are willing to help. Of course, it won't drive me away from the project as a whole and I can take quite some beating from some time, but in the end, some minor stuff was enough to drive me over the top and throw the towel on that single part of the app. And guides for "how to make things wrong" always make a better reading than advice for how to do it correctly, esp. as there is no single correct way, but a number of wrong ones.
So, keep reading, I probably will write that one up soon here on this blog!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 05/2010 (February 1 - 7, 2010):

• Releases:
  I prepared SeaMonkey 2.0.3 builds, which are now available on FTP as well as the beta update channel for testing by our community, offering well over 100 bug fixes. If things go well, we should be able to release this update in sync with Firefox 3.5.8 on February 16th.
  The 2.0.x nightlies now carry a 2.0.4pre version number, but we have no firm schedule for the following updates yet (will coordinate with Firefox, possibly also Thunderbird drivers on that).
  Work on 2.0.3 also included putting up a first version of the release notes.
  I also tried to let the release process generate 64bit builds for Linux this time, those are fully experimental and will only appear as "contributed" builds though, they have no official status at all.
• Build Infrastructure:
  The move of our core buildbot master code to a shared location could be completed, Thunderbird will look into using the same code in the future and we closely mirror the Firefox setup now, making it easier for people patching their side to fix ours as well (and the other way round).
  Revision reporting on packaged tests is now both generic and respecting applications that are built from different repositories as the platform (like SeaMonkey or Thunderbird).
  Additionally, I continued working with Mozilla teams to get SeaMonkey data up on the graph server, which needed a firewall rule and a correction on the staging server's database, but testing looks good now and we should be able to go live on the real server soon.
• Download Progress Windows:
  I created screen shots of some additional proposals for improving the progress windows, requested ui-review on them to see which one wins out with our "UI tsar", and finally implemented the winning proposal in a patch, which should be very close to positive review by now.
• Build System, Packaging:
  After a few runs on the Mozilla Messaging try server, I could finalize the patch for merging our package manifests and also make Mac use a manifest, get reviews and check it in.
  Another patch I worked on is about making branding usage fit Mozilla standards more closely, which should also ease the life of people wanting to ship suite versions with a different branding than the official "SeaMonkey" trademark designs.
  Some discussions about build system variables reminded me that I should re-test and attach the papering-over patch for mailnews Qt port bustage which I've had locally for quite some time now.
• SeaMonkey L10n:
  Starting with SeaMonkey 2.0.3, the language packs are marked compatible with all 2.0.* versions.
  Also with this release, Japanese is joining the collection of officially available localizations.
  This was also the first time I played with and used the new L10n sign-off dashboard for a release - further opt-ins / sign-offs for SeaMonkey 2.0.x will all run through this tool now. See the m.d.l10n thread for more details on using this tool.
• Various Discussions:
  2.1 planning discussions, Alpha 1 and further steps for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, KompoZer integration work, new machines, FOSDEM, places history changes, module ownership, mozilla.org planning and "Mozilla" vs. "Firefox" websites, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, langpacks and switching, etc.

I may not have posted a lot of Mozilla-related blog posts this week, but I got around to do quite some actual work. I wondered for a bit if I should post separately about the progress window work, but the ignorance of hard work I have been and am putting into those tiny windows as well as the vitriol from people who can't stand designs being modernized made me decide not to mention this work much. I know that it needed my work to even have progress windows at all in SeaMonkey 2.0 and I'm convinced that my current proposals and work can fix some of the shortcomings I had already know when doing the initial work and that were criticized by users, but a number of those users seem convinced that our team (especially myself) is not caring about what they say at all, so I don't feel like taking their dreams away. And the attempt of humor in the title of my post about the initial work was not well-received as well. In any case, I feel an obligation to improve work I started, but discussions with those users have taken any fun out of working on this part of the code. Maybe my rare tries of actually doing some coding should stay that rare or even stop completely. It's not like I wouldnj't have enough other work on my TODO list.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 04/2010 (January 25 - 31, 2010):

• Build Infrastructure:
  I installed a newer gcc on the Linux machines and started using it for trunk builds. Additionally, I synched our mozconfig files for trunk much more to what Firefox is running on trunk as well.
  Because I might be a bit crazy and like to put our machines under more pressure than they should be under, I even tried to turn on one additional test suite on trunk to try and find bugs to fix.
  I also helped Armen from Mozilla release engineering to get his current L10n build work into a shape so that it works fine with SeaMonkey/Thunderbird builds as well.
  Last not least, I filed a bug on disappearing Windows slaves - seems like we've overused the space available on our Parallels server.
• Packaging:
  As we want to run packaged tests on Mac some time, we will need to turn on tests on normal builds there, but need to care that the test files don't end up in file we deliver to users. That and us probably being the only ones who haven't done it yet was enough motivation for me to finally look into merging our package manifests and use one preprocessed file for all (three!) main platforms. I got all the way to having the "browser" section complete, based on the Firefox manifest and our current Linux/Windows ones, now I just need to do the sections for mail and all the other stuff we don't nearly have in common with Firefox - and then get this sucker tested and reviewed!
• Support Emails:
  Even if I tell people that I'm not the person to contact for support, a number of emails about that topic end up in my mailbox nevertheless, some directly, some via seamonkey-council. I tend to move them into a folder and batch-handle all of them every few weeks - or rather months. This week, it was time to do such a pass again, and I sent about 70-80 replies to them (I try to leave nobody without an answer), even though most of those are just one sentence and a templated section to look at our community page to find better and more responsive soruce for support.
• Various Discussions:
  2.1 planning discussions, Alpha 1 and further steps for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, YouTube and "HTML5 video" vs. Ogg, geolocation service options, new machines, getting codesighs and leak test data on graphs server, KompoZer integration work, L10n dashboard and sign-off, future add-ons UI, etc.

A good part of this week did run into various discussions and more buildbot tweaks, things are moving forward positively from all I'm seeing - we just need to get some more real development done on trunk, even though that slowly starts to pick up now. Any help to make SeaMonkey 2.1 an even better suite than 2.0 is appreciated, of course!