Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5

Greg Beaver wrote:

There was nearly no discussion of this for at least a week. Then the RFC was submitted and a few comments were made and addressed. Again, I'd like to ask *why* this discussion is happening now that the RFC has entered voting. Everything that is being brought up now was brought up, discussed, and dealt with before the RFC was even made a proposal in Pepr. The wiki was around for a week or two before that. Have any of you checked the archives to see how this was all discussed before?

I was personally out of town the entire time that the RFC was in proposal stage, and only in town for 4 days during the wiki period. It's summer time, do we really have to blitzkrieg an important decision? Personally, as I gain experience with PEPr, I am less and less satisfied with the voting procedure. Not only is the length of time too short to really get a majority viewpoint, but the ability to change a vote is actually somewhat important. If the voting period were 1 day, the inability to change a vote would be much more crucial. I wonder if it might be possible to consider having a 2-3 week period where you can vote and change your vote. Tracking votes is easy - each PEAR account can only have 1 total vote. Then the tally can be taken at the end of the third week after all of the debate can be at least heard, if not resolved.

the problems dont lie within PEPr. The problems lie in the fact that this is opensource and that we dont get paid to be here and we also dont usually work on hard deadlines. Companies pay people to comment within a timeframe. They also often have the "speak now or forever hold your peace" approach. These dont apply to us. While sometimes the time is too short, sometimes it is too long. The proposal process and how it is implemented in PEPr is the lowest common denominator. That doesnt stop us from applying common sense. This goes for all regulations. Common sense must prevail over any regulation. So anyway can we save ourselves the why now emails? Our goal is to make a decision on a very critical part. Expect it to be difficult. Expect it to be lengthy. Expect it to be changed later. We are doing opensource. We can afford to strive for the right thing (tm). At the same time lets try to find a working interim solution atleast. Whatever it maybe, nobody can claim to know the full effects of either decision just yet (however I claim to know that nobody knows the full effects ..). Anyways the point of this mail was not to favor either side, just to remind us that common sense must previal and that we still should forget that our decisions are never unchangeably cast into stone either. regards, Lukas