Re: [Phpgroupware-developers] Project Structure

[Ralf Becker]

Dan Kuykendall schrieb:
> Dave Hall wrote:
> 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?

I'm one of this "jonny come latelys", my first API contribution dates 
may 2001 (Group level ACL). It hurds a lot to hear this permanent 
non-acknowledgement for all other contributions then your own, Dan.

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

I had the same idea when I read this draft the first time, the reason 
why I support this too now: The task of these coordinators is not to 
maintain there area, but to coordinate the work in it.

> Also its not really fair to have someone who is responsible 
> for internationlisation to be on equal grounds with the API person.

Why is it not "fair". For the user of phpGW (outside english speaking 
contries) internationalisation is far more important then any API.

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

Just to give one example: When the phpwebhosting symlink disappeared 
from our CVS, we wrote you a mail. Nothing happend for days and we wrote 
to the savannah hackers to help us in that matter. You imediatly 
responded to them, you will take care of that matter. Nothing happend 
again for some days, 'til we wrote to the savannah hackers again and 
they made the necessary changes for us.

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

This shows more the importance, of assigning everything to the fsf, then 
any other argument raised in this paper.

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

I'm pretty sure our contributors are mature enough to know which are the 
areas of there knowledge and not vote on stuff they have no idea about.

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

The proposals should be the start of the documentation of the class or 
service in the API.

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

I can not agree with that, maybe I have too much faith in people.

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

This again only the view back into the past. And I will not start 
counting the number of lines I or someone else contributed.

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

As you have all means to do so, in the current setup of the project, 
this will be the only solution left.

I hope we all learn from that for our future and the future of the (new) 
project.
This includes me too, as I looked too long only for the technical side 
of phpGW and felt very angry from time to time, without articulating and 
changeing it.

Ralf
--
----------------------------------------------------------------------
Ralf Becker
OUTDOOR UNLIMITED Training GmbH                Telefon 0631 / 31657-0
Leibnizstraße 17                               Telefax 0631 / 31657-26
D-67663 Kaiserslautern            EMail address@hidden