Re: [Phpgroupware-developers] Project Structure

[jason]

On Tue, May 13, 2003 at 02:08:15AM +0200, Dave Hall wrote:
> Hi phpGroupWare contributor,
> 
> Several active participants in the project has expressed their concerns in
> relation to how the project is run. After some discussion, we have decided to
> put a proposal to you and the other contributors, for comment. We also hope
> that the "core team" - ceb, jengo, seek3r & skeeter - will participate in this
> discussion and respect the views of the community.
> 
> Our primary concern is that the project is run by the "core team", which is
> mostly composed of people who are not currently active in the community. We
> have also been informed that this "core team", must be notified of any planned
> development work and approve such development. We recognise that the "core
> team" are the people who have made major contributions to the project in the
> past, but in our opinions this does not give them the right to continue to
> control the direction of the project and its contributors.

100% agree.  The project needs leadership and the current "core team" hasn't
been active enough to provide it.

> The Role of the FSF
> As the project would be democratically run we feel that all developers
> should be required to assign copyright to the FSF, not a member of the CT. All
> domains controlled by the project should also be reassigned to the FSF. This 
> way
> the project and its infrastructure is held by the FSF, to ensure some
> continuity between CT changes.

This only makes sense.

> Developers/Contributors
> We also wish to see the title of developer, changed to the more inclusive
> title of contributor. Not every person who currently contributes to the 
> project
> are php gurus - but they still make valuable contributions to the project.
> We would like to see the current "how to become a developer" document amended
> to spell out the criteria for being
> a contributor for each area of the project. All contributors would be
> expected to:
> 
>     * be available and contactable
>     * maintain their area of the project
>     * assist others in maintaining their area of the project - within their
> abilities

"Contributor" sounds like a better title.  There has tended to be a rift
between the translators and doc writers and the developers, and putting them
on even grounds of project status could help communication and planning.

> We propose that for the first 3 months of a contributor being added to the
> project that they will be on a "probation period", during which time they can
> participate in discussions, but do not have voting rights. The probation
> period is to protect the project from being stacked by those who wish to take
> over.

The probation period for voting is a good idea, but I don't think the new
developer should be limited in making contributions during that period.  CVS
write access, devteam install, wiki, etc. should be available to new
contributors.  It's very discouraging to think that your contributions
aren't appreciated and that new developers are shunned.  The attitude lately
has been very anti-new contributor and that has to change if the project
wants new talent and code.

> Also after 1 months of un notified inactivity a contributor would lose
> their voting rights, and have to serve a 3 months probabation period on return
> or after 3 months of inactivity they would
> lose the title of contributor.

This is just absurd.  Leaders need to be active, casual contributors don't.
Some parts of the project don't receive a bug report or feature request for
6 months or more.  If someone just keeps track of the mailing list and fixes
bugs or updates a doc every now and then, all the power to them.

> Decision Making Processes
... 
> A proposed change to the API would need to documented on the wiki, with
> contributors would be notified on the developer list of the proposal, and 
> given
> 1-2 weeks to comment on it. The final version of the document would then be
> agreed on. A developer or team of developers would then be assigned to the
> task. The developers will be expected to update the wiki with progress on 
> their
> development.

Bzzt. Overmanagement.  I think a standard proposal email to and approval by
the CT would be more than enough.  If someone wants to code a change without
a proposal and send the patch to the list with an "RFC: what do you guys
think?", the CT should be ok with that too.  Rigid management may lead to
rigid thought.

> Development Plans & Reports
> We feel that the CT should produce quarterly development plans and reports
> for the community to review. The reports would outline what is planned in the
> next 3 months and longer term implications of such decisions, and also
> contain a review of the previous report outlining the status of each 
> component from
> the previous period.

Definitely.  The project needs vision badly.  Even the recent release
schedule was a giant leap in the right direction.

Sincerely,
Jason Wies (aka Zone)