Re: [Phpgroupware-developers] Project Structure

[Dan Kuykendall]

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.

I am here and will participate in this discussion.

> 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 only need to be involved with "core" issues. Such as any major 
changes to the way things work, or any changes in the API. We also try 
and have at least one of us involved because we know how and why phpGW 
works the way it does. We better than any others are able to know the 
various dependancies and how new stuff should be introduced.

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

Yes, we have made major contributions in the past and still continue to 
make many. But you are wrong to think that this does not give us the 
right to control the direction of the project. Because we wrote the VAST 
majority of the code, the trademarked name, the domain and savannah and 
sourceforge projects, we have every right morally and legally to control 
the direction of this project.

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

In concept this isnt entirely a bad idea. However, none of the current 
core team is going to submit to a solution that would allow several 
jonny come latelys to vote us out of our own project. It just isnt going 
to happen. I also want to know what "active contributors" means? Who 
decides who is active or not? Who decides what consitutes a contribution?

> 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

This group of seven will not work out well. Its a good start, but the 
API is not easy and having only one person assigned to this is not a 
good idea. Also its not really fair to have someone who is responsible 
for internationlisation to be on equal grounds with the API person.

> 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

All of this is currently handled by the core team to some degree or 
another.

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

What do you consider "AWOL"?
This is one thing that pisses me off. I answer emails sent to me. I try 
and follow the mailing list. But if I dont show up in IRC I get 
considered "AWOL", without even someone sending me an email. I have seen 
a couple of you say I "disappeared" and have blamed me for holding back 
progress. And yet I havent recieved a single email asking me about the 
issue.
This is the kind of crap that is going to continue to make me oppose any 
such lame schemes.

> 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 am not going to assign my code away. I was planning to in the past, 
but with this type of crap turning up it will be a cold day in hell 
before it happens. Same for the phpgroupware.org domain.

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

This is a very good idea.

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

Again, who decides what consitutes a contribution worthy of the status? 
What consititues inactivity? IRC time?

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

This isnt a bad idea.

> One issue which we
> feel should involve the community is the db abstraction layer - phplib vs PEAR
> vs ADOdb.

This has been discussed at length in email. I spent about 200 hours 
invisigating PEAR, I even became a PEAR contributor in the process. 
However it will not work well in the phpGW structure, and redesigning 
phpGW to work with PEAR would be a major hassle.
ADOdb is nifty and such, but again it is not worth doing since our 
current DB abstraction works just fine.

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

You keep flipping back and forth. First you say there is a leadership 
team, which indicated a representative republic type structure.. now you 
are saying that some things would be done by popular vote. This is 
pretty lame, because most contributors are not "coders". So why does 
someone who helps translate to spanish have the same vote as someone who 
works in the API or core apps?

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

I assume you would only want this for major changes to the API. It seems 
like your starting to create too much management overhead.

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

OK. Now you have cleared up the limit of the CT. Basicly you want it run 
 by popular vote of the contributors. This is terribly flawed because 
people outside of the issue are of equal vote.

> 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 seems like a bit too much structure for this project. Your going to 
spend more time in discussion than in development.

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

This is just wrong. Not all contributions are equal. Maybe this isnt 
"politically correct" to say, but its the truth. Each member of current 
core team has individually contributed more than all others combined. I 
think its handy to have stuff translated to spanish, but thats just not 
compariable to somewhere around 20,000 lines of code and about 3500 
hours which I have personally pumped into phpGW.

> We think the structure
> outlined above is heading in the right direction, but this is not a final
> proposal - please contribute to it here or on the wiki (see
> http://phpgroupware.org/wiki/restructure ). This is only a draft document, we 
> seek your input
> into the future direction of the project.

Its an interesting discussion. But as it is setup now I will simply not 
agree. I will pull back control of the project and force it to fork 
before it will even come close.

Dan Kuykendall (aka Seek3r)