I suppose I am meant to understand that you disagree with the policy addition. Very good.
> In the past I know there have been things that got voted down because > they weren't consistent with the "spirit of Habari" or "why Habari was > started". Largely that equates to not being in line with the opinions > you, Scott, Chris J. Davis, Rich, etc. hold, being the "core" group. I > object to that logic because it seems to place your values (and > therefore the ones that originally defined the "Habari spirit") above > those of other participating members, potentially even in a vast > majority, throwing off the "one voice, one vote" equilibrium. I recall having discussions about features and how they are influenced by that vision, perhaps resulting in votes. I'm not aware of any commit that was made in opposition of a majority of voting PMC members. Please indicate where this has occurred so it can be rectified. What I'm hearing now though, is a sentiment that it should be reasonable to apply one's own vision to Habari without discussion by means of reverting others' commits. I don't agree with that. Sure, we don't need to have a post over every commit, but it seems reasonable and valuable to discus cases on which we don't all agree, of which a revert is a clear and obvious example. There is no rush to fix these things that are reverted - they're only in HEAD, and users there should expect this kind of "breakage". > Extending that logic to essentially revoking Cabal membership would seem > much more like a tight-knit aristocracy than the oligarchy it's supposed > to be. It seems to me that you've taken my original message as a personal attack, and have responded in kind. Mostly, I was referring to the admin color changes that occasionally bounce their way into and out of the core code. I believe that frequent abuses of commit privileges like these that insight perpetual reverts should be reviewed. > Please open separate threads to discuss the merits of specific past > reverts if it is not directly relevant to this policy topic. Thanks. > > > I would like to bring up the Apache license notice revert (r3185) that > originated this "discussion" here, since it seems directly relevant. Then one might also bring up these instances: r2832 - Reverting r2831, it's absolutely horrid. I'll fix it in a moment. Then why not fix it and then commit the fix? Not only did the fix take an additional measly 5 minutes, but it could have avoided the insult in the commit log. r2889 - Reverting the error_reporting changes in r2886 while we further discuss if and how we really want to handle settings like this. See habari-dev for a discussion if you have an opinion one way or another. Oddly, precedent for the suggestion I made in this thread. r3070 - Reverting r3068 and restoring the spam count to the dashboard. An instance of not agreeing with how a feature should work or whether it should exist that ultimately results in a perplexing new site-wide option -- but no -dev discussion, despite the volley of commits. r2846 - Re-applying button styles. In this instance Heilemann has been out-voted by a number of people (PMC and non-PMC) on IRC. This is the one you would expect to see in this list, regarding the button styling. No discussion was logged on this topic until later when Khaled posted to -dev, and that was the first time many people even knew it was happening. Unless we've changed something, IRC votes are not binding, and for this second volley of commits and the general sentiment that it aroused, it arguably should have been called to a binding vote. In terms of where r3185 went wrong, moeffju saw a need to make Habari better in terms of applying Apache licensing. I think that complying with SHOULD clauses is a good thing, not an optional thing that should be dismissed at whim. I think this case was a good commit, although I agree that the size increase is undesirable. What I'm suggesting is that posting this concern to the dev list before reverting could avoid tension and result in a better overall outcome. As an example alternative, all of the Habari files should have PHPDoc headers as part of our code standards compliance. Adding a simpler licensing notice in the PHP Doc would add minimal additional size, and fulfill the requirement. If there was discussion on the topic, I can't tell solely from the commit log. No conversation on IRC was referenced in the commit log, and no -dev thread exists indicating the discussion. For all I know, moeffju said, "Yeah, you're right, get rid of it." That would appease me, but I'd like to see that happen; I'd like to know that people are discussing these things and arriving at compromises, not just reverting commits on "wager" that everyone else will agree. All that said, none of these instances are directly relevant to the policy suggestion I offered, which is future-facing. I would simply like to know when a commit is reverting the work of others who have also earned the privilege of committing directly to Habari's core, and be able to discuss the rationale for either change. Better yet, if some way to improve the code in compromise can be reached that avoids the revert altogether, that would be the superior solution. Fine if you don't want to call it a policy. Call it a courtesy -- A personal favor to me, or out of respect to the gifter of the code you revert. For so rare an occurrence, I think it would not be too much trouble. > If you would > consider having a feature or piece of code you contributed being removed > or changed a personal slight, you probably shouldn't be contributing it > to an open source project in the first place; once it leaves your hands > it's not yours anymore, it's the community's. I think we should handle other people's submissions with respect. Even if a revert is technically just another commit, it has additional social implications that should be considered. Reverts don't move the code forward, both in a literal sense, and in the sense that they don't help to achieve the objective of the original commit at all. In addition, the negative social aspects of reverts leave them as something to be avoided entirely if possible, and well-documented and discussed if not possible. 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 -~----------~----~----~----~------~----~------~--~---
