Wednesday, April 16, 2014

Community and Volunteers

It was suggested that I cross-post this from mozilla.dev.planning onto my blog. This is in reply to a thread entitled "Proposal: Move Thunderbird and SeaMonkey to mozilla-central" about (essentially) merging comm-central back into mozilla-central. There have been many technical concerns raised in the thread (that I'm not going to rehash here). What I'm more interested in is the lack of community feeling there. As Nicholas Nethercote said in that thread:
"I am surprised [...] by how heartless the discussion has been."
I should note that I did have some help editing this down from my original post. Turns out I tend to write inflammatory statements that don't help get me point across. Who knew? Anyway, thanks to all of you who helped me out there!

My full post is below (with a few links added and plaintext formatting converted to HTML formatting):
On Monday, April 14, 2014 4:52:53 PM UTC-4, Nicholas Nethercote wrote:
> The technical aspects of this decision have been discussed to death,
> so I won't say anything about that. I am surprised, however, by how
> heartless the discussion has been.

I agree, the technical bits here seem to have solutions suggested by Joshua and others, but the non-technical parts of this discussion have left me feeling disheartened and confused with the Mozilla community.

I find it ironic/amusing/sad/upsetting that a few threads above this is a thread entitled "Contributor pathways, engagement points and bug mentoring" while in this thread I see community contributors being blocked at every turn!

Here I don't see people attempting to foster a community by putting their best foot forward. I see people trying to get their job done; with an attitude of "if this doesn't help me, get it outta my way!" I don't think this is the right way to grow a community. I don't think this is how Mozilla HAS grown it's community. I don't think it's in line with what Mozilla expects from it's community members (both employees and volunteers!)

Personally, I dislike the amount of Mozilla Corporation goals focus in this thread. Can we have a discussion as part of a larger community? Why must it focus on Corporate goals? I'm not part of the corporation, I don't really care what its goals are or are not. I care about Mozilla, I care about providing high-quality, free, open source software to improve the experience of the Internet for everyone. And no, I'm not talking about Firefox. I'm talking about Thunderbird. I understand that Mozilla's goals are currently Firefox and Firefox OS, but these are not my personal goals.

At the Summit I had a few conversations with people about "on-boarding" new employees and getting them to understand how the community works and that interacting with the community in a positive manner is an important part of Mozilla. I don't remember the exact context, but part of it was that it is important that new employees don't think of it as "How can I use the community?", for that implies taking advtange of them, but "How can I work with the community?"

Please don't see this as an "employees vs. volunteers" argument. I believe that I'm expected to live up to these same goals. If I, as a volunteer, can help an employee achieve his goals; I'm more than willing, no...I'm EXPECTED to do that. I think this is a two-way relationship that must be fostered. It has seemed to me that over the past couple of years that I've been hanging around here there's been less and less focus on the community and more and more on the Corporation.

I understand Thunderbird and SeaMonkey may not be important to you, but it is important to me! (And others who contribute to the Thunderbird/SeaMonkey community, including employees who contribute on their spare time.) When Mozilla stopped directly supporting development of Thunderbird it was widely announced that "Thunderbird is dead!". We, as part of the Mozilla community, have been fighting to prove this wrong. Could you please respect our efforts? Merging c-c into m-c will help us focus our efforts on building a great product instead of spending significant effort on keeping a dying one on life-support. (And prove to all that "Thunderbird is dead!" was just a sensational headline.)
I don't have much else to say beyond that (besides thanks for reading this far!)

Wednesday, December 4, 2013

GSoc Lessons: Part Deux: The Arms Race

This post title might be a little excessive, but I'll blame The Sum of All Fears that I was watching last night. This is the second part of a set of posts about ideas I heard at the Google Summer of Code 2013 Mentor Summit (you can read the first part about the application process).

This will explore an interesting anecdote I heard about the interaction between applicants from another organization that, on reflection, seemed to resonate somewhat with what I had seen in my corner of the Mozilla community.


The organization these students were applying to required patches to be fixed for a student's application to be accepted (as discussed in my previous post). For a particular project there existed multiple highly motivated and skilled students, but only one slot. Thus, a "patch race" of sorts occurred where the students competed by continually providing more patches that were increasingly complex. (Note that this wasn't a in response to a challenge from community members, it was a spontaneous situation.) Once a single student started to submit extra patches the other students felt they must also submit more patches to be considered equal/superior (hence my allusion to an "arms race"). Interestingly, they would also sometimes work on the same bug in a sort of race to see who could fix it first.

There's a couple things I took away from this:
  1. Great, the project just had a lot of things fixed!
  2. The students were investing escalating amounts of time during the application phase.
  3. The students were not working in an open manner.
I won't really expand much more about the first point, it's always good to fix things.

Although submitting patches might showcase a student's skill, it also relates to how much time the student is willing and able to put into the application period. This, in particular, matters since different areas of the world end their school year at different times. A student that has already finished his semester during the application period may have a lot of free time to attempt to get a GSoC slot (but will most likely not have as much time during the actual summer!) This something that mentors should keep in mind while reviewing applications.

A downside of increasing amounts of time invested is that the rejection is that much harder for both the mentor (especially if the student is now part of the community!), as well as for the student who has now vested a large amount of time in the project.

The realization that actually upset me, however, is that these students were not working in an open manner! Instead of collaborating, they were competing! To me, this would set off a very poor tone for the rest of GSoC. In fact, one of the biggest challenges I've had with GSoC students is getting them to work in the open (i.e. "show me the code", anyone in #instantbird is probably tired of hearing me say that).

At this point you might think this is a hypothetical case I made up! Upon letting it sink in and reflecting on it...I realized I had actually seen similar situations during the application periods I've been involved with. This year, we found a bug in Instantbird's IRC code (CTCP quoting and dequoting); after referencing some specifications, I was pretty quickly able to figure out the vague areas where people should look for a fix. A couple of GSoC students in the room started looking into it and exhibited a greatly reduced form of the behavior I discussed above. The students were sharing information, but were not comfortable sharing code. Unfortunately, this led to some very vague questions which I was unable to answer (or answered incorrectly) and led to me coining my catchphrase from above.

I by no means think this reflects poorly on our students! I think this is some what natural and expected for most students unfamiliar with open development. (Extrapolating from my experiences in school...) Students generally work individually (or in small groups) on projects and are directly competing for grades (at least if the course is graded on a curve). This would foster a sense of competition as opposed to cooperation! Luckily the students working with us understood (with very little prompting, I might add!) that we'd prefer they work together and help each other. We were able to successfully fix the dequoting bug (which then caused a bug in the quoting code to be visible...sigh...).

My short take away from all this: remember that students are not yet a community and they're competing with each other until they've been accepted. (And that they're used to competing, e.g. homework and exams, not collaborating!) I don't really know whether I feel the above situation is good or bad, but it's certainly an interesting effect from the way the GSoC process works.

Monday, December 2, 2013

GSoC Lessons: Part 1: Application Period

I briefly talked about my experiences at the Google Summer of Code 2013 Mentor Summit. I've been pretty remiss in sharing what was actually discussed there and for that I must apologize! This will hopefully be one of a few posts about what I learned and discussed at the Summit.

The first part I'd like to talk about is the application period: welcoming students, requirements for student applications, etc. Much of what I say on here is just ideas I've heard other organizations implement (with my personal opinion on them, please don't think this represents what Mozilla is suggesting students do, or even what I'm suggesting Mozilla should ask students to do!)

I had many separate conversations about what is required for an application to be accepted. It seems that Mozilla is actually on the side of one of the easier organizations to apply to. We don't (to my knowledge) require that students have contributed at all to the community beforehand. It is possible that some smaller communities inside of Mozilla require more than just an application, but there does not seem to be any rule across Mozilla. I said I wouldn't offer my opinion above...but I lied: I think Mozilla should make it clearer to applicants what is expected of them before the application.

There seem to be a variety of things different organizations "require" before accepting a student application, for example:
  • A patch / pull request
  • IRC / email involvement / idling
  • File a bug (I mean this in the "Mozilla" sense: an actual bug, a feature request, etc.)
  • Fix a bug / make a commit
I think all of these have pros and cons and making any a hard and fast rule would probably be a bad idea. Personally for Instantbird, we greatly encourage students to idle on IRC and get to know us; and to fix a minor bug or two or three. What I'm always looking for is: use, passion, and skill.

Asking for a patch / pull request (I include these together since they really just depend on how an organization accepts changes) can be a bit intimidating for a new user. I think this can be a pretty rough thing to ask for new contributors that might not want to share their work publicly with a large group of people (on a mailing list, public bug tracker, etc.) where they might be wrong. Even after being part of the community, I find that GSoC students are often very unwilling to publicly share code unless it's "perfect", but I digress. Anyway, if you're considering "requiring" this, I think it should be pretty clear that this changeset doesn't need to be perfect, it just needs to show that the student is able to read code, understand a bug report, provide a fix and test it.

I think it's perfect reasonable to ask students to idle on IRC and join mailing lists. They should definitely be trying to understand the community before attempting to join it. It isn't just a matter of if the community thinks the student would be a good fit, but also the student must ensure they can fit into the community.

Filing a bug is a great way for a student to show a few different things: they've used your software; they've used your software enough to find a bug in it (and there most likely is one!); they're able to express themselves in a clear and concise matter. If you're lucky they'll find something that actually annoys them and fix it themselves!

I have fix a bug listed last. You might ask how this differs from submitting a patch...and it does! Fixing a bug requires a patch to go through whatever review process your project uses, but builds upon just submitting a patch. My thoughts on this are pretty similar to just submitting a patch, but it depends on how large the bug is.

Something I found interesting is that almost everyone I talked to didn't treat their GSoC students any differently than they would treat a new contributor to their project. They still had to prove they were worthy of commit access, etc. Is there anything else you ask of your students before they apply to GSoC? I'd love to hear it!

Some other topics I'll hopefully find some time to write about include: community lessons, and handling a failing student. The community one will be very not-GSoC focused and could apply to just trying to incorporate new contributors...but I'll include it in this series.

Sunday, October 20, 2013

Google Summer of Code Mentor Summit 2013

Not only was I lucky enough to mentor a great student for this year's Google Summer of Code, but Mozilla asked me to represent them at the Google Summer of Code Mentor Summit!  This was located at Google's offices in Mountain View, California this past weekend (Friday, Oct. 18th - Sunday, Oct. 20th, 2013).

Before actually heading over to the Summit, Myk Melez and Nick Desaulniers were kind enough to show me around the Mozilla Mountain View office!  (Thanks to Daniel Holbert for setting that up!)

The GSoC Mentor Summit is run as an "unconference", the open sessions were chosen by conference attendees and run as discussions with no keynote speakers.  This was an interesting experience and how good each session was varied quite a bit by who was taking part in the discussion, but overall it was great to hear the experiences of other projects with their GSoC students, as well as to hear about lots of projects I had never heard of before!  In general the session I attended were about community building and managing GSoC students, I took lots of notes and will digest all of this in further detail at some point.

I was able to meet lots of great people from different projects, just a few of which were: Pidgin, Debian, Buildbot, the Open Lighting Project, the Tor Project, phpBB, etc.  Unfortunately being from Mozilla, most people already know what you do...or they think you do at least!  Many people were surprised when I said I work on Thunderbird and Instantbird.  I heard "Thunderbird is dead" at least twenty times, which was quite disappointing that those in the open source community don't even understand the current status of Thunderbird.  Many were happy to hear that it is still being maintained and developed by the community, however.  I even had some people thank me (which I don't really deserve) for helping to continue maintain Thunderbird!  It was great to hear things like this at the Mozilla Summit, but it was really invigorating to hear people outside of the Mozilla community excited that their favorite email client was still being developed.

People were further surprised to hear that Thunderbird now includes instant messaging / chat (since Thunderbird 15 or 17) and that there is a Gecko based instant messaging client: Instantbird.  It seemed like some people were excited by this and hopefully they'll try it out!

Anyway, I've gone a little off-topic, but overall the Mentor Summit was great and I'd like to thank both Mozilla and Google for giving me this opportunity.  If I find any really great gems in my notes I'll write further blog posts about them.

