Re: removal of this list

Travis Swicegood wrote: > That is my suggestion. Once we have this figured out, I would love to > see it go the way of the PEAR Group. People nominate people to be > elected to the group that oversees the governing of the standard. > That said, at tek we had a large enough representation of the various > groups to feel we have a consensus, and we started on it rather than > opining on internals@ or any newly created list that we needed such a > body. > > As far as "excluding", I don't think there has been any mention of > excluding anyone. Membership is closed, but anyone can ask to become > a member. All it takes is a vote of the group to add a new member to > the mix. As for the "closed" part, the list is publicly available for > anyone to view: > http://groups.google.com/group/php-standards > > That's a glass house. Don't like what's being said there, call us on > it. Blog about it, tweet it, etc. I live a pretty public life and > even have my main, everyday email address posted on my website. I'm > glad to respond to anyone with a reasoned suggestion or criticism. > > Hopefully I can be proven wrong over time, but the decision to make > the main mailing moderated seems to have been the right one. Everyone > has a favorite color when a bike shed is at stake, but the shed still > needs to be built. Hi Travis, Perhaps seeing the way it looks helps to understand where I'm coming from. I happen to be a vocal person, but I do have to say that the few people from PEAR who have approached me off-list have all expressed either the same reservations about the standard, or the same reservations about the openness of the process. I've been heavily involved in the community wrangling over language details and standards in the past, and there have been moments where bike-shedding became an issue, but I've never encountered a bike shed issue within 2 weeks of announcing an idea. Namespaces, for instance, took 5 years to reach a point where they resolved the major issues found, and once the current implementation was proposed, it had to undergo some significant technical transformations to resolve some non-obvious and serious issues with the design (not just the implementation), not the least of which was the unique problem posed by PHP's autoload feature. We had to argue like parliamentarians for months to even discover some of these issues, and real consideration for the points of view of anyone took place. Even stupid ideas (like using # as namespace separator) were answered. Sometimes with snark, but still answered :). On the other hand, the final decision on which separator to use was made in a single 4 hour international IRC meeting. The entire meeting was logged, and posted unedited along with the decision, and any criticism that wasn't "you're stupid, that separator sucks!@#" was answered with technical rebuttals, because we literally considered every single one of them. In the end, my experience with standards is that you do satisfy a majority of developers, but you can't know whether you are satisfying them unless you are completely open about the process. I should say, finally, that you say "make the main mailing moderated", and "I don't think there has been any mention of excluding anyone" in the same message. What is moderation if it isn't excluding some viewpoints? There is no spam problem (a good reason for moderation) or a problem of off-topic trolls (another good reason), so the only reason for moderating would be to exclude other's viewpoints. There isn't even a problem of many people saying the same thing over and over, or potential of NGA violation (the reason Apple's dev lists are moderated). Volume is also not a problem. See my point here? Moderation = explicit exclusion and is the reason Rasmus is philosophically against having it on php.net. Greg