| Note | ||
|---|---|---|
| ||
This is only a draft, and an incomplete one at that. It has not been approved or agreed to by anyone. Not even me. Comments are welcome welcome |
| Info | ||
|---|---|---|
| ||
This process is not perfect or even fully defined. It is not our intent to beat this document to death by trying to anticipate every possibility. We are certain that as we use it, there will be changes. We are going to roll it out early and modify it as often as required. No big bang, just a slow burn. A couple of projects are already quietly participating in the "incubation thing" process. |
...
- Pentaho Product Management (PM) initiates and sponsors the "incubation thing" of a feature or product that is on the Pentaho road map.
- A third party company has a product that fits into the Pentaho suite and wants to contribute it to Pentaho.
- A community member as an idea for a feature, discusses it in the "incubation thing" forum (to be created) and generated enough interest and support to request an "incubation thing" be created.
- The CTO office wants to sponsor a prototype or proof of concept.
...
This sounds formal but is really a matter giving the following information to Community Connection (communityconnection@pentaho.org): (This could be a simple form)
- Identity of the Project Sponsor. Their responsibilities include:
- Communicate status to Community
- Coordinate meetings with working group
- Request resources from Community as needed to support initiative
...
If the proposal is accepted, (at this time there is no formalized process just general consensus) Pentaho Community will create a new "incubation thing" and coordinate setting up resources required. The "incubation thing" will start in the conception phase and have a collaboration space consisting of:
- Entry in the "Conception Phase" listing in the "incubation thing" space on pentaho.org
- A forum within the "incubation thing" forum space
- Wiki page for documentation, requirements, meeting notes etc
- Subversion project for source code when needed
What about these things?
- A working group email group for communication
- Some kind of webex access for meetings
- FTP Space for downloads
During the acceptance process, Pentaho Project Management (PM) will decide if the "incubation thing" is destined to become supported Pentaho product. The "incubation thing" will be identified as "Supported Product" or "Unsupported" and be specified on the "incubation thing" page. It should be obvious to everyone what the end game is. Pentaho engineering will also specify their level of support of the "incubation thing".
...
The conception phase about the communication of ideas: brainstorm requirements, discuss use cases, look for existing software, generate interest, etc. By the end of the conception phase, there should be an initial set of high level requirements with enough detail for someone to generate a prototype or start on seed code.
If someone already has a similar product that they want to contribute to open source, this would be the phase where it is evaluated for feasibility.
Most Active Community Participation
Anyone with an interest in defining the capabilities of the feature or product. Usually related to the end user, product management or system integrator.
- Product Management
- CTO
- End Users
- Integrators
Entry Requirements
No requirements beyond the Requirements for initiating a new "incubation thing".
...
The seeding phase is where the initial coding begins. Seed code in the form of a prototype or proof of concept is typically generated by a small few and put out group or single developer. Builds are made available for people to try, comment on and modify. It is usually easier to discuss features and requirements when there is code to try out and comment on. This is where the strength of early and often come in. By the end of seeding, most or all requirements have been defined, tasks have been identified and big chunks of work can be assigned. Seeding usually ends with a Milestone 1 (M1) release.
Most Active Community Participation
During this phase, a small group of developers get involved with prototypes and POCs. Product managers and system integrators will be verifying the prototypes against storyboards to make sure the requirements are being interpreted correctly.
- Product Management
- CTO
- Integrators
- Developers
Entry Requirements
- Defined Seeding Requirements - The things that need to be proven or prototyped are identified
- Define Exit Criteria - What must be accomplished before this phase can be considered complete.
...
- Code the framework - Initial architecture framework provides straw-man for evaluating requirements. It may morph into the implementation.
- Proof of concept (POC) - Usually throw-away code to demonstrate a feature or concept. Determine the feesability of a technology or help visualize a UI.
- Prototype - Similar to a POC, usually more complete and likely that some or all of the code will be used
- Define Exit Criteria - What must be accomplished before this phase can be considered complete.
Incubation
TODO
Entry Requirements
...
The incubation phase is where the bulk of the coding occurs. Requirements should be complete and JIRA cases should be created and assigned to developers. The incubation phase generally lasts through the Milestone (M2-M4) releases and ends with a feature complete (FC) release.
Most Active Community Participation
Many more developers get involved during this phase. Users can start looking at features as milestone builds are completed.
- Developers
- Users
Entry Requirements
- Completed Requirements or PRD - Product Requirements Document complete and agreed to by working group.
- Completed seed code - Prototypes or POCs should be complete. Framework code, if required, should be in a state where other developers can contribute
- Define Exit Criteria - What must be accomplished before this phase can be considered complete.
Typical Tasks
- XXX - DDD
Hatching
TODO
Entry Requirements
...
- Code major features - Code and document the features and develop JUnit tests
- JIRA Cases created - Requirements should be documented in JIRA so tasks can be assigned to developers and tracked
- Document design - The architecture and design documentation should be completed during this phase, preferably at the beginning
- Milestone Releases - This phase usually accompanies M2 - M4
Hatching
The hatching phase comes after the main features are complete and the project needs to be stabilized, debugged and completed. If it is going to be supported product, the go-to-market tasks can start.
Most Active Community Participation
With the major development complete, the bulk of community activity turns to feature testing and integration testing.
- Testers
- Developers
Entry Requirements
- Design docs complete - After all we are almost feature complete
- Remaining work is documented in JIRA - If it's not in JIRA it's not likely to get done
- Define Exit Criteria - What must be accomplished before this phase can be considered complete.
Typical Tasks
- XXX - DDD
Product
TODO
Entry Requirements
- XXX - DDDComplete features
- Stabilize - It should become stable enough for people to start trying it out and deploying
- Bug Fixing - Find and fix major bugs, design defects etc.
- Create Samples - Samples, task oriented documentation and tech tips
- Go To Market Plan - If this is going to be supported product.
- Feature Complete - This phase usually ends with FC
- Migration plan - If applicable
Product
The product phase is where software is turned into whole product. If the project is going to be supported by Pentaho, all the normal GTM stuff happens here. If the project is going to be spun off as its own open source project, those preparations will happen here.
Most Active Community Participation
This is where the end users get heavily involved
- Testers
- Developers
Entry Requirements
- Feature Complete -
- Define Exit Criteria - What must be accomplished before this phase can be considered complete.
Typical Tasks
- XXX - DDD** -
- ** -
- ** -
- ** -
- ** -