Quoting David Eisenstein <deisenst@xxxxxxx>: > This sounds pretty good, Eric, though I am only finding the use of the > word "consensus" in our online docs a few places, and those mainly in the > wiki (nodes "UpdatedOverview" and "QaTesting"). Are there other places I > am not seeing it that you are concerned about? Perhaps not. But it is used by Jesse on the mailing list a lot. ;) > I guess it all depends upon what kinds of activities you feel we need to > use a "consent" model for. The various activities of our Project seem to > require different levels of control. Mostly this is for QA and package release, and for deciding whether to drop or add things (like when we dropped RHL 7.2 and RHL 8, or when we talked about adding RHL 7.1, etc). Things of that nature. It also came up with my proposed re-write of the overview. I was told to post it and try to get a consensus on it, but all I got was silence so it has never been updated. > Publishing things to the wiki, for I'm not worried about wiki things, mailing list postings, etc. I'm talking web site changes, policy changes, procedural changes, etc. > Basically, it seems like consent, the way you define it, is the way we're > doing things now anyway. Well, the overview rewrite has been dormant for months because we've not got a consensus on it, due to apathy. Right now, I can't update it on the web site because we don't have a concensus or veto. My changes would make this easier, as since no one is vetoing it or arguing against it, it could simply be put in place as-is. And one very bad problem (an overview of the project that in no way reflects reality) would be solved. > It is kinda the concept of "Do it now, and > apologize later," which gets results; a philosophy of "Don't do it until > you get permission," seems to cause things to languish, because nobody > remembers to give permission. This is exactly the situation we have now, and I'm proposing we change. My overview update is languishing because no one has given permission to update it, nor has anyone objected to updating it. In the current system, that means it is in limbo. In my proposed system, it could be moved into production since no one has said anything against it in the 6+ months it has been available for review. > HOWEVER -- in QA testing in the bugzilla, we must keep a permission (or > formal consent) model -- things mustn't be verified to updates-testing or > published to updates until there is (at least one, probably better two) > positive, PGP signed, votes from people doing QA work. QA cannot happen > without this kind of permission given. My system doesn't change this. We still have the rule that you must have X pgp-signed votes to publish. What it changes is that right now someone can veto it without a reason, where as in my version they would have to have a valid argument/reason to veto a publish. > It seems that, generally, if there is a negative comment given in > bugzilla, items do not move forward. In my system, the negative comment would have to be a valid argument against it, rather than just a negative comment. Other than that, it stays the same. > Instead of veto, maybe the idea of > "valid blocking issue," (or "Marc or Dominic veto" which is the same thing > 99% of the time ;-) ) or something like that, could be used. Right now we have the "Marc or Dominic veto" setup (except it also includes Jesse, etc). That is what I want to get away from, and into a "Someone has a valid reason not to publish" statement instead. And if no one has a valid reason not to publish, and it otherwise meets the publish criteria, then it is published. > By the way, Eric, I like what you have done with "How to use Bugzilla" on > the fedoralegacy.org website <http://fedoralegacy.org/docs/bugzilla.php>. > It looks pretty up-to-date in sync with our new bugzilla at Red Hat. :-) Thanks! > -David -- Eric Rostetter -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
