Geoffrey, I've rearranged your message a bit to make a few points in a different order.
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. 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. Finally, there is no prerequisite of code contributions for PMC membership. You can be tapped for membership for any number of reasons, all having in common a specific benefit to the community or filling some community need. So it could be for offering consistent support on IRC, helping set up and man a table at a convention, or maintaining the wiki. One of the things we were looking at coming from WordPress was that the people who provide non-code contributions should be recognized for their contributions, and the best way to do that is to grant them PMC membership. That said... > > Well, the simple solution would be to make me part of the cabal. :P > Perhaps that's part of the answer. I am as dismayed as you must be that there are members who participate solely in that they show up on IRC. In my mind it's not just about committing code or providing support, or any of the reasons that brought them to the attention of the PMC to begin with, but also about caring for the community. I have a specific example: When someone writes a message like what starts this thread, I shouldn't be the only one replying to it, and people shouldn't be annoyed that we're having "another one of those threads". Complaining about everything and offering no plan to improve it, adhering to the status quo with no rational explanation when others complain, plain ignoring people with valid complaints, refusing to arrive at consensus among community members about contentious issues -- In my opinion, these are not the behaviors of someone trying to foster a healthy community. As far as my personal criteria for PMC selection goes, if a person wants their primary contribution to the community to be code, then that code needs to account for its affect on the project as a whole. To form a poor example, it may be useful to commit changes that convert output of themes entirely to a DOM-based model, but that has wider-reaching implications than the code explicitly affected by that patch. All too often we get patches from people whose code quality is good, and suits the task to which it is explicitly set, but I wouldn't personally apply the patch because of something otherwise ineffable. Maybe I think it's just not a direction that makes sense. Maybe I think it's just not important to include. There has to be some subjectivity to it. I would allow other PMC members some subjectivity in their choice. Sadly, people have perceived this in the past as malice on my part, and for some who insisted on pressing the issue, it did. > I think the cabal simply has to be more attentive to contributions > from the community. If it does not, it will simply make itself > perceived as self-centred, only caring about what its members want, > and not caring about the community. There is no "merit" in such a rule > of governance, more sharing aims with members of the cabal. ... > 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. Applying the suggestions you've offered directly would be a great start. I'll look at each of these very briefly. > 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. > > 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. I agree. If you feel you've been mistreated (I had always read the comments in IRC as comraderie, but I can see how over time that would get old) I apologize for myself. I'll be better. Feel free to pm me on IRC if you have similar sentiments. > 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. > 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. > 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. Once again, a formal way to evaluate patches could specify exactly this. > 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. > 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. 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. What other action items do you see that would improve the situation as you perceive it? Owen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
