You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Cambridge K1 we were discussing how we want to do consensus-based decision making. We want to facilitate online users (who may be nervous) to take part in the process. So the facilitator needs to know:
who has consented
who is blocking
who hasn't participated
In order for this to be generalised and for "consent" and "block" not to have magical hard-coded meanings, I propose that we add a per-organisation priority list of "special" states. For example, in K1 we might set this list to the following, in this order:
consent
danger (I wish we had "block")
Then, if a user has any "consent" feedback on the proposal, they are considered to be in the "consent" state (just for this proposal).
If they have no "consent" feedback, it looks for the next type, "danger" in our case, and if they have any of those, they are considered to be in the "danger" state.
If they have no "danger" feedback either, then it's run out of feedbacks to search, so they are in the "undecided" state.
If this proposal doesn't get any objections and nobody implements it first, I may do it myself for K1.
The text was updated successfully, but these errors were encountered:
In Cambridge K1 we were discussing how we want to do consensus-based decision making. We want to facilitate online users (who may be nervous) to take part in the process. So the facilitator needs to know:
In order for this to be generalised and for "consent" and "block" not to have magical hard-coded meanings, I propose that we add a per-organisation priority list of "special" states. For example, in K1 we might set this list to the following, in this order:
Then, if a user has any "consent" feedback on the proposal, they are considered to be in the "consent" state (just for this proposal).
If they have no "consent" feedback, it looks for the next type, "danger" in our case, and if they have any of those, they are considered to be in the "danger" state.
If they have no "danger" feedback either, then it's run out of feedbacks to search, so they are in the "undecided" state.
If this proposal doesn't get any objections and nobody implements it first, I may do it myself for K1.
The text was updated successfully, but these errors were encountered: