Parameter Changes meeting with Harris Warren
Tuesday, 10th May 2022. 1500 UTC
For comment and discussion please refer to the GitHub Issue below
GitHub Issue - F7 - Parameter Changes in Catalyst - meeting with Harris
Transcribed, summarised and timestamped by Vanessa Cardui - QADAO
GitBook presentation and YouTube transfer by Stephen Whitenstall - QADAO
Present (in order of first speaking)
Stephen Whitenstall; Allison Fromm; Harris Warren (IOG); Phil Khoo; Tevo Saks; Vanessa Cardui; Matthias Sieber.
Speaker percentages
Harris (31%), Stephen (24%), Phil (21%), Allison (10%), Tevo (5%), Vanessa (5%), Matthias (2%)
Meeting summary
Welcome and intro
Stephen 0:00 A special meeting of Community Governance Oversight (CGO) with Harris Warren of IOG, to discuss parameters and parameter changes.
Framing this meeting
Allison 0:42 CGO emerged originally from the Parameters Pilot that Harris presented to Circle v2. The Pilot has been on hold; but CGO have realised that many parameter changes are still happening, in quite a scattered way. We plan to track them and report to the Catalyst community, to bring some documentation and transparency. This raises bigger questions:
What is, and is not, a Catalyst parameter?”
What's the decision making process for changing a parameter?
What's the communication method, both for getting feedback before the change, and for communicating the change after it happens?
CGO will start this reporting process in our regular Town Hall slides Before that, we want to connect with IOG, and open a dialogue around Catalyst parameters.
CGO background and goals – is it a decision-making body?
Phil 3:54 We are an Oversight group; we’re not elected or appointed to make decisions. We are funded, meaning the work we’re doing is in line with Catalyst roles according to the Challenge we were funded in. But we are lookers. rather than tellers or doers.
Stephen 4:51 We work within the scope of the proposal that Harris, Dor and I drafted in November 2021. That had several deliverables on oversight of specific governance areas, i.e. challenge setting; the parameters pilot; and Circle problem-sensing. We framed the F7 work as surveys, questionnaires, retrospectives, and a final report.
Hopefully, we get funded for F8 [documenter’s note: this happened] to continue providing oversight of governance processes, using broadly the same pattern: we examine what's going on in the community via questionnaires, workshops, etc, in order to feed into another report. But we're not intervening in any decisions.
Initially, IOG announced in a Town Hall that the Parameters Pilot was on hold, so we thought we would have no work to do on parameters; but then we realised parameters are more than just that pilot – they are still being changed. The draft process that Harris developed for parameter changes was a system of consultation with the community – so we thought, "shouldn't we be applying the oversight we were going to give to that, to all parameter changes in Catalyst?"
Allison 8:04 To make it explicit for the benefit of the recording – we are talking about Catalyst parameters only, not the broader Cardano Blockchain parameters.
How Catalyst parameters are changed
Harris 8:23 There are perhaps 20 Catalyst parameters that get defined with every fund. Our objective is to enable others to make decisions on them; so we need to establish validity of decision making within some established body outside of IOG. It could be Circle, together with an IOG Technical Council; or some other body. 9:35 Parameters are often generated out of research into how we protect the system and make sure it's not gamed or attacked; they can also be generated out of experimentation. Some of it is heavily based on game theory; so we need a Technical Council to provide that research insight.
Stephen 10:29 Once a decision is made in IOG to make a parameter change, is there a standard process by which you consult the community?
Harris 10:52 Right now, we're not modifying much, apart from dReps, and dRep rewards. Some of that has been shared, but we could give more detail, and share more with the community.
The need to involve the community
Phil 11:32 From IO’s viewpoint, there are around 20 parameters. But we've identified other parameters that IO are changing, that you haven't identified as parameters; they need consultation too. For example, we consider changing the Fund budget from a dollar amount to an ADA amount to be a parameter change. This was IOG-led; the community only found out once it's already happening. As active people in the community, we are starting to feel that these things should be announced before they are changed. It will stretch the timeframe longer, and complications might emerge from the discussion; but we're starting to feel that there's pressure outside coming in that will mean we need those channels of discussion to start being open.
Harris 13:02 It was a big decision to make that denomination change, so that was not taken lightly; and I think we do need to have more involvement with the community.
We could start with parameters that are less contentious. Things like dates and amounts are heavy items; we’d need a lot of insight and structure and process to be able to have that decided by the community. And I think it's going to take time to evolve the best approach to share those – we've been using Town Hall as a mechanism, but what is the recommendation from this group for how we get feedback from the community without taking a ton of time?
Ways forward
Stephen 14:11 Could Oversight assist IOG in creating a pattern of notification to the community? Obviously, it will take time to develop advance notification, But if IOG notify us that you’re going to announce something, is it part of our role to help with communication?
Harris 14:47 Yes; we could have discussions with this group sooner; and you would have deliberation and then you would share that with the community. That seems reasonable.
Allison 15:05 Harris, you say there haven’t been many parameter changes; but there have been several, such as changing the eligibility to be a VCA, and introducing the reputation model for VCAs.
On our role – at present, we are volunteering to oversee: to track changes, keep them organised and accessible, and give some context from an oversight perspective of what changed, when and why, and how it was communicated. But longer term, we could play the role originally envisaged in the Parameters Pilot – to help consolidate community feedback, and help communicate the research or considerations that are going into these decisions.
Harris 17:49 That’s fair; we do need to share more. Some big changes have happened due to a need to respond immediately to problems. So if we have some research that suggests we should make a change, what are the practical next steps for us to share that? Who should get the information first?
Stephen 19:23 When I drafted the F7 proposal in consultation with Dor, we planned to focus on overseeing governance processes, particularly challenge-setting and Circle problem-sensing. And with parameter changes too, we can oversee, maybe communicate them at Town Hall from a neutral perspective, and report every four months to say what we've seen and heard. In the Fund 8 proposal, there's also some resources given to research, led by Kenric.
Phil 20:56 Harris, you mentioned less-contentious parameters. So we've got
official parameters, some of which are less contentious and can be slowly transitioned to being decided inside the community,
official parameters that IOG should keep stewarding because they present a big risk, and
parameters that the community is identifying are being changed. We need to ensure that both the community and IOG know that these are parameters, if the community decides they are; and that in future, they're either put into the category of “at risk; needs to be stewarded” or “low risk, low contention”.
We're offering to be that communication channel; and to offer facilitation to support community Circles around the decision-making process.
Harris 22:55 How long is your funding good for?
Stephen 23:02 We'll do a closing report for the F7 proposal in June. If we get funded for F8, then October.
Tevo 23:39 For me, most changes to the system are parameter changes; but what makes them changeable parameters is the documentation behind them. Is there any priority on which decisions you would expect the community to start making first? We could think towards those parameters beforehand, and suggest processes, documentation or guidelines; then we could run those prioritised or expected parameters through that.
Harris 24:58 We need to take a stance on how decisions will be made. Ideally, Tevo, we want to parameterize every item, where it becomes a variable that sits in a system; so then we're making a change to a value that's stored somewhere accessible in the system. And if that’s there, it will help in terms of automation of the system. So we are viewing it as numbers in a script at some point. There's a lot of human process still involved, and it may be some time before we lose that; but in the meantime, we want to share that deliberation of those parameters more widely. I can list some additional examples of parameters that that we have; I shared a portion of that list in the early concept of the Pilot. So we can have some further discussion on very tangible, specific examples, if you'd like.
IOG attendance at CGO meetings
Allison 27:05 It might be useful if you or somebody from IOG wanted to attend our meetings, so that you hear what we're working on, and so we have a conduit to IOG to ask questions in real time and have an open dialogue.
Harris 27:50 I think that's great. Myself or someone else will definitely have a seat within your discussions; I think that makes sense.
Stephen Whitenstall 28:03 There has always been an open seat, the invite’s been there. I also said to Danny that we would alert IOG of anything we needed to discuss, and this is the alert! so it's working in practice.
Phil 28:23 As an alert: what we would like to do is raise in future Town Halls the parameters we have identified, and have some place for people to go and explore our discussions around them. Some of these parameters might not be considered parameters yet by IO; but it is our intention to publicise them as we see them. Not necessarily that they should be in the hands of the community right now; but that there's a way to get to that point.
What is, and is not, a parameter
Stephen 29:41 What might be helpful in terms of our report in June, is to document what we think are the current parameters, and what IOG list as parameters, as a comparison of perspectives.
Phil 30:17 From us, for instance, the CA / VCA process. We had a community-created VCA process of “red flag, yellow flag, green flag”; that was scrapped because of IOG research, and replaced with “good, excellent, filtered out”. So instead of bringing in an iterative change to a community-created process, IOG changed to a new system. That approach was OK in the early days; but it should happen less and less as we grow, so the community feels it's got agency.
Stephen 32:09 As well as the question of “what is a parameter” that Phil raised, there is “how are existing parameters documented?” and “how are the community notified?” Is there consistency on that?
How are decisions made, who makes them, and how is the decision-making process shared? How is the deliberation and the rationale shared? This is all oversight: overseeing the documentation, the notification, the decision making, the deliberation and the rationale.
Tevo 33:16 I have two examples. One may not sound like a parameter change, but it is - changing a name from Community Advisor to Proposal Assessor. Could the community do that? Or does IOG do it in the boardroom? Also, there is a grey area between system changes and parameter changes . More clarification is needed, so that we all know which is which; which changes need a separate body to do research before it's even open to discussion.
Vanessa 34:41 It will be interesting to compare our take on what is and isn't a parameter, with IOG's take. Our view is that some things don't superficially look like parameters, but their knock-on effects mean that they actually are.
Matthias 35:20 An example of a parameter change is requiring a deposit for proposal submission. It's very exclusive. My understanding is that Catalyst’s goal still is to “facilitate the highest potential of human collaboration”, and excluding more groups doesn’t meet that mission statement. There was no discussion; but some selected community members may have been consulted.
Will IOG lose its freedom to experiment?
Harris 36:47 There is some discussion of paying to propose, from a research side, that it would improve the quality of proposals; but there's no decision on it. So it might be a good example for us to track. If IOG had some interesting preliminary research that we wanted to start charging per proposal, how might we go through the process of sharing that? And how might we make a decision on it as a collective, with the community? Also there is the experimentation approach of Catalyst: “That didn't work - let's try it this way”. Can we maintain any of that freedom? Can we do that experimentation as a collective? Or are we trying to lock things down and make smaller changes and less experimentation?
Stephen 38:31 It comes back to communication. If you mention in passing “We are discussing the possibility of adding proposal fees”, it can sound like you’ve made a decision without consultation. How do we communicate better?
Phil 39:05 On Tevo’s point – the system has parameters. The CA process, or system, is a parameter itself; then there are additional parameters inside it. If we want to change things, we need some way to identify what's there, and then identify how to change it. [The CA system] is more than just the 1% rewards; it’s the whole process.
Harris 39:42 That’s more like continuous improvement; there's constant change.
Phil 39:48 But then there's parameters like “do we keep calling it the CA process?” There's a vocal group of people who disagree with the name, but there's no system in place to change it, or even have a conversation, beyond just Tweeting complaints about it. We need to develop the processes to be able to change it; and now is the time. We're at a point where we can start looking beyond just making proposals so that we can have this thing called Catalyst - we already have it. Let's look at how we can keep making it better.
Stephen 40:32 You could change that through Circle; but then the question is, should parameter changes go through Circle? And what should the decision-making process look like in Circle?
Phil 41:05 We're not completely reinventing this – community engagement processes are already used in governance, such as local councils having consultation periods. And we can use technology to solve some long-standing governance problems. I've been listening to Jordan Peterson on “chaos and order”. Everything we do will either add more chaos, or more order, to the system; and the idea is to keep that pendulum as close to the middle as we can, to work through it. We shouldn’t bring in too much order, or too much chaos – but we do need both, because one encourages freedom and innovation, and the other encourages accountability. What we're trying to establish here is how we can bring the community into that discussion.
Harris 42:58 At some point, a change will boil down to someone making a proposal. But how do we fold that into the fabric of the community? Perhaps a Catalyst change request, that is submitted to a group that deliberates on it? Currently, Circle is doing some of that, via sensing and prioritising problems; but at some point, the decision must be made. Part of the idea of giving some power to Circle, or other bodies, is to be able to actually make that decision. Ideally it is data-driven as much as possible. But these kinds of theoretically simple decisions – we do want it outside of IO; so where should it go?
Stephen 45:19 The intent of Community Governance Oversight is to help with that – to gather information, observe what's happened, and report on that at each iteration. So how much information does CGO need, to be well informed enough to make a good report on how governance is proceeding in Catalyst from the community perspective?
Whether CGO should be have decision-making powers is a separate issue. Maybe, in the future. But I see us very much as Oversight, because it avoids ambiguity – we don't make decisions, we observe what's going on and we ask questions.
Managing expectations on what the community can change
Vanessa 46:34 There’s a clear need for a process for changes, and for the community to understand what the process is. Another need is managing expectations. There are different types of parameters: some of them, the community can have a say in changing, or maybe could control completely; but others, perhaps we can't be involved with at this stage. So we should ensure we don’t raise false expectations, or tell the community they can have an impact on things that they can’t influence, as that would be damaging. Also – at what stage will a potential parameter change be able to come from the community, rather than from IOG – bottom-up rather than top-down? I hope we'll never again hear a fait accompli announced at Town Hall, and not know where it came from, who decided it, or why we were not consulted. Clarity about what kinds of parameters we can expect to be consulted on, could prevent that.
Harris 48:59 Setting and managing expectations is certainly important. I don't know where the exact disconnect is, but it's our intention to give the community the ability to participate. How we approach that, is what this pilot is all about; it has been on hold, and I think we can reactivate the discussion. There are places where we do want to get the community's involvement. For instance, we're trying to develop a Circle code of conduct; and the community can help.
Stephen 50:36 A practical example of good communication: I transcribed Kevin Hammond’s Town Hall on Treasury, and I noticed that he explained why he couldn't tell us particular things. For example, he said “I can't tell you this, because it affects security”. We know IOG is working on lots of things that you probably can't tell us. But rather than use the refrain, “we will let you know”, explain in general terms why you can't tell us – for example, “because we're still working on it” or “there's security issues”. That also helps distinguish parameters that the community can change or affect, and those we can’t.
Phil 52:20 On the decisions that can't have community input at this point – we still need the communication, the consultation and the comment. The decision-making can stay in the hands of IO for now, but at least create a feedback loop so that the community has the opportunity to give insights. We've also got dReps – at the moment, they are focused on voting on proposals, but in theory they’d be available to run votes on other things as well. They could be a decision making channel; because they will be elected officials, in a way, through delegation. And on parameters that we cannot change at this point, we need to know what the “goalposts” are – so “When this happens, then the community is ready to start to make this decision”.
Harris 54:13 I think it's fair that we should characterize the type of problems, because some are minor and some are much bigger. And if we cannot provide full information, I think it’s fair that we should provide an adequate reason why not, such as “because it’s a security concern”. We can try to establish that habit. But some of that is also mid-flight too; so I will just say that.
Sharing IOG’s decision-making template
Tevo 55:38 Is there a template or guideline internally in IOG, that you will go through in order to make changes to a parameter?
Harris 55:56 Yes; there's often a document that we review to see if there's any changes; and often there's minimal or no changes fund-over-fund. I believe we should be able to share it at some point; after editing a few sensitive things. But for the most part, it's pretty moderate; it involves things like the percentage of how many “approve” and “disapprove” votes happen, and certain thresholds – I don't know if we've shared in detail before, but if we haven't, we should. But we do have to be a little bit careful, to avoid people saying “Oh, if I just meet this threshold and do this, then I can game the system”. So I am happy to try to work towards that goal of sharing a more comprehensive list. I've shared some examples in the early pilot discussion – the reward distribution date, the dates themselves. But the proposal acceptance threshold – at least 1% of the total registered stake must vote on a proposal for it to be there; there's got to be a delta between the two – there's some logic that was built with research.
Stephen 57:43 So a vetted copy of that template could be passed on to us, that we can communicate?
Harris 57:51 I can certainly help facilitate that, and work toward that goal.
End and thanks
Stephen Whitenstall 57:57 Thanks, everyone for contributing to this meeting. We'll do a transcript, and summarise what's been discussed. Any feedback or final thoughts?
Harris 58:19 I think it's really great. I definitely applaud your efforts, and I'm definitely happy to stay in the conversation and keep this going and take us to the next stage.
Tevo 58:36 I think you’re doing a great job in reaching out. Newcomers might miss some details of why decisions are made; but often, we can see that you’re basing it on consultation. This the first time I’ve ever been in a meeting with a company where both are aligned to the same vision, so the openness is totally unique.
Meeting ends 59:17
Summary by V Cardui for QA-DAO, based on auto transcript from otter.ai
Last updated