KEP-0006.txt

Jeroen van Meeuwen vanmeeuwen at kolabsys.com
Tue Mar 1 11:34:45 CET 2011


 KEP-0006.txt |  171 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 171 insertions(+)

New commits:
commit 3f1002be5d1474e52a470020aa512f50783af137
Author: Jeroen van Meeuwen (Kolab Systems) <vanmeeuwen at kolabsys.com>
Date:   Tue Mar 1 10:33:42 2011 +0000

    Add new KEP #6: Server Development and Release Process

diff --git a/KEP-0006.txt b/KEP-0006.txt
new file mode 100644
index 0000000..889b156
--- /dev/null
+++ b/KEP-0006.txt
@@ -0,0 +1,171 @@
+{{kep
+ |number=6
+ |ticketnumber=
+ |title=Server Development and Release Process
+ |author=Jeroen van Meeuwen
+ |author_email=vanmeeuwen at kolabsys.com
+ |status=draft
+ |type=process
+ |creation_date=2011-03-01
+ |obsoleted_by=
+ |related=
+}}
+
+= Overview =
+
+Development and release cycles consists of (roughly) the following phases (in order or appearance);
+
+# [[#Phase_1:_Feature_Proposal_Gathering | Feature Proposal Gathering]]
+# [[#Phase_2:_Feature_Approval | Feature Approval]]
+# [[#Phase_3:_Feature_Development | Feature Development]]
+# [[#Phase_4:_Development | Development]]
+# [[#Phase_5:_Quality_Assurance | Quality Assurance]]
+# [[#Phase_6:_Final_Release | Final Release]]
+# [[#Phase_7:_Maintenance | Maintenance]]
+
+Each of phases 1 through 6 is to be completed within a certain period of time. Detailed descriptions of each phase can be found below.
+
+Each of the development phases naturally has a start, but because development is ever ongoing what it requires is an end to be set.
+
+Maybe such an end to a certain phase is set in stone (e.g. a hard date), in which case -prior to the end of the phase- the result of the current phase determines whether the next phase can be started for a particular topic, or whether the entire development effort op this topic can no longer be a part of the current development cycle (e.g. is probably too far behind the process to make it in time for the targeted release).
+
+In cases where the end of each of the development phases on a particular topic are not set in stone (e.g. "let me know when you're ready"), most commonly no set release target has been set for the development either. The development effort would basically be dangling permanently until it is ready to be included.
+
+== Time versus Feature-based Development Cycles ==
+
+Time-based development cycles have several advantages over feature-based development cycles;
+
+# time-based development cycles have a cut-off date set, preventing ongoing development on features to be completed from continuously postponing releases,
+# features can still be developed at their own respective pace, but are only submitted for inclusion when the development can finalize within the set schedule,
+# time-based development cycle build better manageable expectations on the consumer as well as the business end of Kolab.
+
+Kolab therefore uses time-based development cycles.
+
+== Major or Minor Development? ==
+
+For development cycles targeting a release with a '''major''' version bump, such as from 2.x to 3.0, the development and release cycles are supposed to all be aligned and start and end at around the same times/dates. Plenty of coordination is needed to make that run smoothly!
+
+For development cycles targeting a release with a '''minor''' version bump, development efforts themselves can be disjunct as there may be no great overhaul in functionality within a product series with the same major version number, and whether the feature is included in <code>2.x</code> or in <code>2.(x+1)</code> is off little technical impact.
+
+= Development Cycle Phases =
+
+The development cycle is the time during which new Kolab Groupware Server features are developed.
+
+== Phase 1: Feature Proposal Gathering ==
+
+=== Description ===
+
+The requirements phase is when everyone chimes in and screams and shouts what they think should be in the targeted release. Provided some shape and form can be offered to consolidate everyone's ideas so no ideas get lost in the circus, in principal no ideas need to be excluded from this part of the process. Re-factoring, re-thinking architecture, overthrowing some or the other dictatorship in the Caribbean.
+
+=== Phase Details ===
+
+The phase in which requirements are gathered starts a brand new development cycle -by definition. By the time this phase starts, Release Management should already have determined (in general terms though), the target release this development cycle is aiming for, so that the development and release cycles can be referred to as part of, for example, ''The Kolab 3.0 Development Cycle''.
+
+Starting one development cycle is not necessarily mutually exclusive with starting another development cycle in parallel. Most commonly though, only one development cycle targets a single major release. Exceptions could include ''quick win'' type of additions to the release targets, or enhancements that span multiple versions.
+
+{{note|Kolab 2.4 and 3.0 Parallel Development Cycles|If a feature is to be implemented in the Kolab Format (such as is the case with, for example, [[KEP:2 | KEP #2: Modification of datetime: store local time, add 'tz' attribute]]), which is not '''unrelated''' to Kolab Groupware Server development, but is a development on the client-side handling of the Kolab Format primarily, two Kolab Groupware Server development cycles can start in parallel; one for a ''2.4'' series implementing only the improved Kolab Format handling, and one for a ''3.0'' series developing and implementing other new features as well.}}
+
+=== Process Handling ===
+
+The phase could be started in a controlled fashion by announcing a window of time where people can write up and propose their ideas. Supposedly, a window of a month should suffice, when announced two weeks in advance.
+
+A template for suggestions should be offered, clearly asking for as much information as can be reasonably expected.
+
+The process format to use for the feature proposals is the [[KEP]] process as described in [[KEP:1 | KEP #1: Bootstrap the KEP Process]].
+
+== Phase 2: Feature Approval ==
+
+=== Description ===
+
+During the feature approval phase of the development cycle, we look over the details of each feature proposal and assess its feasibility, the timeline the feature could be completed in, and how the feature development and implementation can properly align with the rest of the proposed features.
+
+In some cases, fleshing out some of the specifications can start as soon as the first version of the requirements has been submitted. Anyway, it's not a one-way street ;-)
+
+Some of the specs of the proposed feature may result in links between various aspects of other features as well, possibly constituting dependencies between features or partial duplication of functionality.
+
+=== Phase Details ===
+
+Some example questions to be answered during this phase could be;
+
+* Is the proposed feature feasible at all?
+** e.g. "world peace" will probably not make it
+* Is the proposed feature worth the trouble right now?
+** e.g. "windows port for the server" might not be worth the trouble right now
+* Is there overlap between features currently proposed, or with existing products?
+** e.g. "a mail server filter for foo" and "a mail server filter for bar" show some overlap,
+* Are any of the features proposed mutually exclusive?
+
+=== Process Handling ===
+
+During a first IRC meeting, feature proposals are glanced over and where there may be questions or concerns, tasks are being assigned to follow-up with the feature owner(s) to have those questions answered or concerns addressed.
+
+During a (short) second IRC meeting, feedback and progress is being reported to make sure we continue to move forward.
+
+During a third IRC meeting, nearing the end of this phase, a final meeting will put forth the list of primary features targeted for this development cycle. It will also be determined, in case of a major development cycle, whether features that are accepted are targeted for the first minor or postponed to a later minor, and a roadmap with (dated) milestones will be distilled from these lists.
+
+== Phase 3: Feature Development ==
+
+=== Description ===
+
+During the feature development phase, actual features are being actively developed.
+
+Using the issue tracker, tracker issues and milestones, progress on each of the feature component(s) is being tracked, which is essential in a time-based development and release cycle.
+
+Should progress be insufficient, then Release Management is provided with two options;
+
+# Put additional resources to the feature development,
+# Drop the feature as targeting the current target milestone and postpone it to a later milestone.
+
+'''In exceptional situations''', Release Management can slip the development cycle and hence also the release cycle to allow features to complete development.
+
+=== Process Handling ===
+
+[mailto:kolab-devel at kolab.org kolab-devel at kolab.org] can be used to ask questions and provide feedback concerning progress on feature development. This would be a task for the Release Manager. Reports may be churned out from the issue tracker, if possible, to show progress being made if any at all.
+
+= Release Cycle Phases =
+
+The release cycle is a pretty complex cycle. Some phases are, or can be, executed in parallel, such as continued development versus quality assurance. Also, the release cycle is basically an infinite loop for as long as the released product's life cycle lasts.
+
+== Phase 4: Development ==
+
+{{note|This is not the only Phase|This is not the only phase that starts; the [[#Phase_5:_Quality_Assurance | Quality Assurance phase]] starts in parallel with the (Continued) Development phase!}}
+
+=== Description ===
+
+This development phase goes to bug-fixing and fixing of churn-out by Quality Assurance rather then "new" feature development. The essential difference between "new feature development" and this phase is, that this phase concerns itself with features that are feature-complete (e.g. have show-case implementations), though not necessarily free of bugs.
+
+=== Phase Details ===
+
+* Feature owners and developers pick up the remaining issues for your feature
+* The remaining issues are assigned the appropriate severity (blocker, critical, major, etc.)
+* The list of remaining issues will be looked over to determine any release blockers
+* New issues will be logged by testing through [[#Phase_5:_Quality_Assurance | Quality Assurance]].
+
+=== Phase Handling ===
+
+== Phase 5: Quality Assurance ==
+
+Quality Assurance starts in parallel with [[#Phase_4:_Development | the Development phase]], and will result in new bugs against the developed features. Bugs may occur given use-case scenarios, and range from code error to documentation deficiencies.
+
+Also during the Quality Assurance phase, test cases are executed to verify the specifications of developed features are met.
+
+=== Phase Handling ===
+
+This phase can only start provided a common, collaborative means to continue improving the features developed, expanding details on the test cases, and product documentation. This implies a certain set of features to the issue tracker used.
+
+== Phase 6: Final Release ==
+
+This phase is the final release phase, ultimately releasing the final product. This phase is executed repeatedly within a product series, by, for example, releasing teeny versions 3.0.1, 3.0.2, etcetera. These teeny versions would typically not include a development cycle -but may require Quality Assurance regression testing.
+
+=== Phase Handling ===
+
+Completion of this phase can only be postponed or delayed under the following conditions;
+
+* No feature enhancements justifying a release has been completed,
+* Important feature enhancements can be completed within a reasonable time.
+
+Anything not completed or not according to specification originally included in the Feature Proposal or Approval goes in to the product's Release Notes.
+
+== Phase 7: Maintenance ==
+
+Further, continued Development, Quality Assurance, Documentation, Deployment, Maintenance and Support is an infinite loop throughout the product's life cycle. This is the final phase of the product, which starts as soon as the final product is released.





More information about the commits mailing list