Resolve voting "loophole"

[nyalldawson]

There's a loophole/ambiguity in the current voting process:

1. Developer A opens a QEP
2. Developer B looks over, and approves in its original state
3. Developer C triggers discussion, as a result the QEP text is amended

This leaves the original approval vote from developer B in an ambiguous state -- does there previous approval still apply even though the text has changed?

We could resolve this by:

1. Requiring a discussion period prior to any votes being cast - eg two weeks for discussion before any votes are permitted.

• We'd also then need a minimum timeout for voting to avoid two initial approval votes from instantly triggering acceptance without time for any negative votes to be cast. This could be handled by either:
  • allowing negative votes during the discussion period
  • requiring a minimum time for voting to be open (the downside of this is that it would further slow the whole QEP process)

2. Invalidate votes already cast whenever changes are made to the text, and require those voters to recast their votes
3. Something else??

[troopa81]

how do we plan to vote exactly ? 👍 and 👎 on the PR, +1 and -1 in the comments, approve/need for modification in PR

Regarding the proposition being modified after an already casted vote, I would propose to just make a last call message to remind everyone that the proposition is going to be accepted (in a period to be defined) if nobody complains anymore.