A couple of points I'd like to bring up. Overall, I agree with Geoffrey that this system needs some improvement. However, I've been down this path before and have little hope of a positive outcome.
On Apr 5, 2009, at 9:03 PM, ringmaster wrote: > > 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. Even if 3rd party review happened, I find it unlikely that a PMC member would get around to committing in a reasonable timeframe. Whether the code is reviewed or not, it needs a PMC member to commit. Unfortunately, I don't think the bottleneck is the actual code review but even opening the ticket. Maybe a dedicated committer (who commits patches after review by community and/or Cabal) would alleviate this. The PMC is going to have to be part of the solution, one way or another. > >> 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. I too would like to extend my apologies if you feel I've mistreated you. I do recall frequent teasing/joking, but I always assumed it was good-natured and you didn't mind. > > >> 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. > 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. True, and we should all keep that in mind. However, with 25 members in the Cabal you'd think it would be reasonable to get code reviewed within 48 hours. > 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. Let's hope such an RSS feed works effectively. Hopefully some other Cabal members will subscribe and do periodic reviews. There's also a report with this: http://trac.habariproject.org/habari/report/11 > > >> 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. I don't think any one member should be expected to do so. However, I do think a rotating group (2-5) of members should commit to reviewing code within a timely period. ~Arthus --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
