On Sun, Apr 5, 2009 at 5:04 PM, Geoffrey Sneddon <foolist...@googlemail.com> wrote: > How (in terms of criteria) are we going to review patches, though? I > (still) don't know how to get anything committed, because I don't know > what people want in a patch. IMHO, "I don't like it" isn't a valid > reason to refuse a patch. "I don't like it because x, y, and z" is.
I think this is always going to be a moving target, because each of us approaches issues from a different perspective, with different strengths and weaknesses, different biases and preferences. While I realize this may make it frustrating in the short term for some, I think the long-term end result is better. We're enforcing a different kind of checks-and-balances system. We're encouraging would-be participants to stretch beyond their limits. Maybe those limits are long-term code scalability or performance; maybe those limits are the ability to carefully articulate and advocate for the quality of the work they're submitting. > The further problem, which is the real reason I brought up the ticket > I did, was that timeliness is important: if you leave a patch to hang > around, nobody bothering to look at it, it will become outdated and no > longer apply. Why should I (or anyone else) update a patch that became > outdated because nobody bothered to look at it? What will make it the > case that the revised patch won't end up equally neglected? As others have pointed out, Real Life often gets in the way. It has for me of late, and I see few signs that that's going to change any time soon. I participate when and how I can. Many of the bugs I glance at have little enough detail to help me quickly understand them, let alone reproduce them. Any patches on said bugs often lack sufficient explanation of how the proposed fix actually works, and I simply don't have the time to educate myself on everything. I'm sure there are plenty of well-articulated bug reports in Trac that have exemplary patches attached to them. I've been unfortunate enough not to have dealt with many of them yet. If any of them are yours, advocate for them in IRC or this mailing list. And to folks watching from the sidelines: this sounds like an excellent opportunity to participate with Habari. Take a bug report with a patch, apply the patch, and weigh in on the Trac comments whether the patch worked. Can you reproduce the problem? Are new problems introduced? > 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. You can complain to -- and about -- the PMC, but remember that this is Open Source. If the community gets more engaged in testing and discussing bug reports, there is a much greater chance that patches will get integrated. I know I'm much more comfortable applying patches that have been tested by a handful of people: it reduces the chance that the patch fixes one problem while introducing others. The Cabal are just every day human beings. At least one of them is in the final stages of PhD-ness. Most of them have full time jobs. This is a hobby for all of us. I think we're all fairly well engaged, given the limitations on our time. > 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 think this merges with our recent discussion of behaviour on IRC. I don't think we -- the PMC -- should ever be disparaging or insulting to members of our community. We should all be adults. If you don't have anything nice to say ... > 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 disagree strongly. The point of the Cabal is to have different points of view. Our project -- and our product -- is greatly improved by having differing points of view. Although it's sometimes contentious, it ensures that we don't live within an echo chamber, constantly patting ourselves on the backs for another job well done. > 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. > 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. > 5. Don't get into revert wars. This is basically the same as #3. Yes, I think we all agree with this. > 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. I don't disagree with this at all. > 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? We do our best. Since not all members of the PMC are coders, not all members of the PMC are capable of reviewing patches. So while the PMC may appear to be a large body of people, remember that not all of them possess the same skills. And not all of them are as engaged in the project at any specific time. Again, the community can help. The community can review patches and comment upon them. The community can help streamline the review process, thereby streamlining the commit process. If I see a patch that has half a dozen positive comments from names in the community that I recognize as having some programming acumen, I'm much more likely to fast-track the patch. Cheers, Scott --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to habari-dev@googlegroups.com To unsubscribe from this group, send email to habari-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
