[Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On Fre, 2004-03-19 at 13:44, Benjamin Geer wrote:
> Gerd Stolpmann wrote:
> > In order to reach this goal, a number of questions should be answered
> > (best as some kind of community process):
> > 
> > - How can people participate (add packages, fix bugs, improve the base
> >   software)?
> > 
> > - How can the quality be ensured?
> > 
> > - How are decisions made?
> > 
> > - How can the platform be kept open?
> 
> How about a structure like this:
> 
>     * A GCC-like steering committee composed of very
>       experienced, respected Caml developers, who would be
>       responsible for setting overall policy and resolving
>       conflicts in the community.

I hope we don't need such a committee. First we should try to seek a
consensus. I suppose this will almost always be successful, and over
time we will have a situation where the voices of some people will have
more weight than the voices of others, simply because they are naturally
respected.

So I would suggest to postpone such a committee until it is really
needed, when everything else failed.

>     * Mozilla-like module owners, designated by the
>       steering committee.  Module owners would review and
>       accept patches for their modules after public
>       discussion.

GODI currently has packages which are comparable with modules. Every
package has a maintainer. Initially, the maintainer is the person who
adds the package to the repository.

Technically, I don't plan any sort of access control, i.e. everybody
with an account can change everything. Of course, it is bad practise to
change the package maintained by somebody else without notification.

I simply believe that a good practise of cooperation is better than
formal rules.

>     * Rotating GCC-like release managers, also chosen by the
>       steering committee.  The release managers would be
>       responsible for coordinating regular releases and
>       determining when each release was ready.

It is currently unclear for me whether we should have releases at all.
GODI has the ability to update every package separately, so what is a
release?

Of course, for the outer world a formal release is something valuable.

We definitely need a process to determine when each package is ready for
release. We'll see how to do that.

> People could participate by posting proposals to a mailing list; 
> discussion would ensue, and the relevant module owner would be expected 
> to accept or reject the proposal within a reasonable amount of time, 
> taking into account the consensus on the list.  A Mozilla-like review 
> process could be used: the author submits a patch, the module owner 
> reviews it and requests changes, and they iterate until the module owner 
> is satisfied.  For major enhancements, a more formal, detailed proposal 
> format could be used, like Python's PEPs.

There is now a mailing list, see the separate announcement.

I think we will see whether we need formal rules or not. This depends a
lot of parameters that are currently uncertain, e.g. the number of
developers.

> If INRIA was willing, such a structure could also take over development 
> of the standard libraries.

I guess they have their own internal process which is incompatible with
such a structure.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners