CIP-0136? | Governance metadata - Constitutional Committee vote rationale

[Ryun1]

This proposal aims to provide a specification for off-chain metadata vocabulary that can be used to give context to Constitutional Committee votes.

📄 Rendered Document

[ptrdsh]

cool stuff. thx for starting this.
Is the difference between CC vote rationales and DRep/SPO vote rationales crucial? aka: couldnt we define one "voting rationale metadata standard" instead of 3?

[Ryun1]

@ptrdsh

Is the difference between CC vote rationales and DRep/SPO vote rationales crucial? aka: couldnt we define one "voting rationale metadata standard" instead of 3?

I feel that CC votes are significantly different to those of SPOs and DReps
With CC voting on the constitutionality of actions whereas SPOs and DReps voting to represent their delegators

With that said, a unified standard could probably be done
but would require a lot more iterations and a lot more input to mature the standard
So choosing the path of least resistance I think it makes sense to start with this standard,
and push that idea to the future

[ptrdsh]

Heya! nice progress! :)

2 quick and 1 more substantial question:
Did you not add a title on purpose for the rationale?
And.. did you purposely name similar fields different from cip108?

Thinking of future GUIs that show all rationales (proposal, cc vote, drep vote, spo vote) and general coherency, the shortest text in the current design is "summary", while we have a "title" in CIP108. May be helpful to add one.
Also, I think "summary" is similar in meaning to "abstract" and Id stick with one wording across CIPs, unless they are purposely named differently for differentiation. Same goes for rationaleStatement (=rationale).

However... Again, id like to raise the question as to why we couldnt just add the CC (and Drep) specific fields in the CIP108 standard.. seems unintuitive to have those standards be spread out, albeit extremely similar in content, with maybe 1-2 fields extra.

[Ryun1]

@ptrdsh

Thinking of future GUIs that show all rationales (proposal, cc vote, drep vote, spo vote) and general coherency, the shortest text in the current design is "summary", while we have a "title" in CIP108. May be helpful to add one.

I'm not against adding an even shorter field
For me a title makes more sense for Governance Actions, where you are trying to catch a voter's attention
For CC Vote rationales, im not sure that is as needed

Also, I think "summary" is similar in meaning to "abstract" and Id stick with one wording across CIPs, unless they are purposely named differently for differentiation. Same goes for rationaleStatement (=rationale).

We can reuse elements if people would prefer it

However... Again, id like to raise the question as to why we couldnt just add the CC (and Drep) specific fields in the CIP108 standard.. seems unintuitive to have those standards be spread out, albeit extremely similar in content, with maybe 1-2 fields extra.

We certainly could, but there are two reasons why Id prefer to keep them separate:

• They have different scopes, so forcing tools which only care about governance action data to also support CC Vote rationales is a bit wonky
• I find it simpler and easier to just add to vocabulary for each CIP
  • For me it is easier to explain that CIP108 is for governance actions and CIPXXX is for CC vote rationale
  • And I don't see a massive benefit to reuse

[rphair]

@Ryun1 you're good to go with 0136 & I know you won't forget to rename the containing directory & update the document link in the OP 🎉

[gitmachtl]

I would add that an additional authors field can be used too, but not a must. That should actually be also in CIP-119 tbh. So even if the offchain metadata is viewed out of context, there are still the names and signatures from the authors present in the file.

[phillewis]

I don't think we need to try and shoehorn everything into a common standard. CIP-108 is asking a question (e.g. should we make a parameter change, should we withdraw from the treasury), whereas this CIP is responding (e.g. that isn't constitutional because), so the information needs to be different.

The only thing that I am thinking about is the internalVote object. Do we want to give the option of providing more information than just the number of each vote type? Instead of an integer, it could be an array of identifiers. A count of each array would provide the same value, but could be extended with some tools to show who voted for each. Ideally we should have a seperate CIP for different identifier types (e.g. strings for a simple name, or DIDs for a more detailed identifier), as these could be used across different standards (such as DRep metadata).

[phillewis]

Also, what realistically is the difference between a Summary and a Conclusion? They feel the same to me.

[Willburn]

Also, what realistically is the difference between a Summary and a Conclusion? They feel the same to me.

Writing two rationales in this format it does seem a bit redundant from my experience so far as when I reread it there is some information repeated. But the idea was to have a shorter summary (200 char limits currently and should perhaps be doubled) that was quickly viewable by anyone as the main info on the whole rationale vs a longer conclusion that could encompass all aspects of any conclusion.

