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.
