I don't care to comment on everything, I just want to express one major concern here:
"If you can convince a PMC member to commit your patch, they should commit it." Not all PMC members are coders. Simply because you "present" your patch well and can convince someone who doesn't know PHP or our code that it's good doesn't make it so. Obviously not everything should have to funnel through Owen, but at the same time having someone who doesn't know what they're committing add code is also not an option in my opinion. If we're going to take that approach, we may as well give anyone access to commit code. The value in having a select group of members who can actually add code is that review and education process by someone who is more likely to be knowledgeable about not only our code base in specific but best practices in general. We need to find a better way to do this, yes. That is not, in my opinion, it. On Mon, Apr 6, 2009 at 9:29 AM, Rich Bowen <[email protected]> wrote: > > And ... my slightly longer response ... > > > On Apr 5, 2009, at 17:04, Geoffrey Sneddon wrote: > > > > > 1. Don't tell people to "fuck off" as I have been numerous times. It > > doesn't help build a community: it makes people leave. > > +1. Courtesy is important. Courtesy is more important than technical > prowess. > > > > > 2. Don't go around mocking people endlessly making them a joke. It > > doesn't give the place a positive atmosphere, and thus doesn't help > > get people to stay around and become a community. > > Likewise. Courtesy. > > > > > 3. Present a united front as a cabal. A patch should be rejected by > > either all members of the cabal, or by no members of the cabal. The > > reasons for which a patch can be refused should be objective enough > > for this to be the case. > > -1. The Cabal is not a Cabal. It is a Project Management Committee. > The name is a joke, and has been since inception. There is no united > front. > > As for patches -- I think most of them are taken too seriously. If you > can convince a PMC member to commit your patch, they should commit it. > The notion that the entire PMC has to approve a patch is just a recipe > for glacial movement. If someone vetoes a patch and IF they can > provide COMPELLING TECHNICAL REASONS (ie, not just "I don't like that > color of green") then it should be backed out. > > Trunk is CTR (Commit Then Review). Release branches are RTC, with -1 > votes carrying more weight. > > > > > 4. Make it clearer why some people in the cabal and others are not. > > Having some sort of transparency would massively help the > > accountability of the cabal: from what I've heard from some people in > > the cabal, the cabal was founded as the people who were around in > > #habari at the time, which sounds like far more of a cronyism than a > > meritocracy. > > > This is *TOTALLY* not true - revisionist at best, and damaging to the > community at worst. The PMC was founded as the four people who came up > with the idea over pizza at Bucco di Beppo at Ohio Linux Fest. Of > those four, three have continued to produce quality code, and the > other, I hope, has continued to provide sage advice from his > experience with the Perl and Apache communities. Other people have > been brought in by consensus of the existing PMC as they have > demonstrated contributions to the community. Some folks think that we > vote people in more rapidly, while others think we should be pickier. > Thus, there tends to be balance in the force. This is also why a > "united front" is difficult now and will continue to be more difficult > as the PMC grows. > > > > > 5. Don't get into revert wars. This is basically the same as #3. > > +1 in principal, but it's worth discussing what happens when two > committers have radically different views. Folks need to be willing to > let go their personal opinion when the community as a whole outvotes > them. That's amazingly difficult. > > > > > 6. Be clear why things are being done: if a commit is reverted, say > > why; if a patch is refused, say why. Rejecting things without reason > > is not going to make people inclined to contribute, as they do not > > know what is required of them. > > +++1. Rejecting a patch without saying why is rude. Ignoring a > patch ... well, there are many reasons for that. Understand that the > most common is that people have lives outside of Habari, and patches > get lost in the noise. The patcher's responsibility is to agitate and > find someone willing to commit it. If folks tell you to shut up about > your patch, the correct response is "either commit it, or explain why > you refuse to commit it, and then I will shut up." > > > > > 7. Review patches in a timely manner (irrespective of outcome). If > > patches are rotting, why should I bother writing a patch that I'll > > almost certainly have to rewrite because nobody has bothered to do > > anything about it? > > This is really difficult, because people have lives outside of Habari, > and none of us are paid to do this. You can't require folks to do > anything, when they're volunteers. On the other hand, the > responsibility of the PMC is to identify folks that are driving > development, and nominate them for the commit bit. > > -- > Oh! I have slipped the surly bonds of earth > And danced the skies on laughter-silvered wings > > > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
