Since joining Red Hat, I've been working with an amazingly distributed team scattered around the world. I work with engineers in Beijing, Ireland, Switzerland, the United States, and more. To simplify communication we use JIRA, e-mail, IRC, and instant messenger clients to keep in touch and on task.
This talk focuses on some of the Eclipse technologies we use and others we've looked into using to help us deal with the distributed nature of our environment - from using the Eclipse IDE for development and the JIRA connector for Mylyn, to potentially using ECF to manage our various chat-like communication channels, and other technologies that came to light.
Brian Fitzpatrick (aka "Fitz") is a software engineer with Red Hat, Inc., who has contributed to the Data Tools Project (DTP) since its inception. Until recently, Brian's focus has mainly been on Eclipse tooling development for Sybase. This past year he joined Red Hat and has been working on cool SOA tooling. He hopes to continue helping out with DTP and elsewhere in Eclipse for the forseeable future. Currently he serves on the DTP PMC as well as as being the Team Lead for both the Connectivity and Enablement sub-projects within DTP.
Since joining Red Hat's truly global workplace in 2009, I've been struggling with how to deal with keeping in contact with team members around the world. What we'll cover today is a bit of the problem I deal with regularly, what we currently do, and some of the Eclipse technologies I'd like to see us develop as solutions.
My name is Brian Fitzpatrick. You may have seen my name around the last few years as a member of the Data Tools Platform (DTP) team – or you may not. :) I was with Sybase for 13 years before recently jumping ship and joining Red Hat in the middle of last year to help out with some of their SOA tooling. I've been dealing with some sort of distributed team since joining DTP back in 2006,
At Sybase, I was dealing with folks on the East and West Coasts of the United States, in Colorado, and in Shanghai, China. So I was only dealing with a few different time zones and it wasn't too difficult juggling e-mails and meetings.
When I started working for Red Hat in June 2010, I was thrust into a whole different world... Denver to Switzerland, Ireland, Beijing/China, Minsk, Massachusetts, California, Georgia, Japan Truly a global view of software development.
- Who among you works with people in multiple states regularly? - Multiple countries? - Multiple time zones?
On average, I chat with developers in Ireland, China, and Switzerland daily. From my timezone in Denver, that's up to a maximum 15 hour difference. We truly live and work in a global economy.
Though English is a common language for technical purposes, it presents some interesting challenges at times for non-English speakers. And I have to say I'm your typical ignorant American as far as languages go. Though I've had some Spanish and French, I'm primarily English only. I have a lot of respect for the international community and their gift for knowing multiple languages. For example, I would not be able to speak Chinese without years of work and don't know how some of our Beijing developers are able to coherently speak to us on a regular basis. That said, accents, grammatical differences, transmission issues, and so on make speaking over the phone sometimes impossible. To counteract that problem, we do a great deal of what we do over e-mail, Wikis, the web, and instant messaging. Written conversations seem to translate more easily for everyone involved most of the time.
We often have to share sets of steps or UI behavior between developers, QE resources, product management, users, and so on. Among the tools we've seen used are Camstasia and Jing, which are Windows or Mac-based and don't run on Linux, which many of us do development on. The backup to screencasting is to write out a set of steps and do screen captures, but that often is confusing and difficult to put together in a Wiki, document, or PDF.
The last major hurdle we face regularly is when we share patches via our bug tracking software (JIRA) and do code reviews. As spread out as we are around the world, it's difficult to do a quick code review in all cases simply because you need questions answered or suggest changes and the time delay presents a challenge.
We live in our bug tracker (JIRA), on mailing lists, plain e-mail, IRC chat, and Wikis. Wherever possible, we encourage folks to create and share screencasts, patches, .log files, console output, and document steps as specifically as they can so we can reproduce issues, investigate further, and provide feedback or fixes.
Not everything gets shared consistently across all mediums and we end up repeating things. Not everyone can follow the conversation because it takes place in multiple places that aren't necessarily logged regularly or shared across the board.
ECF - consistent instant messaging from within your development environment Bug Trackers - better and better integration with Bugzilla and JIRA will aid developers across the board Code reviews - the new Mylyn Reviews project announced in December 2009 would integrate with bug trackers and allow more interactive review cycles Multiple Source Code Control Options - CVS, SVN, Git offer better, simpler integrations for developers
- Simpler UI models for ECF Contact & Connection Management (pretty simple) - Built-in logging and log management (search capabilities) for ECF chats (pretty simple) - Screencast/screen capture tools better integrated with Eclipse IDE (not so simple) -- Already some work done for doing screen captures over XMPP in Eclipse 3.3/3.4 (http://wiki.eclipse.org/Screen_Captures_over_IM) - Something along the lines of Google Buzz or Google Wave where multiple people can contribute to a conversation in real time or with time shifting and the threads can be kept consistent - unlike with e-mail sometimes or IM or social media (probably hard) -- An ECF provider for Google Wave is in the works for Helios (https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347)