Costin Manolache wrote:

working on that. thanks.

how the voting rules are applied is a per-community thing, supposedly spelt out in the group's guidelines. the basic things that apply across all projects are the concept of majority rule for non-code issues, the significance and application of vetos, and (((plus_1 >= 3) || lazy_consensus) && (! veto)) for code decisions and other things decided by the community to require that form of voting.

if the 'revolution rules' are those described by the proposal ted wrote (?) which i cited earlier, they also i think are a per-community thing. a fair approach to providing support for development of alternatives when a veto has been expressed, but more formalised in the project guidelines at jakarta than anywhere else afaik. elsewhere the 'revolutionary' development happens offline. the jakarta model may not work in other communities; i could see some regarding its application as noisy and a distraction from the 'main work' of the project, but it's an interesting concept that at least should be documented, particularly for the incubator. so i'll write my take on it and ask you (and others) to check it.