Stage 3: Making a Decision

[Katie_Berns]

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

Agenda

• 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

[bruno]

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?

[nicksellen]

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.