An Inconvenient Process

Today I vetoed the nomination of five potential committers. This is something I really disliked and hated doing but I believe I had to: all five nominated persons have reported a few bugs but have not (yet) contributed a single patch. They have been nominated because the company they work for is going to contribute a cool feature to the WTP Incubator project and these people are supposed to maintain the code. Unfortunately, the contribution is still outstanding and the code is not yet Open Source.

What do you think? Should the Eclipse Process be changed so that everyone who likes to contribute and signs the Member Committer Agreement automatically becomes a committer? We have fewer than 500 about 1,000 [see Wayne’s comment below] Eclipse committers and probably in every Eclipse project there is a need for more contributors and committers. To lower the hurdle of becoming a committer also means lowering the attractiveness of being one of a select group of Eclipse committers and this may have the opposite effect: less instead of more active committers.

Update: After the code had been made public as an attachment in Eclipse Bugzilla I restarted the nomination. The code really looks good and I’m happy that WTP Incubator will grow by an interesting feature and by five committers who deserve this status. Looking back, I think that when a nomination comes along with a contribution we should always demand that the contribution is made public before or at the very beginning of the nomination process (if it is not already Open Source). Unlike me, you should not only ask for it but also veto as soon as possible so that it is clear that this has to be fixed before the nomination ends (you can then change your vote from -1 to +1 or 0).

