on Aug 28th, 2009IPZilla hurting community contributions?
Here are two ways the Eclipse IP process is discouraging community contributions:
1. IPZilla is private (“committer only”).
Why? I find this intransparent and discouraging towards contributors. At a minimum it should be open to committers and contributors.
2. IPZilla round-trip times for small contributions are way too long.
I think a speedy round-trip-time for small contributions (i.e. few days) is paramount in making it worthwhile for the community to contribute AND for us committers to shepherd these contributions.
To illustrate my point: I’m waiting more than two weeks for a CQ to be approved, which I could write myself 2-3 times in those two weeks. Should I turn the next contributor away? (“Thanks, but it’s faster if I write it”)
I wonder why can’t non-incubation projects in good standing have parallel ip for their milestones? This would speed-up acceptance of community contributions. The review could be completed in the ramp down time between freeze and final release.
What do you think?
PS: kudos to the Eclipse legal team for doing a great job making Eclipse technology commercially consumable.
Biggest problem right now is the back log of IP issues waiting to be reviewed. I was given an estimate of about 6 months before one of the items I was waiting on would be reviewed. Huge problem for an established project.
Yes, that is exactly why the current process is bad for contributions. Hearing after 6 months that your 300 line contribution is accepted does not encourage repeat contributions.
As a positive example: I’m amazed at the speed the linux foundation is accepting contributions (see my previous post). They have doubled the amount of code-changes that go into each release, while keeping the release interval the same (<12 weeks). I wonder how they do it…
I agree with both points. I cannot understand why the IP-zilla’s are non-public. Delays adopting code that contributors have been kind enough to put time and effort into is of course always discouraging. I think Eclipse could put much more trust into the committers or at least the project managers and let them take more responsibility for the code that is committed.
For instance, I have a current 500 line contribution written by a person who has made significant contributions to the project in the past. The person has assured that he’s written 100% of the code and his employer has not change their mindset about him contributing under EPL. What more is there to consider? Why can I not just check his stuff in?
We need to distinguish between the review of contributions from contributors and the third party code (e.g. code originating at Apache) when discussing IP review turnaround time.
Contributions by contributors to mature projects are given a high priority and typically reviewed within the week. We make an effort to give these contributions a higher priority for the very reasons that Elias cites. Response time may vary from the typical for a variety of reasons – including well deserved vacations and a higher volume of committer provisioning or third party contributions.
The review of third party contributions takes longer, and the kind of wait time highlighted by Dave is an unfortunate reality for some. The introduction of parallel IP was intended to reduce the impact that delayed IP review had on the projects.
Expanding the scope of parallel IP to other areas was discussed at the IP Advisory committee and a balance between risk mitigation and enabling the projects was drawn. Within this balance, we also must recognize the wide variety of experience and knowledge within our projects, which number over 100 now. We revisit this line regularly in our ongoing effort to balance the needs of both our committer members and the ecosystem as a whole.
Regarding access to IPZilla, the limitation on access is designed to facilitate frank discussion of IP related topics and provide value add to Enterprise and Strategic Members that wish to leverage the results of our work for their own internal purposes – mitigating risks where possible and giving their internal review teams a “leg-up” when starting their own reviews.
Hi Janet.
Perhaps the parallel IP concept could be extended? I would like to propose the following extension.
If the following conditions are met:
- the contribution is in the form of source code patch to a bugzilla
- the contributor guarantees that:
a) he has written 100% of the code
b) he contributes under EPL
c) his employer has no objections
- the project manager of the receiving project approves
Then a check-in would be permitted without delay. A CQ must be issued anyway since the IP must be approved prior to releasing anything that includes the code.
The extension would apply both to incubation and mature projects.
Hi Thomas,
All conforming Incubating Projects can leverage Parallel IP today[1]. The extension that you suggest would be for contributor contributions to Mature Projects only. This is a relatively small number of contributions which are typically reviewed within a week. I’d be concerned that the introduction of Parallel IP in this circumstance would add a step for the IP Team and provide little benefit for the projects.
Janet
[1] http://wiki.eclipse.org/Development_Resources/HOWTO/Parallel_IP_Process
Not sure why this would be an extra step. Wouldn’t the work involved for the IP team remain the same?
IMO, you underestimate the benefit. When community members contribute code, that often happens as the result of an ongoing discussion, either in a forum or on a bugzilla. Much is gained if we are able to check things in moreor less immediately, test it, work with it, communicate, and receive new patches. If we don’t check things in, we quickly run into situations where the patch becomes stale due to other work on the same component, thus forcing the contributor to create updated patches.
An alternative suggestion is, simply trust the project maintainers and raise the bar for when an IP review is needed. If the conditions that I mentioned are met, then I’m not completely clear why a review is at all needed.
Hi Thomas,
We already operate in a climate of trust with our committers who can freely submit code to CVS/SVN. The practice for reviewing other code contributions is intended to strike a careful balance between reducing risk to the ecosystem and enabling the projects. It’s a difficult balance that we review on an ongoing basis.
I’m currently reviewing the IP process to look for opportunities to streamline the process and be sure to take your comments into account. Changes such as those you suggest will be considered as part of that process. Thanks for the feedback!
Janet
Janet, Thomas, David,
thanks for taking the time to comment on my post.
For my part I wish for either parallel IP for eligible mature projects or for a much larger limit before we consider something a “significant” contribution. For example 5000 lines instead of the current 250.
I’m looking forward to the outcome of the IP process review.
Kind regards,
Elias.