accolades

To the development team:

 

I want to congratulate you all on a job well done. ; K-M is a truly remarkable achievement, especially when one considers that the development seems to have occurred with only limited management.

 

I stumbled onto K-M while surfing a few days ago.  After reading a bit, I decided to download and try it out.  I expected a primitive, immature, incomplete and buggy alpha/beta product.  What I found is a product superior to both IE and Firefox (IMHO). (K-M is the best kept secret in WebWorld.)

 

That said, I suggest that the development team face the reality that K-M is inevitably destined to become the most popular browser in WebWorld.  Tremendous pressures will arrive concurrently with this fame. ; The bottom line is: you are not ready. No one is ever ready for the pressures of a massive expansion. Scared? You all should be scared.

 

So, you have a choice.  Quit the K-M project (e.g. hide from the coming expansion), or prepare for the expansion (decide to ride the tiger and become famous and probably rich).

 

An early step in preparing for the coming pressures is to bring the beautiful, maturing monster that is K-M under development control. This requires a formal, documented Statement of Objectives (SO), a requirements document, to give direction to continuing development. 

 

A System Specification (SS) and WBS (Work Breakdown Structure) to give concise task level direction to technical development should elaborate the SO.  In addition, a clearly defined authoritative implementation management structure is essential to success.

 

How to proceed may seem illusive so let me suggest some things:

 

1. To begin, the development team should designate (elect) a Lead Developer (LD) and a deputy.  (The primary mission of the deputy is to perform the duties of the LD in his/her absence.).

2. The LD develops and maintains the SS and a derivative WBS (work breakdown structure) of the tasks necessary to implement the various elements of the design.  Each element (WBS task) must be elaborated by an SOW (Statement of Work) that clearly defines end product(s) of the task. ; Task durations should be less than six weeks.
3. The LD assigns (allocates) WBS development tasks to other developers, as he/she deems appropriate and according to the desires of the individual developer.
4. The LD (and his/her assistants) will post unassigned WBS tasks in an ad hoc forum.  Developers desiring to participate in development will do so by volunteering for tasks in the forum.
5.  Developers will report their task progress weekly, or more often, as deemed appropriate by the LD.

 

(Note: Thus, the LD forum will continuously reflect the status of the development (broken down by WBS element task) for the information of interested developers.  Visit

 

         ;      http://www.projectconnections.com/jsp/regfinish.jsp

 

for software program management templates, requirements guides and examples of WBS documents, flowcharts and schedules.)

 

The SOW’s (Statement of Work documents) for each task also provide the informational basis for the development of related user manuals and other documentation.

 

M-K functional enhancements (new requirements) begin as additions to the SO.  The SS and WBS are an elaboration of the elements of the SO.  

 

3. Enhancements (in the form of additions or modifications to the SO may be recommended by any K-M registered user via the EF (Enhancements Forum (to be established.)) and by editing the current SO-wiki and SS-wiki (to be established).

 

The K-M Administrative Council (AC) is responsible for initially creating the SO-wiki and SS-wiki, and for maintaining and freezing them periodically (as design targets for the LD).  The LD utilizes the current SS as the hard target for development efforts.

 

K-M registered users elect the members of the AC (13 are suggested).  The AC members elect a Chairperson (and Vice Chairperson (VC), who acts as Chairperson in the absence of the formal Chairperson).  Typically, the VC automatically relieves the Chairman when her term expires). 

 

The AC utilizes the EF and SO-wiki and SS-wiki as source data for K-M version design freezes.  At freezes, the SO and SS (actually the WBS) become the de facto current design targets and the basis for documentation detail.  The wikis become the baseline configuration point of departure for the subsequent version. 

 

The Chairman unilaterally determines the content and timing of K-M core version and plug-in design freezes.

 

The Chairman appoints a QZ (Quality Assurance Czar) and a DZ (Documentation Czar).  (Czars train and appoint their deputies, who ultimately become their replacements.)  

 

Note: The QZ and DZ do not report to the LD.  They report directly to the Chairman. The QZ certifies (to the Chairman) the functionality of the current M-K version at release (with exceptions).  The DZ certifies (to the Chairman) the accuracy and completeness of the current M-K documentation to support the current M-K release (with exceptions).  Only the QZ may authorize the formal release of Beta or final M-K versions to the user population.

 

The QZ and DZ do not rectify exceptions.  They define them and report them as tasks in WBS SOWs and post them in the development forum (EF) for volunteers to undertake.  The QZ and DZ will each maintain a blog or forum to interact as necessary with volunteers addressing exception WBS task  s.