Re: [Phpgroupware-developers] Project Structure

[Reiner Jung]

Am Die, 2003-05-13 um 05.12 schrieb 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.

This is one point what is wrong in this project, when only 4 people make
the decisions. When the other don't agree the core team have the full
control about in which the project will go. Nobody outside the core team
have this possibility!
> 
> > "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?

Cool, all the jonny come late make the job for "your" project ? The have
the rights to create code for you? the have the rights for translation.
The have the rights to give support. 

Have they more rights, or it is enough that they be members in your
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
> 
> 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.

What is here the difference between between people which organize the
translations and other things and the API programmer? Is the API
programmer a better man only why he knows how programming in PHP.

The other make important jobs to. Without this people phpgw don't work.
> 
> > 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.

Yes, this a real democratic way to handle a project. When you don't
agree with me, the i have my code and my domain. This are your
arguments?
> 
> > 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

This terrible flaw is democracy 
> .
> 
> > 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.

How you pull back control over the project? You want kick all out which
not agree with you? 
> 
> Dan Kuykendall (aka Seek3r)
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers