Re: [Phpgroupware-developers] Project Structure

[Dan Kuykendall]

This was discussed a little on IRC. Here are the primary changes needed 
for this to be something I can agree with.


> "Core Team" Restructure
> We propose that the "Coordination Team" or CT (formerly know as the "core
> team") is elected for a term of 12 months, by the active contributors to the
> project. The role of these people is to coordinate the project for the period
> they are elected and take
> responsibility for the day to day operation of the project. We feel that
> there should be 7 positions and each has an area of _primary_ responsibility -
> these areas being:
>
>     * API
>     * Applications
>     * Support
>     * Internationalisation/Translations
>     * Documentation
>     * Colloboration
>     * Sponsored Development
>
>
> The allocation of areas of responsibility are decided by those elected. In
> addition to these areas of responsibility we feel that the CT, as a group,
> should also be responsible for the following:
>
>     * be available and contactable by the community
>     * furthering the development of phpGroupWare
>     * guide the strategic direction of the project - in consultation with
> all contributors
>     * further collaboration between phpGW and other compatiable projects
>     * encourourage participation in the community
>     * ensure efficient operation of the project infrastructure
>     * administer the sponsored development program
>     * be the contact point for the FSF
>
>
> If a developer is "AWOL" for more than 3 months, their position would be
> declared vacant and a by election conducted to elect a new person their
> position. We acknowledge that all contributors need a break from time to time, 
> but
> they must notify the project of this and make satisfactory arrangements for
> their period of absense.

In addition to the 7 will be 4 permanent positions for jengo, ceb, 
skeeter and myself. These are the founders of this project and have 
earned the right to have these positions as long as we want them.
Keep in mind, that if we are not active, we will not end up voting and 
therefore have little impact. So we only will have impact if we are 
active. Additionally, the 4 founders will need to have veto power.

> 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.

I will still probably sign over copyright of my code. I have no 
intention other than to keep it GPL'd. The trademark and domain are not 
negotable, I am keeping both.

> 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:

Agree

> 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. 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.

I like the 3 month probation. I think the one month inactivity is way 
too harsh. This needs to be figured out to give a better balance. Its 
also said "unnotified inactivity". If a developer notifies us that 
he/she is leaving for 6 months, it would seem unfair to hold his 
position if an unnotified gets booted after only 1 month.

> Decision Making Processes
> We feel that at the moment there is very little accountability with in the
> project. We would like to see this changed. For example the CT could be
> required to meet once a month, with minutes made publicly available. We also 
> feel
> it is important for discussion on important issues to be held in a public
> forum, where all contributors are encouraged to participate. One issue which we
> feel should involve the community is the db abstraction layer - phplib vs PEAR
> vs ADOdb. A poll of contributors could be conducted in the devteam install
> on phpgroupware.org - with documents outlining the pros and cons of each side
> of the debate being on the wiki.

This is a good idea. We just need to prevent creating too much 
management overhead.

> 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.

This is not too cool in all case. It only needs to be used in cases of 
major changes.

> We also feel that the CT does not have the power to make decisions without
> involving the community. Where possible the community should be the ones who
> make the decisions not the CT.

This needs major refinement. Straight popular opinion of all 
contributors is a very bad idea. Contributors who help translate into 
their native language have no business voting on which db abstraction 
class we use.
We need to have contributors classified by the 7 previously mentioned 
areas. Some contributors will be in multiple groups based on their 
contributions. Then we need to classify the issues, and have only the 
groups impacted/involved vote on the issues.

As mentioned, the founding four would have veto power.

> 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.

This is a good idea. It just needs to be done in a way that its doable. 
This could very easily turn into far too much management overhead.

> Conclusion
> We feel that all active contributors to the project should be the ones who
> control its destiny, not a group of former developers. 

Let me state my case about the founding four.
I understand the desire for new contributors to want to be able to 
really get involved and impact the project. This is a very good thing. 
Dave Hall is a good example of someone who has helped breath new life 
into the project again. And in return I have been very open with giving 
him admin rights to the savannah project, full access to the website and 
in general I have supported what he has wanted to accomplish.

However, it must be remembered that the founding four have poured insane 
amounts of time and energy into this project for over three years. 
phpGroupWare would simply not exist without us. As a simple matter of 
respect it seems like a major disgrace that any jonny come latelys would 
think we have no "right" to continue to have some control over this 
project. We have every right. We started the project. We have done the 
most to bring it where it is today.

Also, as it stands, phpGroupWares current code is not all that much 
changed since the new group of active contributors became involved. Its 
largly the same codebase, with lots of nips and tucks here and there.

It seems to me to be perfectly reasonable to demand that we have 
permanent positions in the Coordination Team.

As far as the veto rights. It seems like it may need reminding that lots 
of contributors have come and gone over the years. However on the whole 
the founding four have always been with the project. I personally keep 
in touch with jengo from time to time, but he has not the time to be 
involved now. So it is important that we have veto powers to prevent a 
group of newcomers to jump in and hijack the project and make changes 
that go against our primary goals. I think it would be incummbant on the 
founding four to only use veto's where we feel it is absolutly 
nessesary. But it is a power we deserve to have.


Dan