phpgroupware-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[phpGroupWare-users] Re: [phpGroupWare coordinators] Goodbye


From: Maât
Subject: [phpGroupWare-users] Re: [phpGroupWare coordinators] Goodbye
Date: Sun, 11 Oct 2009 09:52:49 +0200
User-agent: Thunderbird 2.0.0.23 (X11/20091009)

Sigurd Nes wrote:
>> From: Dan Kuykendall address@hidden
>> Sent: 2009-10-06 08:22:41 CEST
>> To: address@hidden
>> Cc: phpGroupWare Developers address@hidden, phpGroupWare Users address@hidden
>> Subject: Re: [phpGroupWare coordinators] Goodbye
>>
>> Hi all,
>>
>> My preference at this point would be to shut down the project. It seems
>> like the codebase is just too outdated. Maybe at somepoint it would be
>> worth picking up and starting from scratch with all thats been learned
>> both in phpGW and across all the various projects in the open source
>> community these last 9+ years.
>>
>> Anyways, if a clear vision can be had and a developer to continue it is
>> around, then please contact me... otherwise a leaderless project is a
>> dead one.
>>
>> Dan
>>     
>
> Hi all,
>
> I have plans for it and want to keep it alive.
>
> I think the best approach will be to focus on the system as a general 
> application development framework - starting with the API and some core 
> modules (admin, setup, preferences).
>   
Every single framework does that... and many better than we do : Zend
first of them but also Symfony, drupal, eZ...

If we plan to gon on their scope we are dead...

> I also think the majority of the existing applications without a minimum 
> level of maintenance has to be put in a historical archive for future 
> reference and a possible source of inspiration only.
>   
That makes sense but the svn system as i re-organized it just need to
change the list of externals to let these module aside

> Important features are:
>  * user-handling
>   
Yes and there we'll need to put hard work

And part of this work will involve thinking about template system :
coders are often very poor interface designers

And good interface designers have often very poor php and xml skills.
Dreamweaver (sorry guys for the ugly word) and css and htmls are their
worlds.

Relying on current xsltemplate even if it's sexy on the paper  will
ensure  that zero descent web designer will be able to get in and help
us make nice  looking user interfaces.

As far as web design is concerned the previous phplib based  template
system was loads better.

>  * integration capabilities (xmlrpc/soap/ldap...)
>   
Agreed

>  * building blocks for ui as super-objects prepared to utilize common 
> elements (as tables, lists, calendars)
>   
Not agreed

>  * mechanism for internal integration across modules
>   
Agreed a million times

> I will fix the API (and core) to a usable state (running php 5.3) - and 
> update to the latest 3-party libraries.
>   
Ok on the goal but if we go on we'll have to discuss the method : i
don't wand to see a giant commit changing things everywhere whitout more
thant "Merge from my working company tree"

Suvbersion is all about keeping track of changes and helping bug hunting
by the means of changelog and commit date analysis

A million times okay for code fixing... but a million times not okay for
giant commits impossible to check

You probably did not even consider such commit... in this case please
accept my apologies for this part of my mail :)

> I think that once the system is in a shape that makes is possible to install 
> and operate - it will attract developers and users.
>
> Regards
>
> Sigurd
>   
indeed having something that installs and works would be a nice idea :)

but if you want to attract devs ans users that will not be enough

we'll need documentation (people willing to write it) and user + dev
support (people willing to help people getting in... explaining things
again and again)

And till we have enough manpower to make separate teams for support and
developpement and doc writing and betatesting the remaining people will
have to be everywhere










reply via email to

[Prev in Thread] Current Thread [Next in Thread]