Re: [Phpgroupware-developers] Project Structure

[Jim Foster]

Just a general observation from a user who has been developing sites based
on phpGroupWare since Q4 of 2000:


Let's put aside the technical details, for a moment.

What is forcing me away from further work with phpGroupWare is the tone from
statements such as these:

---------------------

... you are wrong to think that this does not give us the right to control
the direction of the project ...

... this is the kind of crap that is going to continue to make me oppose any
such lame schemes ...

... but with this type of crap turning up it will be a cold day in hell
before it happens ...

... I will pull back control of the project and force it to fork before it
will even come close ...

---------------------

This is not the first time I have heard this ringing of attitude, but it
will definitely be the last.

Why would anyone want to continue to do any kind of serious development with
a tool - despite its technical merits - when management has this kind of
close-minded orientation from the get-go?

For me, the hand-writing on the wall couldn't be larger.


Jim Foster
IS Manager, address@hidden
TMTS Web-Site Design Services


----- Original Message -----
From: "Dan Kuykendall" <address@hidden>
To: <address@hidden>
Sent: Monday, May 12, 2003 8:12 PM
Subject: Re: [Phpgroupware-developers] Project Structure


> 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)
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>