[phillewis]

Also just to clarify, is the expectation that there will be one of these responses for each CC member, or one responses from the entire CC?

[Willburn]

Also just to clarify, is the expectation that there will be one of these responses for each CC member, or one responses from the entire CC?
I would say each CC member (so say a single rationale for one council that holds a CC member spot) based on what was established in Longmonth of Independence for each CC member in terms of rationale and perspectives used to get to a conclusion.

[phillewis]

Also just to clarify, is the expectation that there will be one of these responses for each CC member, or one responses from the entire CC?

I would say each CC member (so say a single rationale for one council that holds a CC member spot) based on what was established in Longmonth of Independence for each CC member in terms of rationale and perspectives used to get to a conclusion.

Not sure what you are referring to with regards to Longmont, but it sounds like you are essentially suggesting 7 independent committees rather than 1 ICC.

[Willburn]

Also just to clarify, is the expectation that there will be one of these responses for each CC member, or one responses from the entire CC?

I would say each CC member (so say a single rationale for one council that holds a CC member spot) based on what was established in Longmonth of Independence for each CC member in terms of rationale and perspectives used to get to a conclusion.

Not sure what you are referring to with regards to Longmont, but it sounds like you are essentially suggesting 7 independent committees rather than 1 ICC.

7 independent council members of the ICC who vote as the ICC body. In Longmont it was discussed if each of the councils needed to have one unified way of interpreting and if this is even possible in a decentralized governance system. The conclusion there among all the councils that attended was that there is independance of thought in each of the councils and we publish rationale for each of the votes. The blockchain aggregates our votes as a collective ICC.

[phillewis]

Also just to clarify, is the expectation that there will be one of these responses for each CC member, or one responses from the entire CC?

I would say each CC member (so say a single rationale for one council that holds a CC member spot) based on what was established in Longmonth of Independence for each CC member in terms of rationale and perspectives used to get to a conclusion.

Not sure what you are referring to with regards to Longmont, but it sounds like you are essentially suggesting 7 independent committees rather than 1 ICC.

7 independent council members of the ICC who vote as the ICC body. In Longmont it was discussed if each of the councils needed to have one unified way of interpreting and if this is even possible in a decentralized governance system. The conclusion there among all the councils that attended was that there is independance of thought in each of the councils and we publish rationale for each of the votes. The blockchain aggregates our votes as a collective ICC.

Yeah, I think the idea of a committee is a bit of a misnomer. If we are reviewing and responding to GAs as independent entities then we aren't "a collective ICC".

We should probably propose a name change to something that better represents the true function.

[Willburn]

One could argue we are a decentralized collective as A) vote aggregate of all of us is used for any tresholds and B) we share information with each other (so far the practice atleast) so even if we have independant votes for each cc I will certainly be promoting a culture of collaboration in the council I am part of as that will cause us ot have better rationales and more effective and efficient governance overall. I look forward to seeing how this evolves.

In any case I believe the CIP structure should be neutral to how the structure of the CC evolves (councils, collaborative or not etc.), and provide a standardized data format for rationale(s) to be published.

[phillewis]

I don't think we need to try and shoehorn everything into a common standard. CIP-108 is asking a question (e.g. should we make a parameter change, should we withdraw from the treasury), whereas this CIP is responding (e.g. that isn't constitutional because), so the information needs to be different.

The only thing that I am thinking about is the internalVote object. Do we want to give the option of providing more information than just the number of each vote type? Instead of an integer, it could be an array of identifiers. A count of each array would provide the same value, but could be extended with some tools to show who voted for each. Ideally we should have a seperate CIP for different identifier types (e.g. strings for a simple name, or DIDs for a more detailed identifier), as these could be used across different standards (such as DRep metadata).

Just following up on this and whether there is any appetite to explore identifiers in the internalVote? Don't want to hold up this progressing, so if others @Ryun1 @Willburn @ptrdsh @thenic95 don't think it is necessary we could try to wrap this one up.

[Ryun1]

@phillewis

Just following up on this and whether there is any appetite to explore identifiers in the internalVote? Don't want to hold up this progressing, so if others @Ryun1 @Willburn @ptrdsh @thenic95 don't think it is necessary we could try to wrap this one up.

