Re: Re: new template engine

alexander.merz@s1999.tu-chemnitz.de wrote: > > > accept everything, Pear will become something like hotscripts and > > believe me this will kill Pear. I think that there are thousands scripts > ACK > > > forks _inside Pear_ will be evil for both users and Pear developers. If > > someone ask me, "what provides Pear?" and I answer "Pear provides 3 > > abstraction layers, 8 template systems, 3 documentation methods, ...", > > he probably will think that Pear is at least silly (including me in > > helping that mess to grow ;). I'm friend of improving, enhancing or even > > replacing but not of duplicating. > We should create a standard process for commiting such new classes. > Starting with questionnaire like this: > 1. Is there already a class, that provides the functionality? > yes/no > 2. Is it possible to transform the your API to the existing API? > yes/partly/no > 3. If your answer was 'partly' or 'no', are the new methods caused by: > i. better handling of the stuff and/or > ii. my class more can make > 4. If you answer is 'i.' in 3., your class is > * faster > * more simply > * saves memory > * _______________ > 5. If you answer is 'ii.' in 3., why is it not possible to extend the existing > implementation? Adding bureaucrecy without _knowing_ that it's needed is a very bad idea. If there is one place where overdesign really sucks, it's in formal processes. You'll end up like Norway, where 30% of the working population have public jobs. I see accepting or rejecting packages as a task for the people maintaining a part of the package space, and that community awareness, common sense and design knowhow are the primary factors behind the decision. Right now "all of us" are maintaining "all of it", but that has to change. - Stig