Some of you may have noticed the debate happening regarding proper entry expectations for WTP incubator project following Holger’s veto of a committer election. Holger is acting well within the power granted to him by Eclipse Development Process (EDP), but is it a right and proper action?
Every committer on a project has the veto power in an election. By extension, any entry criteria for a project (whether written or unwritten) is nothing more than a social convention. The reality is that every committer can choose to levy their own personal expectations. Most of the time it’s not a problem, except when it is.
Here are some quotes from this particular event:
“I found only some bug reports but not a single code contribution from any of the four nominated persons. Please attach the planned code contribution to a bug report. I'd like to vote for each of the nominated persons as soon as I know that the code is readable and covered by JUnit tests.”
“Have [snip] been asked if they like to become committers as individuals (and not only as employees of SAP)? Are these authors of the code or what is their motivation to maintain and enhance these editors?”
In a regular project with established code base, established team and well-defined scope, you can argue that giving every committer veto power over elections is appropriate. After all, there is an established code base to protect. The same considerations do not apply when a new component is proposed in an incubator.
The WTP incubator project was started with the intention to provide a low entry barrier playground for people to come and experiment on new ideas while gaining experience and proving their merit to committers on the core projects that will eventually be asked to admit matured functions. Incubators make sense because they provide a quicker way to get started than a separate project proposal. Unfortunately incubators have to rely on a social convention that existing committers act in a welcoming fashion to newcomers. Most of the time that happens, except when it doesn’t.
I would posit that there is no legitimate purpose served by holding a committer election when a new component is proposed for an incubator. The situation is supposed to be very similar to new project creation and we don’t hold elections there. The party proposing a project gets to designate a group of individuals to be the initial committers without anyone questioning their credentials or motives. A similar process is needed to make incubators work better.
The last revision of EDP has formalized the concept of a persistent incubator. I propose that we build on those revisions and amend EDP to remove the committer vote requirement for incubator projects when a new component is being proposed. The project’s PMC would still have the oversight and ability to decline a new component proposal. This change would also fix the rather awkward problem of having to have “seeder” committers when creating incubator projects.
Note that my suggestion is for persistent incubator projects rather than normal projects during incubation phase. I am also not suggesting that we remove committer vote entirely from incubators. Anyone wishing to join existing effort already underway in the incubator should still be subject to committer vote.
Thoughts?
PS.1 : This situation has served to highlight a process problem and it is the process that I seek to improve. I have no beef with Holger. I am sure he is acting on what he believes in.
PS.2 : I am further confident that this particular storm will blow over, Holger’s objections will be met, another election held, etc. That doesn’t mean we shouldn’t try to improve the process so that such situations do not happen again and we continue to have vibrant incubator projects at Eclipse.
Update: At Wayne’s request I created a bug to track this proposed improvement to Eclipse Development Process.
Posts
6 comments:
How hard it is to create and maintain a project at Eclipse Labs (or SF/elsewhere, where we don't have all these restrictions) & when it comes out with flying colors, move it to the Eclipse Code base? When both the product & code base is good, there shouldn't be any issues in moving the code to Eclipse and getting committer rights for those who worked on.
Hi Konstantin,
my intention was not to start a debate on principles but to take the right decision in this particular case. Now that the code has been contributed and has become Open Source I have started the nominations again. The code and documentation looks pretty good, and with five committers I expect the Service Interface and Data Types Editors will graduate from WTP Incubator into the main WTP project very soon.
In Incubator projects without the nomination process a company might spam the projects with committers to increase their influence in the election of the Board of Directors. If you want to start an Open Source project without any nomination process, you can do so already at Eclipse Labs (alias Google Code), SourcForge, GitHub, etc.
Holger
I am not arguing about principles. My concerns is for viability of incubotors at Eclipse, which serve a very important function of growing and diversifying committer base.
It sounds like you are happy with the code quality and other explanations in this case, and I am glad for that. But what if there was no code (just an idea) or what if the code was not in good shape yet. Based on your comments, it sounds like you favor rejecting those committers. My argument is that it is inconsistent with the purpose of incubators.
To those that say, if you don't like something go to SourceForge or EclipseLabs, I say think about what you are saying for a minute. Eclipse Foundation sustains itself on membership dues paid by companies that see the value provided by the foundation that is not provided by other OSS hosts. It is in our collective best interests to make sure that Eclipse is the best and most convenient place for OSS inovation in this space. If that ceases to be the case, the companies funding the foundation through their dues might wonder if their money is well-spent.
> In Incubator projects without
> the nomination process a company
> might spam the projects with
> committers to increase their
> influence in the election of the
> Board of Directors.
Nice conspiracy theory. Couple of flaws in it, though:
1. A company can already "spam" Eclipse with committers. All it takes is a project proposal or two. Remember, that initial committers on a project are named, not elected.
2. When electing committer represenatives to Board of Directors, a member company gets only 1 vote regardless of how many committers it has.
3. You over estimate the influence of a board member or two. I say that as someone who served on the board as a committer representative for a year.
> If you want to start an Open
> Source project without any
> nomination process
The nomination and election process for committers only applies after the project is created. The initial group of committers are named as part of project proposal. They are not elected.
My argument is that the same thing should happen when a new component is proposed for an existing incubator project.
For modeling we generally create new subprojects within an incubating umbrella project so that the new committers have access only to their own code. As such, no election to an existing project is involved. It's quite a heavy weight process---a full project proposal with a review is involved---but it helps filter out those who are not very serious or not very committed. This wouldn't make sense for very small contributions or where direct involvement in the established base is the intent.
Please open a bug against "Process" with [EDP] in the title so that we can track this discussion for the next iteration.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=324133
Post a Comment