Sunday, October 6, 2013

Yahoo Protocol Google Summer of Code Round-up

I have to apologize to my student, Quentin (aka qheaden on IRC), for taking so long to write this...but anyway: Google Summer of Code 2013 is over!  Quentin has done a great job working at implementing the Yahoo Protocol for Instantbird (and Thunderbird) in JavaScript (henceforth called "JS-Yahoo").  It's at the point where it has mostly reached feature-parity with the libpurple plug-in.  Before turning this on as default there are a few minor bugs that still need to be fixed, but most of them have patches that just need another couple iterations.

Where do we go from here?  Once the last few bugs are fixed we'll enable Yahoo by default in the nightly builds and, assuming we have no issues, it will be enabled by default in the upcoming Instantbird 1.5.  If there are no major issues in 1.5, we'll remove the libpurple Yahoo implementation for Instantbird 1.next.

How do I try this now?!  You can already easily enable JS-Yahoo in Instantbird nightly builds:
  1. Type /about config in a conversation tab's textbox
  2. Type "forcePurple" in the search box
  3. Remove "prpl-yahoo" and "prpl-yahoojp" from this comma separated list of values (you can also remove prpl-jabber if you want to always use the JS-XMPP implementation from GSoC 2011! Note that this doesn't support DNS SRV, however.)
  4. Restart Instantbird!
You should now be using the JS-Yahoo protocol.  Hopefully you don't notice anything different, but PLEASE file bugs if you see any issues.

How come I can't use this in Thunderbird?!  Because Instantbird and comm-central development don't happen in the same Mercurial repository.  I'm working on syncing the chat/ folder of these repositories currently and JS-Yahoo should be in Daily soon to be included in the next Thunderbird release (i.e. Thunderbird 31).

The whole Instantbird community has been super happy with the progress Quentin made and we hope that Quentin has learned a lot! Thanks for a great summer qheaden and hopefully we'll see you around still!

Friday, June 28, 2013

Mentoring Google Summer of Code 2013

I'm officially a mentor this year for 2013's Google Summer of Code. I'm a bit late on posting this, but oh well! My student this year is Quentin Headen who is working on a Yahoo! Messenger protocol for the Instantbird chat/ backend (so it'll also be usable via Thunderbird). You can see an account of his trials, successes and trepidations (RSS) or follow his code repository. He's made great progress so far and is able to connect, download all the buddies and start private conversations! Not too bad for a few weeks of work! We've been keeping a TODO list of things to be supported, please don't edit it without discussing it with us first.

Our hope is to get this checked into Instantbird by the end of summer and run it in parallel (behind an about:config preference) with the current libpurple Yahoo implementation. Once we're satisified that it has feature parity we'll remove the libpurple version and enable this by default!

Instantbird is also supporting two other projects:
You can find any of us in #instantbird on irc.mozilla.org, my nick is clokep, Quentin's is qheaden, Nihanth's: nhnt11, Atul's: atuljangra, Benedikt goes by Mic and Florian goes by something starting with "flo".

Thanks also go out to Mozilla for letting us participate in Google Summer of Code with them again! You can see all of the accepted projects in Gerv's blogpost.

Monday, May 20, 2013

Instantbird 1.4 Released!

After a bunch of l10n build problems, we've finally released Instantbird 1.4, which includes updates to libpurple 2.10.7 and Mozilla 20.  In particular this includes:
  • Updated Twitter code that uses v1.1 of their API (v1.0 will be disabled on June 11th, 2013).
  • Better character counter for Twitter (it now takes into account if URLs are embedded).
  • Updated log viewer which organizes logs by date (and nests them by week, month, etc.)
  • Better support for IRC bouncers.
  • Support for overriding self-signed/invalid/out-of-date certificates for IRC.
If you've been using some other instant messaging client (e.g. Pidgin or Adium); I'd highly suggest giving Instantbird a try, especially if you also go on IRC. Instantbird has great IRC support! (And...if you do have issues, feel free to ping me in #instantbird on irc.mozilla.org and let me know what your issue is.)

You can download it here, or view the full release notes.