Get the Band Back Together

In my many years as a consultant (prior to my start here at the Eclipse Foundation), I worked with more organizations that I can reasonably count. My feeling is that I have provided a lot of value to the groups that I’ve worked with. Depressingly, though, I feel that some of my greatest successes as a consultant have very little to do with my fantastic abilities to manipulate technology to implement my will on the world. My greatest successes have had more to do with getting folks to actually communicate with each other.

I recall one engagement with a rather large company where I called a meeting of all concerned parties. During the meeting, I had each party do a presentation describing the contributions they were making to the project. Without exception, after each presentation, somebody from some other group told me they were surprised by some part of the presentation. It was clear that, while there was some communication between developers at the lower levels, there was virtually no communication at the higher levels. Nobody really knew what, at least at the higher level, what everybody else was doing.

After going through this exercise a few times, I started to refer to it as “getting the band back together“.

I catch myself thinking about these sorts of engagements every time I think about the Eclipse review process. At least I to now. It was something that David Williams said to me in an email that formed this connection…

We have reviews for just about everything. There are obvious reviews, like creation, release, graduation, move, and termination reviews. There are other less obvious ones as well. For a review, a project lays out what they want to do and why it’s important. This gives the community a chance to better understand what’s happening and get involved in the project (at least in some small way). Unfortunately (or fortunately, depending on perspective), the word “chance” is carefully placed here. We have the chance, or opportunity, to get directly involved with a project. We have the opportunity to ask questions during the review. We have the opportunity to involve ourselves. Normally, however, very few people actually avail themselves of this opportunity.

So… this leads me to wonder if the review process is just plain silly. Why build review documentation (or “docuware”) when so few people from the community will actually read it?

Here’s where the connection that David made for me comes into play. The process of building the review documentation forces the project leadership to capture, at high level, just what the heck they’re doing. At least for many projects, this is something that they don’t do on an ongoing basis. Without clear direction, a project can wander around aimlessly, ultimately resulting in failure. Periodically taking stock of just what the heck you’re doing—ensuring that the ongoing work aligns with the scope and goals of the project—is good for the overall health of the project.

So… if nobody else read your docuware, you should at least make sure that everybody the the project does. While you’re at it, you should make every attempt to ensure that your community knows as well: post your review documentation on your newsgroup.

While I’m at it. What do you think about the form of the review documents? I’m of the opinion that presentations aren’t the right format for them. Rather, it seems to me that an HTML document, or perhaps even a wiki page is a more appropriate mechanism (although the wiki page might be a little too open for these purposes). How about setting something up in the portal which will provide projects with a form-based mechanism for gathering (only) the relevant information? I’d love to hear your thoughts on the topic.

This entry was posted in Community. Bookmark the permalink.

2 Responses to Get the Band Back Together

  1. Dave Carver says:

    You might want to take a look at Joomla, Drupal, or other CMS system for use as the Eclipse Portal going forward. Yes I realize there is a lot of customization work that has gone on, but that is both good an bad. Where I work we are starting to migrate our Members site to a Joomla based system. It allows for a very easy project management, and content management system with out the overhead of uploading Binary documents where formatting could be messed up. It also provides a simple WYSIWYG editor.

    I rarely go into the current eclipse portal unless I have to, it doesn’t have the features I think are necessary for a good portal. As for the review process…people won’t say anything unless it directly affects them. Notice the ATF review…until that was threatened with termination, nothing was happening with it.

  2. Nick Boldt says:

    +1 for wiki format. If you want a “static” version, we can print the wiki to PDF and keep a snapshot that way, though the wiki itself stores history too.

    -1 for putting anything in the portal. It just sucks. I agree w/ Dave that reusing someone else’s CMS is better than custom stuff – this is why I’m throwing away 4 years of custom web UI for doing builds, to be replaced w/ Hudson. Outsourcing is the only way to go, if you don’t want your day job to be maintaining that custom code.

    Personally, though, I’m not sure we need the overhead of all these unattended reviews. I’ve been running the Athena Common Builder project since June, and all our docs re: statement of intent, project scope, where to get sources, plan items, and bug tracking are in the wiki. How would having gelled this into some slides in advance have helped?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s