Stage 3: Making a Decision

Date: December 17th, 2020
Facilitator: Katie
Participants: Bruno, Katie, Vasileios, Nick


  • check in
    • Prolonged but nice!
  • Overview of Nathan Call
    • Important to make the governance process clear in Karrot
    • Think about what in integrated into the code
    • Reflection on the conflict resolution
  • Talk about next steps
    • Finish sketching later
    • Now we move on to Stage 3 - Decide
    • Use heat map and dote to decide what needs more discussion
    • Do we need to check if there is anything that is still missing?
  • Stage 3: Decide
    • Bruno is interested in working with most elemets, maybe we can chose one decision making model, and skip library for now.
    • Nick likes the vision text box, he had also selected the library but is up for having it as an add-on later. A light weight editing and approval would be useful
    • Vasileios thinks its import to ask who will test the prototype, if two groups will test it would be nice to integrate intergroup learning, I think all groups should test it. In agreement
    • Katie try one decision making model or both and do some A/B testing. Categories are interesting and working with the vision text boxes.
    • TRY: Threshold of approval based on the trust Karrot systems. Reactions and temperature check. A multi-stage process, 1. Temperature Check (If all positive or neutral it gets approved) 2. If negative reactions occur then it need approval from 3ish highly trusted members.
  • Move on to prototyping, choose what to prototype
    • things not represented in the sketch right now:
      • democratic flow around agreement proposals
      • Build a facade and try to test with multiple groups, Bruno and Katie could test in their groups and then do others over call
      • Work in tandem, coders start on one page while others work with IA/WIREFRAMES/Mockups
  • Next meeting
    • 30/12
  • Facilitator next meeting:
    • Bruno
  • check out

A post was merged into an existing topic: Governance Meeting Notes

Features have been designed like this so far

The steps:

  • create a new agreement (editors can do that)
  • a draft is created
  • any other group editor can edit the same proposal
  • anybody can see the proposal and they can participate in the related chat
  • nick way: anybody can choose +1,0, -1. The result is score voting → proposal to approve a proposal: x (3 maybe) times more positive votes than negative
  • if you place a negative vote you should write a msg, negative reactions/vote should be motivated/explained
  • If the score is in favor of the proposal then it becomes approved.
  • Brn way: temperature check to get the mood of the room (they do not decide but only editors can accept or reject)–> what happens where people approve sth that has a lot of dislikes? temperature check vs editor-powered
  • should there be a lower threshold for how many members should vote in order for an agreement to be approved?

Some more discussions later led us to this concept to go forward with:

  • only editors can submit proposals (katie doesnt morally agree, me neither, but it wont be a problem–> its easy to get karrots thus its ok)
  • timescale: minimum 1 week + suggestions + custom → pick a specific date
  • any editor can change the proposal.
    • What happens when there’s a change? Votes reset? Suggestion: people get a notification of the change and are asked to review their vote
  • no temperature check
  • everybody can vote
  • score voting with negative weighting (2, 1, 0, -1, -2)
  • anonymous voting
  • negative votes require a reason and they’re kept anonymous (“explain why you don’t like it”)
  • At least 5% of members should vote for an agreement to get approved
  • Proposal with a score >= 0 will be approved

There is some uncertainty about which info to take when first creating the proposal, before the collaborative part starts. Could be duration + title, and/or perhaps a message/context/description of what the proposal is roughly about, or how to participate, or some more human message… tbc.