This is something I normally only talk about after a few beers at EclipseCon. But I think I need to get it off my chest, especially after seeing a recent e-mail on the eclipse-dev list. I'll apologize in advance if I'm getting this wrong and feel free to correct me.
Now first of all, don't get me wrong, I am one of the biggest fans of the gang at IBM's OTI office (still more OTI than IBM they are) and a lot of them are good friends. The quality of the platform and the great extensibility it offers is what has made Eclipse what it is today. We'd all still be in the dark ages if it wasn't for their great work.
And, you know, I think they've come a long way as far as working in the open goes. When we started the CDT, it was really hard to know what they were doing and many times we were surprised by API and functionality changes in milestone builds that required us to scramble to fix up. I think on both sides, CDT and Platform, we've gone that extra mile to make sure we communicate better as committers. We've even received patches from the Platform team to make sure we didn't break when changes did occur.
The thing that has me concerned was highlighted in a mail that just came across on the eclipse-dev list from Kim Moir (sorry Kim, you're just the messenger). "I just talked to McQ regarding the plan. This is what he said... -Component leads can make rules more strict as they see fit..." And the mail goes on a bit longer to talk about the endgame rules for accepting changes.
Now it is my understanding that it's really up to the individual projects to decide what their development processes are, and I guess this is what the Eclipse project (or was it the Platform sub-project) has decided their processes to be. And you know, looking at the rules McQ has set out, they really are trying to give more power to the committers and my first was reaction was that this was a positive step in the right direction.
But, personally, in my role as the CDT Project Lead (which is also a sub-project which makes me a peer to McQ, who is IBM's Mike Wilson, BTW), the last thing I want to do is dictate to my committers what the endgame rules would be. Actually the last thing I want to do is dictate anything. Maybe it's just the way I am, but I feel the responsibility for the processes and guidelines falls with the committer group as a whole. If they don't agree, I'm actually powerless to stop them anyway so I'm really just a facilitator. Mind you, to make sure we have rules, I usually suggest something and if I get no feedback, which happens a lot, we assume everyone agrees. But in the end it should be the committers that decide.
Obviously the Eclipse team is set up differently. A lot of it is historical and due to the organization of the team, both as an Eclipse PMC as an an organization at IBM. But I would really like to see the Eclipse team open up their processes and decision making more and be a bit more transparent.
We have an architecture call each week that the component leads attend to represent their team. During the last two meetings, we discussed the end game plan in detail. This week, I included a link to the draft end game plan in my weekly status update that McQ assembles and posts to eclipse-dev so the teams could review and provide feedback.
ReplyDeleteAfter this week's arch call, I sat down with a member of the PMC and made further changes to it to incorporate the feedback from the meeting. Along the way, many other committers made suggestions that I included in the plan.
It is not a dictatorship by any means. Our committers are vocal
and not shy about expressing their opinions. If there are differences of opinion, there will be loud dicussions in hallways, on mailing lists, in bugzilla, on irc, or IM.
We are very passionate about what we do and really care about what other team members think, and the quality of the software we ship.
But I think we have to be pragmatic and try to get everyone on the same page, especially at the end of the release. We want to ship quality code on time. If everyone just does whatever they want, this increases the risk that we will uncover a serious problem that puts the ship date at risk. The PMC ultimately are a decision making body that steers the direction of our project.
In writing this blog entry, I think that you were missing the context of the conversations that occurred before the plan was published.
Perhaps it would be useful if we posted a summary of the decisions that were reached in the arch call in an open forum. This would reduce miscommunication and misunderstandings on our team, and in the eclipse community as a whole :-)
Thanks, Kim. Well said.
ReplyDeleteYou are right, I am missing the context, as would any who doesn't attend the calls.
With the CDT, our calls are open to everyone and our minutes posted (at least whenever I remember to :(. This is the openness I'm probably talking about. I know the committers are good at being open, I'm not sure that's as true with the component, project, and PMC leads.
"...the last thing I want to do is dictate to my committers what the endgame rules would be. Actually the last thing I want to do is dictate anything. ... but I feel the responsibility for the processes and guidelines falls with the committer group as a whole."
ReplyDeleteDoug, the "end game rules" for the Eclipse SDK have evolved over many years based on the input of both the team leads and the developers. I can understand from the outside it might seem dictatorial (?) but its really just a reflection of a way of working which we've honed as a group. I am not an Eclipse team lead (although I used to be) nor am I on the arch call, but I don't feel left out. Our end game way of working is our collective best practice for producing the most reliable products we can. And I have no doubt it will continue to evolve as product dynamics change.
For example, the approval process for changes in the last throws is a chance for *peer* to *peer* discussion of the impact of a change. That's because we all recognize that our judgment can be less reliable when we're under stress, tired, and perhaps too attached to a particular problem or feature. The closer to the end, the tougher we make it as way to cool down the development process.
I don't know the specific post you are referring to, but I will attest to the fact that the process we follow is what both leads and developers have settled on. It is our contract with each other.
All that said, of course communication is something that can always be improved.
I would like to add that, even though this might not even be consistent with Eclipse procedures, teams that have a single leader and decision marker are often far more effective than those run by committee.
ReplyDelete