summaryrefslogtreecommitdiff
path: root/KEP-0011.txt
blob: bfa53ec6d634a34f51e939b421ae9ad87932000b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
{{kep
 |number=11
 |ticketnumber=
 |title=Development and Release Process
 |author=Jeroen van Meeuwen
 |author_email=vanmeeuwen@kolabsys.com
 |status=draft
 |type=informational
 |creation_date=2011-08-24
 |obsoletes=
 |obsoleted_by=
 |related=
}}

== Abstract ==

The Kolab development and release processes have long worked without formal, clearly outlined processes for both development and release cycles. Recently, the [[KEP:1|KEP #1]] process has gained us a framework for feature proposal submission, critical review and acceptance, and [[KEP:5|KEP #5]] has gained us the mapping of version numbers (i.e. release management) between development and release cycles required for proper issue tracking.

This KEP outlines the various steps, milestones and relationships with regards to feature proposal submission, development and releases, so that all participants in the community can be explained and refer to what can (reasonably) be expected.

== 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]]

=== Timeline ===

{{note|Timeline NOT part of this KEP|Please note the actual time-line details are not part of this KEP document, but instead are Wiki template pages so that they can be included in other Wiki pages as well. Please note that it is ONLY the timeline that is NOT part of this KEP document. Other process phase details are part of this KEP document.}}

The following is a complete time-line, ordered by phase.

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_1_Timeline}}
|-
{{Development_Cycle_Phase_2_Timeline}}
|-
{{Development_Cycle_Phase_3_Timeline}}
|-
{{Development_Cycle_Phase_4_Timeline}}
|-
{{Development_Cycle_Phase_5_Timeline}}
|-
{{Development_Cycle_Phase_6_Timeline}}
|-
{{Development_Cycle_Phase_7_Timeline}}
|}

== Development Cycle ==

Each of the development phases naturally has a start, but because development is ever ongoing what it requires is an end to be set.

It is for that reason, that we set a ''target'' (release) for a single development cycle.

Maybe such an end to a phase is set in stone, a date, in which case -prior to the end of the phase- the result of the current phase helps determine 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 (i.e. can not be included in the targeted release, as it is probably too far behind in time or 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 (i.e. the type of development that is ongoing, "let me know when you're ready"), most commonly no particular release target has been set for the development of said case. The development effort would basically be dangling permanently until it is marked to be ready to be included by its developers, which is when the target release is defined.

==== Major or Minor? ====

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.

==== Responsibility ====

Release Management is in charge of coordinating which development cycle (for which feature) is targeted against which release. A Release Manager '''MUST''' be able to appoint one or more ''Release Engineers''.

=== Phase 1: Feature Proposal Gathering ===

This phase starts with an announcement from Release Management stating "we're open for business".

==== 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. Most commonly though, only one development cycle targets a single major release. Exceptions could include ''quick win'' type of additions to the release targets.

==== Process Handling ====

The phase could be started in a controlled fashion by announcing a window in time where people can write up and propose their ideas. Supposedly, a window of a month should suffice, announced two weeks in advance.

A template for suggestions should be offered, clearly asking for as much information as can be reasonably expected.

===== Phase 1 Timeline =====

The Feature submission deadline is announced 4 weeks in advance. This section describes what happens during these 4 weeks.

{|
! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_1_Timeline}}
|}

=== 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 of the questions asked during this phase would 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

==== 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, near 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.

===== Phase 2 Timeline =====

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_2_Timeline}}
|}

==== See Also ====

=== Phase 3: Feature Development ===

==== Description ====

During the feature development phase, actual features are being actively developed.

Using the issue tracker, a tracker issues and milestones can be used to track progress on the feature component(s), which is essential in a time-based development and release cycle.

Should progress be insufficient, then we have two options;

# Put additional resources to the feature development,
# Drop the feature as targeting the current target milestone and postpone it.

development cycle thing because still - in worst case scenarios - features can be dropped, for release constraints such as delays or feasibility

* time-based releases?
* feature set releases?

note that for major releases and small communities, time-based releases offer some means of controlling the number of features

* What happens if development does not progress sufficiently? Options: Post-pone feature to later milestone or delay release.

==== Process Handling ====

===== Phase 3 Timeline =====

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_3_Timeline}}
|}

== Release Cycle ==

The release cycle is a pretty complex cycle. Some phases are 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 of Quality Assurance rather then "new" feature development.

==== Phase Details ====

* You pick up the remaining issues for your feature
* You assign those the appropriate severity (bug, enhancement, task)
* The list of remaining issues will be looked over to determine any feature blockers
* New issues will be logged by testing and Quality Assurance.

==== Phase Handling ====

===== Phase 4 Timeline =====

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_4_Timeline}}
|}

=== Phase 5: Quality Assurance ===

Quality Assurance starts in week #20 -as does the continued development-, 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 5 Timeline =====

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_5_Timeline}}
|}

=== Phase 6: Final Release ===

This phase is the final release phase, ultimately releasing the final product. This phase is executed repeatedly for 3.0.1, 3.0.2, etc., etc.

==== 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 (3 weeks),

Anything not completed or not according to specification originally included in the Feature Approval goes in to the product's Release Notes.

===== Phase 6 Timeline =====

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_6_Timeline}}
|}

=== Phase 7: Maintenance ===

* Development, QA, Deployment, Maintenance is an infinite loop throughout the product's life cycle.

==== Phase Handling ====

===== Phase 7 Timeline =====

{|
! Phase !! Week !! Day !! Action(s)
|-
{{Development_Cycle_Phase_7_Timeline}}
|}

== References ==

{{Reflist}}

== Copyright ==

This document has been placed in the public domain.