[Typo3-dev] I don't want to fork!

[Elmar Hinz]

Hello David, Kasper and interestd guys,

thank you for your positive answer and interest in joining in, David.

For the biginning I make out three fields:

1. Database
2. API-Level
3. Functional integration

Every field needs to contribute documentation to best practice guidlines 
and developer tutorials.


* Database:

An intelligent definition and evolution of the portal relavant tables
(fe_user, fe_groups, fe_roles (?), tt_address, xyz_calendar (?). All as 
future proof and backward compatible as possible.

That is the stuff we have just started to discuss. It is the field you 
are interested in coordinating it.


* API-Level:

DB-Layer, form library that respects TCA, interfaces, hooks and services

That is the field Kasper is interested in. It's very important for 
flexibility and interoparibility of the extensions. But as we still have 
a working API we can be delay it for a while until Kasper has more time. 
When they have done the BE refactoring.


* Functional integration:

How our customers expect everything should work together in the FE.

That is the field I could imagine to coordinate for the beginning. I 
regularly have to read their wounderful and instructive wishlists.


All these three fields are closely connected. That is why we need a 
common team and and coordinating leader for it. I think an experienced 
developer of a successfull extensions could be a good solution.

 From this three fields other may fork off (documentation, support, 
internationalization, customer specific adjustments, fe developer 
community, TER, ... ). But I would propose to concentrate on the three 
above first.

How do we go on now?



Elmar



























David Bruehlmeier wrote:
> Hi Elmar,
> 
> sorry for not writing earlier... I cannot post news at work.
> 
>> It would be a usefull step to define an officially accepted model for
>> fe_users and tt_address in the first step and then get it implemented
>> into sr_feuser_register of Stanislas.
> 
> 
> Let's not jump to solutions. I think we could do better than that. :-)
> 
>> Joey and David show visions and experience how about the DB model in 
>> this thread.
> 
> 
> I could well imagine to take over the coordination of a specific effort 
> (e.g. like a solid partner management with all related issues). I would 
> in no way like the task of an overall "extension coordinator".
> 
> I am currently working on a proposal for such a project and I am 
> planning to post it to the Wiki by the end of the week (hopefully... :-)
> 
> Even though I have done some development, I do not consider myself a 
> *real* developer. Coordinating a project with a specific goal would fit 
> my "day-job" better, but I must say that I have not yet lead a "virtual" 
> project in an open-source community. This would be a first for me.
> 
> Let me propose this:
> 1. I publish my project proposal in the Wiki
> 2. Anybody interested can join the discussion about the proposal for a 
> week or so. (on the Wiki and in a separate thread)
> 3. If we can agree on the common base and if there is enough "manpower" 
> interested in joining the team, we have a go.
> 4. If we get this far ;-) I want to have official support from the R&D 
> committee. By support I do not mean financial support but things such as 
> "management attention", agreement on the roadmap, review of the design, 
> perhaps code-reviews of critical parts, etc.
> 5. Then we create the design, split it into development tasks and get 
> going.
> 
> What do you think?
> - Dave.


-- 
Climate change 2005: Mexico, Guatemala, New Orleans, Sahel, Bangladesh,
Spain, Portugal, Austria, Swiss, France, ...
Production of CO2 is killing people.
Production of CO2 just for fun is killing people just for fun.