> > Actually, that section doesn't deal with the question that Rohit > raised really. He's asking about the result of challenging a veto, > which is only addressed in the following: > > "The validity of a veto, if challenged, can be confirmed by anyone who > has a binding vote. This does not necessarily signify agreement with > the veto - merely that the veto is valid." > > What isn't addressed is the question of how long a "veto challenge" > needs to remain "unconfirmed" (i.e.: nobody confirms it's validity) > before it's considered to be a "valid challenge" nullifying the veto, > or (alternatively) if there is an explicit action that would cause the > "veto challenge" to be confirmed.
Ack - I misunderstood the intention. > > Like I said, edge case within the edge case. Personally, I'm not sure > that I care to try to plug this very small procedural hole... but it > does exist. Perhaps the problem is in the concept of a "challenge" in > it's entirety? > > Anyone else have an opinion? > I likewise am not interested in plugging this hole; but here's my opinion for what it is worth. If a binding veto is tossed; there should be some deep thought going on about what is happening. Vetos are rare and should be the exception rather than the rule, and we shouldn't be in a hurry to dismiss such things. Additionally this project is a community of people who are working towards a common goal, in general we should not be explicitly engineering ways to bypass the members of community with concerns in an effort to quickly add functionality to the codebase. If we can't get along and build consensus to get things done then that points to other, much more troubling problems. Community over code being the mantra and all.
