Just a thought from a non-dev Rules/policies/procedures/process should always be written down or recorded somewhere, otherwise how do you know what they are? and how do you make sure changes to those rules are known about? Having a central place that every can reference (wiki) makes a ton of sense.
This doesn't mean they have to be inflexible. Flexibility is down to how those rules etc are written. this is fairly basic service management sort of stuff. (No i am not proposing bringing in ITIL/CMMI would be sensible) By having this sort of stuff in the wiki, you are making it easier for new people to get up to speed and reduce the arguments over what the agreed method of doing X is. James -----Original Message----- From: i...@tyrael.hu [mailto:tyr...@gmail.com] On Behalf Of Ferenc Kovacs Sent: 23 November 2010 14:10 To: Derick Rethans Cc: Felipe Pena; internals Subject: Re: [PHP-DEV] [RFC] Release Process On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans <der...@php.net> wrote: > On Tue, 23 Nov 2010, Ferenc Kovacs wrote: > > > > All the rest you write in the RFC is basically already as we do it. > > > > yeah, maybe, but they aren't written down, accepted and well-known rules, > so > > you can forgot/misunderstand/bend them. :/ > > And I don't think that is a bad thing. It's good to be able to be > flexible. > > Derick > > Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
