[GUSDEV] proposal for community involvement in GUS development

[Fernan A. <fe...@ii...>]

This has been mentioned in a previous email to the list, I'm
resending it (with a few minor corrections and additions) as
a separate message as it may warrant further discussion in
its own thread. 

The issue that I brought up was that of control of the
repository and user involvement in GUS development.

I'm sure that everyone agrees that the repository should not
be open to everyone. All open source projects control access
to repositories. But there should be a way to gain access to
'commit privileges'. The following are standard practices in
the FreeBSD community (the ones with which I'm most
familiar). I believe that these are both fair to all
participants and work well to keep users involved in
maintaining and developing code:

o in FreeBSD every file or group of files has a maintainer.
This is reflected with a line in every file (or in a top
file like a Makefile) such as: 
Maintainer: First Last <em...@do...>

The maintainer is responsible for these files. Users
suggesting changes to these files or sending patches need to
get approval from the maintainer. This usually works by
CCing the maintainer when you create a new item in bugzilla.
Approval is by a simple followup message from the
maintainer. Maintainership is a volunteer type thing,
maintainers that don't work anymore in a certain area can
drop maintainership. Users can request maintainership for
orphan files (unmaintained files). In some cases (big areas
or subprojects, the maintainer is a virtual entity (ie a
mailing list) and maintainership is thus shared by a group
of people. Some files do not have a maintainer and are thus
maintained by 'everyone', discussion of changes and patches
use the mailing lists and tracker as in:
Maintainer: <gu...@gu...>
So as you see there is ample flexibility in implementing
this 'maintainership' strategy.

o some users have commit privileges (they can commit changes
  to the repository). But maintainers != committers. Some
  maintainers do not have commit privileges, some do.
  Committers need to know how to deal with the repository,
  maintainers only need to know about their files or their
  area of development.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/

o Usually you should be a maintainer first, participate in
  mailing lists and send good patches, before you can ask for
  or be offered to have commit privileges. Since having commit
  privileges means that you should also take responsibility
  for committing patches from other people and do work on the
  repository, not all maintainers have or request these
  privileges. But this doesn't affect the development or
  maintainance of the project ... maintainership is the key here. 
  
  Even when you're given the 'commit bit', there is a period
  when you have a 'mentor' with whom you should discuss
  everything before committing (ie your commits should be
  approved by your mentor). Furthermore, even if you have
  commit privileges you cannot commit stuff that is being
  maintained by other people without their approval (of
  course, committers do commit very minor stuff, like typos in
  the documentation or trivial fixes without approval) but
  other than that respect is paid to maintainers.  

  Also, all commits that were not originated by the
  committer have an appropriate line giving credit to the
  originators (either the maintainer or whoever contributed
  the patch, or suggested a solution, pinpointed the
  problem, etc.).

Perhaps some of this is already in place ... I'm fairly new
to GUS, so I don't know how you guys give away commit
privileges or how you acknowledge contributions from users.
But from what I've seen there is no 'maintainership' as
depicted above. From my experience in FreeBSD this is a
great way to have users involved in the maintaince of code
and documentation without giving widespread commit
privileges. It has worked quite well for several projects. 

I hope this adds to the project, 

Fernan