On 4 Apr 2009, at 21:44, Owen Winkler wrote:
> It seems reasonable that there are going to be patches about which any > single developer is ambivalent. It also seems reasonable that there > are > going to be patches that would take more time to test than a committer > is willing or available to give. I'm not sure how that jives with a > desire to have objective or even subjective concerns voiced with every > ticket. I think giving useful, informative responses about why code hasn't being committed is vital to get people to submit code: it's hard to write code when you don't know what people want of it. As for time taken to test, I'd argue in a lot of ways the simple way around that is to just require all patches to include a full test- suite, which in turn would probably massively reduce the number of bugs getting introduced into Habari (actually, that probably wouldn't be the case, seeming virtually all code comes from the cabal and thus such a requirement on patches would not make any difference). > I don't believe that committers should review and commit code solely > based on whether it works, excluding whether its goal is worthwhile. > Some patches that are useful at face value merit much more discovery > and > contemplation. Unfortunately, patches are often supplied with a > single > intent, not considering the effect of the patch on the rest of the > code, > just on the achievement of that specific goal. When told to consider > their patch in terms of the whole project, the patch providers > frequently take personal insult to the comment, or insist that just > because the patch works to achieve that single goal, it's enough to > pass > review. These things make it hard to perpetually review all patches. 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. But if we don't review all patches, what is going to happen to them? They are just going to stay in Trac forever and ever, on tickets which are open purely because nobody does anything to them. 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? > Would a +1/-1 and short comment from me on both intent and > implementation on every patch be useful? It depends how short. I think there really needs to be some worthwhile comment saying why something was rejected if it was, but I don't think there needs to be much comment if it is accepted (apart from just committing it!). > Would it be acceptable to comment that I don't have time to do a > complete code review? It depends on the exact case: I'd say if the design of the patch was completely and utterly wrong, pointing that out and saying what should be done instead would be enough; if it is a patch with many small issues you will probably miss some anyway, so you could probably just say, "I haven't looked for long, but I've noticed x, y, and z so far.". > I'm not entirely sure everyone would enjoy me (or me alone) > reviewing all the code. I don't think having a single person reviewing patches in a perfect solution, but it is better than the status-quo of patches just getting stuck there forever. > I don't have a simple answer to the problem, and perhaps it's gotten > like this because the solution isn't simply arrived at. 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. > Concerning this situation, what's worse to me is that everyone > complains, but nobody does anything. Perhaps people expect the > current > situation to improve simply by pointing out that something is wrong. 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. > You put effort into building the community, and as a result the > community improves. Where you want to see change, be the instrument > of > change. Present a solution, get some agreement, take charge of it, > see > it through. > > If that's the intent of starting this thread, then that's great. I > feel > that only by offering potential solutions, rather than solely pointing > out the problems, will the situation improve. I think the majority of potential solutions are quite obvious: 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. 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. 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. 5. Don't get into revert wars. This is basically the same as #3. 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. 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? The main issue is such that lay people, like me, can do nothing but whine: changes have to come from the cabal. Only the first two items on that list can actually be done by anyone outwith the cabal, the rest are specific issues that the cabal has to address itself. 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. The problem is, I think, a lot of people are trying to over-complicate solutions to the problems I've mentioned: the best solutions are obvious and (mostly) are just common sense. > Geoffrey, I think you're a brilliant guy. I think you have a grasp of > certain technologies that we'd be hard pressed to find in anyone else. > I value your contribution to the project, even if I personally think > much of the code you provide is premature for our use (I'd like to see > things working more than I'd like to see them conforming to standards, > which I think is what puts us at odds most of the time). I agree that > your contributions have been much more than some current members of > the > cabal. I'm not sure what conclusion I should draw from all of that, > except that if you have a complaint then you must also have some > suggested path to resolution. Well, the simple solution would be to make me part of the cabal. :P However, I don't believe that to be the right solution: 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. The fact that some people appear to be in the cabal because they submitted a couple of patches doesn't help, especially seeming it isn't rewarding people based on merit, and also isn't consistently applied (as if it was the cabal would be much larger). The cabal, as it stands, is far too big proportionately to the community. -- 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 -~----------~----~----~----~------~----~------~--~---