12 Responses to “An Inconvenient Process”

  1. Pascal Rapicault Says:

    From your post it is unclear on which part of the project these individuals are gaining control over, the incubator or the main code base?
    The process defined by the foundation provides a framework for running a project. From those guidelines and social rules evolve how committers should be elected, thus resulting in differences between projects.
    For example, in equinox and p2, the barrier or entry for committer on the main code base is rather high (probably too high) whereas there are basically no barrier for entry on the incubator.

  2. Konstantin Komissarchik Says:

    I am not sure why you’ve started this crusade, but it is clear to me that you’ve managed to miss the entire point of the WTP incubator. It exists precisely to have no entry barriers. It supposed to encourage people with new ideas and half-finished projects in WTP space to come work on them in the open and gain experience of being a committer safely away from production code.

    EDP does not account for persistent incubator projects. They are technically not allowed, because they don’t have a well defined scope and never mature. Persistent incubators have sprung up as a grass roots idea using social norms rather than EDP as the guiding principle. EMO has largely looked the other way, because they work so well.

    WTP incubator has been pretty active (although it has yet to produce much that is merged upstream). Let’s not kill the spark that makes it work. Your defense of the process is misplaced in this project.

    • howlger Says:

      Hi Konstantin,

      If I am asked whether a person whom I don’t know should or should not become a committer to maintain code which is not Open Source, I would like to be able to say “no” without the allegation that this is because I want to harm the WTP Incubator project. The opposite is true. As you know, I asked “Please attach the planned code contribution to a bug report.” one day after the start of the nomination and I vetoed on the last day.

      Meanwhile the code has been attached to a bug and looks really good (especially the test coverage is amazing). I’m sure the nomination will be repeated and each of the nominated persons will be proud to become a committer not because they are tolerated as unknown persons but because of their great contribution.

  3. Wayne Beaton Says:

    Actually, we have close to 1,000 committers on the many projects at Eclipse. As Pascal says, criteria is different from project-to-project. However, I would suggest that the barrier should be generally lower for “incubator” projects.

    As a rule, we say that we don’t accept code without development resources. The natural extension of that is that new committers should be expected to come along with the code that they are contributing. I would expect to see committer elections start after a contribution has been attached to a bugzilla (for all to see and scrutinize).

    FWIW, the link you’ve provided is intended to provide guidelines and process. The actual criteria/barrier is for a project to decide.

    My bottom line here is that it seems reasonable to me to wait to do the election until after the contribution has been made and the addition has been socialized amongst the existing development team. IMHO, the election can and should happen before the IP Due Diligence process has been completed.

    Again, though, it is really up to the project to set criteria. I recommend that you discuss this with your teammates.

  4. David Carver Says:

    I suspect the second round of nominations to go through, as SAP has posted the code and the required bug, where comments and discussion can now happen.

    See bug 323696 for more details. I’ve already expressed some concern on where they were intending to put the code.

    Oh, and I fully support you Holger in taking the stand. Sometimes in the community we don’t take the stands when we feel we should. The process is there for a reason, and every other component in the incubator had to follow the same process.

  5. Joakim Erdfelt Says:

    Never be afraid to say no.

    That said, I feel you made the right call. You have an existing project, and are tasked with the health and vitality of the project (even the incubator portions), so you must view the nominations as individuals, not the company they represent.
    Like most open source projects caretakers with some time under their belts, there is an expectation of experience, knowledge, and passion required from the new individuals being brought into a project.
    Some view that as hard to achieve without being involved in a project. To those individuals I say fork the project on github (or googlecode) and show you’ve got the chops first.
    But even that approach isn’t perfect for individuals wanting to contribute to the project in other, non-code, areas (bug triage, documentation improvements, assistance in the mailing lists, etc). These non-coder individuals are still valuable to the project (and rare! if you see them embrace them!), but even those individuals have to earn their place.

  6. Fabian Steeg Says:

    I remember reading up on an election in some other Eclipse project that was vetoed for the same reason, and I liked that very much. I believe in an open source community that was initiated and that gets so many contributions from big companies, this policy, that nobody becomes a committer only because he is employed by a member company, is very valuable and part of what makes Eclipse a true open source community instead of being an industry consortium. For me this is about the perception of general openess, so I don’t feel incubators should be any different in this particular aspect.

  7. Miles Parker Says:

    Wow, what a juicy subject! I think both Konstantin and Holger have valid points and I congratulate Holger for being willing to stick his neck out on something as a matter of conviction. Since I’m on Modeling PMC and modeling is a very large project with lot’s of contributing organizations, I see many committer elections come by my email and frankly I just assume that whoever is putting the nominations up knows what they are doing. So, I can also understand Konstantin’s POV. So let’s put these two points of view together — when well intentioned people disagree that always seems to mean that there is a new insight or approach just waiting to be discovered..

    Ultimately as Konstantin say’s in his other post, I don’t think Board Elections are something to worry about, but project governance could be. I’ve thought a bit about this subject, and I think it makes a tremendous amount of sense for the projects to be trusted to make their own decisions with respect to this. It’s a very interesting balance, and I’m speaking form the POV of someone who is in the midst of figuring out where that balance is. I think I’ve actually scared off a couple of potential committers by being too over-whelming on requirements for becoming a committer! And I’m in the midst of helping a couple of potential contributors (in the broader sense) figure out how they want to be involved. On the other hand I feel that if I allow someone that I feel would be a good contributor to join the project in a pro forma way (“just post a bug report or two”) I couldn’t in fairness turn anyone away who was willing to do the same thing. What happens to project governance in that situation? As an extreme case, you could wake up one morning and find your project had been completely hijacked.🙂

    So it behooves everyone to give some thought to having clear and consistent approaches to committer elections and in some sense that ought to be enough to ensure fairness. And I so think projects have a real responsibility for their impact on the overall committer quality pool. If the contributions, skill level and dedication of the overall committer population are diminished, that diminishes everyone else’s contribution in some sense. Certainly if we got to the point where companies put up candidates automatically just as a function of their being members of a particular internal project, that would pretty much render the whole contributor nomination process a meaningless hoop to go through and I don’t think many of us want to see that.

    Internal Incubation projects are different from other projects and it seems reasonable that the criteria should be more open. But I don’t think it is correct to compare projects like WTP incubator to formal Eclipse incubation projects. That’s because there is an important step to take for incubation projects — you need to go through a quite formal proposal process in which both the value of your potential contribution and your ability to deliver on it are accessed by the community at large. Just because almost every project is approved does not mean that the process is pro forma!

    Since that proposal has to come directly from the new contributors this is already a very strong indication of the independence and passion of the proposing team. I’m not familiar with WTP’s procedure regarding this, but perhaps it would make sense to require an analogous if much less involved process for internal incubators?

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: