Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Development Process 2006 New Incubation"
(→Project Lifecycle) |
(→Project Lifecycle) |
||
| Line 37: | Line 37: | ||
** the code will be actively developed to eclipse quality and testing standards | ** the code will be actively developed to eclipse quality and testing standards | ||
| − | ''(Bjorn) Are you trying to have the projects commit to an architecture early in their lifecycle?'' I would like to achieve that projects care about architecture early in their lifecycle and that they document the initial architecture with more then a few boxes (at least a documentation of the main purpose of each plugin and its relation to other plugins, as well as how it shall be extensible. Often enough this kind of documentation happens late in the cycle(or not at all). | + | ''(Bjorn) Are you trying to have the projects commit to an architecture early in their lifecycle?'' I would like to achieve that projects care about architecture early in their lifecycle and that they document the initial architecture with more then a few boxes (at least a documentation of the main purpose of each plugin and its relation to other plugins, as well as how it shall be extensible. Often enough this kind of documentation happens late in the cycle(or not at all). But it is important for projects that want to build a platform that adopters can comprehend the structures - this is different than with projects that "only" create end user tools. |
''(Bjorn) Are you trying to separate the existence of IP cleared code from the existence of a functioning community?'' Sort of. I argue that it is pretty difficult to build a community if you can not provide something easily consumable. But I would not go so far that the community building should be part of the proposal validation phase, I think this remains in the incubation phase. But the community would have something to get started with at the BEGIN of incubation: a full set of sources and binaries (and an architecture overview). | ''(Bjorn) Are you trying to separate the existence of IP cleared code from the existence of a functioning community?'' Sort of. I argue that it is pretty difficult to build a community if you can not provide something easily consumable. But I would not go so far that the community building should be part of the proposal validation phase, I think this remains in the incubation phase. But the community would have something to get started with at the BEGIN of incubation: a full set of sources and binaries (and an architecture overview). | ||
Revision as of 20:50, 21 November 2006
Project Lifecycle
Strike through means striked from original, underlined means new.
Projects go through sixseven distinct phases. The transitions from phase to phase are open and transparent public reviews.
Pre-proposal - An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.
- The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.
Proposal - The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal. Mentors for the project must be identified during this phase.
- The Proposal phase ends with a
Creation ReviewProposal Review or a Termination Review.
Proposal review - The reviews are not described in the original project lifecycle, it is added here anyway for providing info about the purpose of this review. The proposal review checks whether the proposal is in compliance with the Eclipse Bylaws and if the required number of Mentors have been found.
Proposal Validation - After the proposal has been accepted for validation, the purpose of the proposal validation phase is to establish a basic (documented) architecture and to validate this architecture with a working implementation. The proposal team should make all planed code contributions available during proposal validation. It should be able to instantly use the code contributions. The contributions need to be worked to eclipse quality requirements (tests, api, documentation) during Proposal Validation. The proposers need to create an easily consumable build of the implementation.
As there are legal requirements for ip compliance at Eclipse.org, I propose that we use an infrastructure (e.g. from a partner) where the code can live, where we do not have the ip compliance requirement. Eclipse.org would provide newsgroup, mailing list and web space during proposal validation, but the sources and builds would be provided from a different site. IMPORTANT: Mentors would be available to the proposers in the proposal validation phase, but we would not speak of an Eclipse project at this phase.
- The Proposal Validation phase ends with a successful Creation Review or a Termination Review.
Incubation - After the project has been created, the purpose of the incubation phase is to establish a fully-functioning open-source project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a phase rather than a place: new projects may be incubated under any existing Top-Level Project.
- The Incubation phase ends with a successful Graduation Review or a Termination Review.
- The Incubation phase may continue with a Continuation Review.
- Top-Level Projects cannot be incubated and can only be created from existing Mature-phase Projects.
Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.
I believe you have a goal in mind for this proposal, but I'm not clear what that goal is. Thanks.--Bjorn Freeman-Benson
- set quality standards that need to be met before we create an eclipse project
- enable proposals to showcase their ideas without having to wait a couple of month for approval of code contributions or use of third party code (and I guess this a reality for most of the new projects) - by being able to distribute binaries and having easily consumable sources. We (the RAP project) have a very real pain with this - we can not provide any builds and it is quite difficult to build a community just by providing information and incomplete sources in CVS.
- distribute the risk of accepting code contributions between the proposers and eclipse.org. Currently eclipse.org is spending time and money on ip compliance for code contributions and third party code before it is clear that
- the project is able to produce something useful at all (beside an idea)
- the code has sufficient quality
- the code will be actively developed to eclipse quality and testing standards
(Bjorn) Are you trying to have the projects commit to an architecture early in their lifecycle? I would like to achieve that projects care about architecture early in their lifecycle and that they document the initial architecture with more then a few boxes (at least a documentation of the main purpose of each plugin and its relation to other plugins, as well as how it shall be extensible. Often enough this kind of documentation happens late in the cycle(or not at all). But it is important for projects that want to build a platform that adopters can comprehend the structures - this is different than with projects that "only" create end user tools.
(Bjorn) Are you trying to separate the existence of IP cleared code from the existence of a functioning community? Sort of. I argue that it is pretty difficult to build a community if you can not provide something easily consumable. But I would not go so far that the community building should be part of the proposal validation phase, I think this remains in the incubation phase. But the community would have something to get started with at the BEGIN of incubation: a full set of sources and binaries (and an architecture overview).
(Bjorn) If the proposal has Eclipse-based infrastructure for everything expect the code, aren't there IP issues around that as well (e.g., what if a project discusses a GPLed contribution to their external repository but does so on the Eclipse newsgroup; the newsgroup explicits defines all postings as EPLed, so ...)? Not sure about this, let's ask the lawyers if others like the idea at all. Maybe this has to be tuned.
(Bjorn) And wouldn't this proposal have the side-effect of making it more convenient to propose a project with no initial code (because then you wouldn't have to discuss the architecture in advance)? I don't think so, as there would still be the need "to establish a basic (documented) architecture and to validate this architecture with a working implementation". And this is not meant to cause only pain to the projects, but instead enable them to show that they can provide something useful and it is worth spending time with them.
-- Jochen Krause