I dont know if it is really needed, unsure of the appetite for this
And I dont know how this could / should be done, im wary of making this standard too complex to implement
For me, id push something like this to a future version, if others agree?

[phillewis]

@phillewis

Just following up on this and whether there is any appetite to explore identifiers in the internalVote? Don't want to hold up this progressing, so if others @Ryun1 @Willburn @ptrdsh @thenic95 don't think it is necessary we could try to wrap this one up.

I dont know if it is really needed, unsure of the appetite for this

And I dont know how this could / should be done, im wary of making this standard too complex to implement

For me, id push something like this to a future version, if others agree?

Yeah sounds good. Don't want to hold it up unnecessarily 👍

[ptrdsh]

@Ryun1
I have a small request for change/addition before this gets ratified.

Id like to add "doNoVote" to the individual internalVote result options to document individual CC members who preferred that the CC would not vote at all (aka.. votes to not participate) on a given GA.

    "internalVote": {
      "constitutional": 1,
      "unconstitutional": 0,
      "abstain": 0,
      "doNotVote": 0,
      "didNotVote": 0
      }

Name of this option is up for discussion of course. "doNotVote" alongside "didNotVote" may be confusing.
Alternative idea:

    "internalVote": {
      "constitutional": 1,
      "unconstitutional": 0,
      "abstain": 0,
      "noVote": 0,
      "absent": 0
      }

[gitmachtl]

why is there binary 0/1 used and not false/true? json can handle boolean values.

[ptrdsh]

why is there binary 0/1 used and not false/true? json can handle boolean values.

its just an unfortunate example.
those are integers, indicating how many internal yes/no votes were cast by the individual CC member's humans.

check how its used in this vote rationale: https://ipfs.io/ipfs/QmZLsHGah3NMvWeS8kr1pUeCZR8bxTkYL3fgjs2VqNacnV

[gitmachtl]

ah, ok 😄

[thenic95]

Thank you, @ptrdsh! I support this addition. For context, we introduced this fourth voting option [Yes/No/Abstain/Not Vote] for the individual members of the Governance Advisory Team of the Cardano Foundation to ensure all possible scenarios are genuinely reflected when assessing the constitutionality of governance actions.

I think the following naming convention makes a lot of sense:

    "internalVote": {
      "constitutional": 1,
      "unconstitutional": 0,
      "abstain": 0,
      "noVote": 0,
      "absent": 0
      }

[Willburn]

Makes sense. Keep in mind that a majority no vote would mean the rationale is not going to be onchain since its presumably not voted on. Still valuable for community to know dissenting voice on no vote.

[ptrdsh]

Yep Agreed. Also thought of that scenario but transparent dissenting seems valuable enough to include it. Shines a light on background discussions and if someone does vote not to vote, the quorum would be incomplete without it.

[phillewis]

Given the controversy over CC members not voting, adding this to a CIP may be perceived as condoning not voting.

Does splitting didNotVote into two so one can signal motive actually benefit anyone consuming the information?

[ptrdsh]

Whether the option is desired or controversial at this point in time is not relevant imo, the option of not voting is an actual option CC members can consider, so why not reflect it.

What's worth considering here is that there is a key difference to Drep rationales, as CC members are councils consisting of groups of people with individual votes. Dreps typically dont operate and are not intended to be run by groups.
NoVote is thus also really only an option that the individuals of CC members "sensibly" could make, which is the purpose of this CIP.

The concern that this option, by definition, can never have the majority votes as it would contradict itself then, is valid, but as stated above..

• making dissenting votes transparent is useful to the public
• since the option exists to the individual (irrespective of that being acceptable or not), that persons consideration would either be misrepresented in a [didNotVote] or [abstain] vote, both of which are too wrong to use, or not counted at all, which reduces the total quorum size of the CC to a number of votes which is not in line with that CCs public principles document/.. .

[phillewis]

Fair enough. I don't have a strong objection. Just thought it might be something worth considering.

[Ryun1]

@ptrdsh @thenic95

This suggestion is reasonable, id rather just add one new field than removing didNotVote, as people have already been using this and im wary of breaking future tools with existing metadata.

I think againstVote could work here, as long as its described well in the CIP, downstream tools can rename as they see fit (naming is hard).

"internalVote": {
      "constitutional": 1,
      "unconstitutional": 0,
      "abstain": 0,
      "didNotVote": 0,
      "againstVote": 0
}