[Typo3-dev] Slow progress on Glossary project

[Mark Ravitz]

Hi All:

I had a fair amount of free time during the last two weeks
to work on the Glossary project, and wasted it as a result
of poor communications among the Typo3 community
leadership.

As far as I can tell, Kasper communicated with Ingmar who
communicated with Alex and Sylvain who communicated
with Peter who communicated with me.  This happened over
a couple of months and by the time I volunteered, the Glossary
specifications had morphed into something different from
Kasper’s original specifications.  So I worked on the wrong
project for two weeks.

An very excellent solution to this sort of problem is to use a
Project Plan/Requirements document.  The document has the form:

1 Introduction
2 Scope (project objectives, context, limits)
3 Requirements
     3.1 Use Case Analysis
         3.1.1 Actors
         3.1.2 Use Cases
     3.2 Other Functional Requirements
     3.3 Non Functional Requirements
4 Resources
     4.1 Team Members and their Responsibilities
     4.2 Hardware, Software, etc.
5 Software Plan
     5.1 Structural (objects, classes, components)
     5.2 Behavioral (how objects/components interact over time)
6 Risk Mitigation and Management (unknowns)
7 Quality Assurance (testing)

Entries can be very short.  All sections are optional.
It gets created at the start of a project and is never finished.
Everyone involved can edit it.  It works!!!

There is an example at
http://wiki.typo3.org/index.php/EXT/glossary/project_plan

It is a plan for a great Glossary which does not solve
the problems the Glossary was originally intended to solve.
Could the originators of the Glossary project possibly correct this
Project Plan?  (Just delete the incorrect information.)   This would be
invaluable to the current Glossary team.

There is an empty Project Plan/Requirements document at
http://wiki.typo3.org/index.php/EXT/glossary/project_plan_template
if anyone cares to use it.

This is about software engineering.  The sections in the document
were taken from several documents which are part of the Rational
Unified Process software engineering model.

Mark Ravitz