MODULE-PROPOSAL

1. What is a module
A module is a part of GAP that
  - provides a describable functionality.
  - consists of a discrete set of files 
	[unless there is a very good reason]
  - has a well-defined set of authors/maintainers.
  - get credited separately (see below)
 Typical examples would be:
 - Rational functions
 - Lie Algebras
 - The (Library) MeatAxe
 - Stabilizer Chains
 - The small groups
 - The Mac interface
 - GASMAN The memory manager
 - the documentation building and conversion scripts
 
 A module has to define its interfaces to the rest of the system.
 (Typically this is done in one or more .gd
 files but the module proposal could specify something else.)
 Code outside the module is should use the modules only through
 its published interface, except in special cases, which should be
recorded 
 somewhere.

2. User interface/documentation
   To the user a module integrates seamlessly in the system. Module
credit is
 listed in the front of the reference manual (see below).
   3. How does code become a module
   (As crediting is a minefield the following process is quite formal
-- this
 is mainly to avoid later disagreements)
   A collection of files becomes a module if the author/maintainer
 announces this on gap-dev (specifying a descriptive name and the set
of
 files involved, the author list can continue ``historic'' authors who
wrote
 the original code but are not maintaining it any longer) a
(noninvolved)
 system maintainer seconds this claim, and no member of the GAP group
objects
 within one month (so it is essentially a proposal with extra
seconding and a
 longer waiting period). (The aim of the seconding is to make sure at
least
 one other person has read the announcement and agrees with it.)
   Once this is done, the code becomes a module by:
 - Storing the description of the original announcement in a `MODULES'
file
   in `dev' under CVS.
 - Adding the module description to the module credits list in the
manual and
   on the web pages.
 - Putting the Authors/Maintainers names in the Header of the file.
 - An announcement in gap-dev that all this has been done. 
 (this proposal does not make any statement how modules are stored
 (directories &c.))
   The creation of modules might require a split of existing files. In
this case
 the announcement should specify which files are split this way.
   Claiming author/maintainership of a module implicitly includes the
promise
 to monitor gap-forum/gap-trouble for problems with the module and to
 act as a maintainer of last resort for the module and responder of
last
 resort for user questions about the module functionality.
   If a module maintainer does not act on problems with the module
within eight
 weeks after having been reminded of the outstanding problem (we have
a
 person ensuring responses for gap-trouble, haven't we?) the person
finally
 fixing the bug or responding the question may claim maintainership.
 Depending on the amount of his contribution the previous maintainer
will be
 listed as historical author.  
   Vice versa, anybody who wants to work on someone elses module
should liaise
 with the maintainer.
   4. Crediting
   Modules will be credited with authors/maintainers in the reference
manual
 and on a web page. (It is the module proposers responsibility to get
the
 module listed this way.) People with substantial contributions to
code not
 definable as modules (in my eyes this lists would consist of Thomas,
Martin
 and Steve) should be credited separately. The long ``thanks'' list
also
 remains in place.

 [ the above paragraph was Alexander's. I would add Frank Celler SL]
 

 
 5. Technical features.
   The aim of modules is to provide a visible way to credit
contributions
 It also aims to specify ``work areas'' for different
 people that will avoid colliding developments. The latter is not a
problem
 now, but might become as we are more and more spread apart.
   If we want more separation, then we probably want to use
(autoloaded)  packages and  should consider concepts like private
namespaces in that context.

	Steve