Below is a reply to all the emails in the thread since my last post. Apologies for the length, but I was away for a week, and have since been in a mad rush trying to finish coursework and then revising for exams . Also, I've omitted a lot of what is quoted, for fairly obvious reasons (i.e., there's a lot of stuff). If something is omitted, I probably agree with it, though. Oh, and I wrote this fairly quickly, so probably parts of it don't make sense. Just ask.
On 6 Apr 2009, at 02:03, ringmaster wrote: > On Apr 5, 5:04 pm, Geoffrey Sneddon <[email protected]> wrote: >> >> I think the >> cabal needs to take a good look at each of its members, and ask >> itself >> what each member has done to deserve to be part of the cabal >> (submitting a couple of patches isn't deserving of merit in itself, >> fixing a large number bugs without introducing regressions is >> deserving of merit), and also ask itself whether each member is >> helping or hindering the community. The bar to entry to the cabal is, >> at the moment, far too low, and as far as I can tell there's no >> movement, ever, about removing people from the cabal. > > I should point out that membership in the Habari PMC only terminates > when a member resigns or is voted out by the rest of the PMC for some > reason. There was never an intent to expire membership. It seems > like you're suggesting that membership only continue while > contribution is consistent, and perhaps it's reasonable that continued > positive involvement should be a requirement of continued voting > rights, but there is no current requirement that this be the case. > Members are welcome to remain idle until such time they decide to > become involved again, and when they do, they are expected to continue > in the same capacity and spirit for which they were originally > inducted. This isn't what I mean: what I mean is that what some people have done to be in the cabal is unclear, and whether some people are fulfilling the role that the cabal is meant to (according to the wiki page) is equally unclear. > Mind you that Cabal selection is not based solely on contributions, > but the willingness to foster the kind of project that the rest of us > have set out to build. Someone who has only a personal agenda isn't, > at least in my mind, someone who should be a PMC member. There is a > bit of subjectivity to the Cabal selection process. I think you want > trust and a shared vision, otherwise there would be a lot more > fighting than there already is. I think expecting "the willingness to foster the kind of project that the rest of us have set out to build" can be detrimental, as it makes the project very one-sided and single-minded, which in a lot of ways is the worst possible way to run a project. I think in a lot of ways the cabal already is very single-minded, though I can't point any finger at why. >> Well, the simple solution would be to make me part of the cabal. :P (If it wasn't obvious enough there's quite a lot of sarcasm in that comment.) >> Well, in the case of patches, I can't do anything but complain: it >> needs to be with somebody with commit access who does something, and >> hence someone in the cabal. > > Ah, not so. > > This is what I'm getting at. Sure, you might not have the power to > commit, but you do have the power to review. If you were to review > patches in a way that applies your need to have review, evaluates in > balance the relative good in its improvement to any detriment, and > provide a consistent and reliable recommendation on which committers > could act, you would yourself provide a valuable enough service that > you might be recognized for that service as a PMC member. I think such things need to be documented, as it is drastically different to almost any other RTC process I've ever come across (where being able to review patches is a very-hard-to-come-by-right). >> 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. > > I'm not sure this is practical without a place for the cabal to > privately review each patch and come to a consensus before offering a > unified opinion. And since we're not in the habit of privately doing > much, Trac seems the place to do that. I suggest rather than the > specific wording above, we have a more formal way to annotate patches > as reject or keep. Apply this to #5, too. At least with patches the criteria should be objective enough that the vast majority of the cabal should either accept or refuse it. I think what I had in mind when I wrote that was a case when I had been told a patch couldn't and wouldn't go in by one member of the cabal, though no comment on trac was made, and a few weeks later it was committed. If someone says it couldn't and wouldn't be committed, I don't expect someone else to go and commit it with absolutely no discussion. As I've said before, having a clear set of criteria of what patches must be encourages contribution, as it makes it easier to tell whether a patch will be accepted or not (and hence whether there is any point in spending time in writing it). This is part of the reason why I've contributed what is probably an equal amount of code after becoming a member of the cabal (around a month ago) to what I contributed over the two years prior. >> 4. Make it clearer why some people in the cabal and others are not. > > I think that with what I said early in this reply about the criteria > of membership, this item does not apply. Your membership today will > be valued for what you do today. Others' membership expires as I > described unless there's some policy change. Sure, but how do I know Person X actually deserved to become a member of the cabal and wasn't just appointed through cronyism? The process for admitting members to the cabal is completely opaque. >> 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? > > I hate to remind everyone that this is a volunteer project. I have > two kids, a wife, a job, and a beautiful first no-jacket day of spring > I'm ignoring right now to write this reply. Some times there just > isn't going to be anyone around to commit stuff. > > However, if there was some reliable way to enqueue tickets for review > and commit, this process could be improved. I've added a feed to my > reader that shows tickets with has_patch. I'll see them and comment > on all of them as I am able. I'm not sure if that's enough or not. > We'll see. I don't think the "volunteer" necessarily stands up with the size of the cabal it is: I find it highly unlikely that no member the cabal will have the time to at least have a first, quick, look over a patch and provide some feedback within, say, a week. The problem is that as far as I can tell there are quite a lot of people within the cabal who take the egoist view that only what they are working on matters, and don't care for things like this that help to foster a community and get more developers. >> To put my actions where my mouth is, I believe all of the above >> happens within the SimplePie community, to the extent that they apply >> to an aristocracy (which is more or less what the governance of >> SimplePie 1 development: changes are abound for SimplePie 2 which >> should make it more accountable and give it a clearly defined >> process). If anyone can point me to counter-example, please do so. > > My understanding is that the number of primary committers to SimplePie > is 2. That means that nearly everything has to funnel through you. > If you don't do it, who will? It also means that decisions are > easier, because you're the only one making them. There are three (at least somewhat) active developers. I think the "If you don't do it, who will?" comment is fair though, and is one thing a lot of medium-to-large projects (in terms of developers) suffer from: "Heck, it's not much, someone else can do it." However, inevitably, everyone says that and nobody does a lot of the more tedious community integration work. Decisions within SimplePie are basically made by someone doing something and seeing if anyone complains, no matter how big an issue it is (which is more or less taking CTR to a fair extreme). > With so many people able to do so in Habari, it seems like there > should be multiple people reviewing code. I'd hate to find out that I > was the only person expected to do so. > > Is anyone now in the PMC able to step up and assume code review as his > own task? I think you don't even need to do the actual review, just > get it into the hands of the person who can. I certainly will when I can, but like you I'd hate to find out that only one person was expected to do so. > What other action items do you see that would improve the situation as > you perceive it? Is directed at me or the then-PMC? I can't think of any others. On 6 Apr 2009, at 02:19, Sean Coates wrote: > Some review does happen, and I don't expect that to be on the > shoulders of any single person. One of my patches from this week was > partially rolled back. I don't mind -- it worked for me, but not for > everyone. > > In fact, I even rolled back one of Geoffrey's patches this week > because it was causing the upload functionality in the silos to break > (content-type header related). I contributed it in good faith: I believed it to work in all browsers, and had been told by the ed. of the spec of it that it did. I do, however, think there is a double standard: if someone within the cabal commits code that causes one browser to break everyone shrugs their shoulders and gets it fixed; if someone outwith the cabal contributes code that causes one browser to break they lose trust from some people and it becomes harder to get code committed. On 6 Apr 2009, at 02:53, Arthus Erea wrote: >>> 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. >> >> I'm not sure this is practical without a place for the cabal to >> privately review each patch and come to a consensus before offering a >> unified opinion. And since we're not in the habit of privately doing >> much, Trac seems the place to do that. I suggest rather than the >> specific wording above, we have a more formal way to annotate patches >> as reject or keep. Apply this to #5, too. > > I don't think presenting a united front should be important. We > certainly shouldn't add more bottlenecks than already exist. > > In fact, I think such a united front (and the private deliberations > which would be required) is contrary to the Habari ideals of > transparency and openness. There's no reason Cabal members shouldn't > be able to argue amongst themselves (and the community) about a patch, > to reach an eventual consensus in public. There isn't, in itself, really much problem in arguing in public (in fact, I'd say it is better to do it than in private), but as I said, I was more meaning being united on things that should be primarily objective (and hence the cabals should all agree). Arguing in public becomes a problem when it has short-term effects on a project (e.g., committing a patch), when, as above, one person refuses the patch one week, then two weeks later it is committed. There is no reason a project with the number of developers of Habari cannot act in a more timely manner. On 6 Apr 2009, at 11:11, Scott Merrill wrote: >> 4. Make it clearer why some people in the cabal and others are not. > > When new members are added to the Cabal, I believe an announcement is > sent to the public mailing lists announcing this fact. If this hasn't > happened, I think it should. That doesn't address the "why", though. >> 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. > > There is only one instance I can think of where a person was added to > the Cabal for reasons other than direct contribution to the project. > After some discussion, it was generally agreed that it would be a jerk > move to rescind this person's membership. > > All other members of the Cabal have been specifically invited to be > members based on contributions to the project, and to the community. > Most members have been invited for specific code contributions, based > both in quantity and quality. Several members have been invited > because they have shown excellent stewardship of the community. > > No one has been awarded membership solely because "we like them" or > because we're all close pals. This goes against what I've been told (in private) from other members of the cabal that more than one person had: if we had some public documentation (on the wiki?) saying that X was added for "contributing a new theme engine" and that Y was added for "fixing a large number of bugs", there would be a great deal of increase in transparency and hopefully such contradictory statements wouldn't be made (as nobody within the community has any idea which statement is true: I can see more reasons to doubt the credibility of the "No one has been awarded membership solely because 'we like them'…" than I can the statement they were added as they were friends). On 6 Apr 2009, at 14:01, Rich Bowen wrote: > On Apr 5, 2009, at 17:04, Geoffrey Sneddon wrote: > >> The cabal, as it stands, is far too big proportionately to the >> community. > > Philosophically, I completely disagree with this statement. In an > ideal project the PMC (cabal) is the community. Makes votes difficult, > but gives the widest possible perspective on important decisions. Not > every vote requires the entire PMC to participate. OK, in an ideal world, yes. This isn't. :) From a community cohesion point of view (IMO), it's best that either everyone who wants to be in the cabal is, or that a very small percentage of people are. On 6 Apr 2009, at 14:29, Rich Bowen wrote: >> 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. Again: document it (especially that). On 6 Apr 2009, at 15:15, Rich Bowen wrote: > Either way, PMC members should take this as a STRONG > admonition. Don't commit code you don't understand, whatever your > motives. If someone asks you to commit code, be up front about the > fact that you don't comprehend the implications, and that's a valid > reason for refusing (or, rather deferring to someone else) a patch. We can get into problems with patches that deal heavily with things like HTTP and XML (and Unicode that virtually everything we do relies upon ultimately): what do we do with patches no one has the expertise to review? It's a problem I've run into from time to time. -- Geoffrey Sneddon <http://gsnedders.com/> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
