Feedback on Polkascans Treasury proposals #16+#17
References
- https://github.com/polkascan/social-contract/blob/master/kusama/contract.md
- https://kusama.polkassembly.io/motion/130
- https://kusama.polkassembly.io/motion/131
- https://kusama.polkassembly.io/post/61
Current state
By the time I write this, the votes has been casted and the proposals approved.
My comments are mainly no longer relevant regarding those proposals but we are laying out some rules for the next so I think a few points are worth discussing.
For the sake of brevity, I will try keeping arguments as short bullet points at the risk of being less 'smooth'.
Statement about Polkascan
Some of my comments below may sounds negative and some are :) but many are not.
To balance those comments, I feel it would be fair to bring a couple of statements:
- The Polkascan team has been involved very early in the Polkadot ecosystem. Being the first carries risks, one of them being to be the first to experiment a framework were many processes are not defined.
- The Polkascan team has been recipient of Web3 grants and delivering a widely used product.
Additional comments
Some of the comments here are directly related to the Polkascan proposals, some are resulting from those and may not be directly related.
Feedback
What I liked and support:
- the idea of a capped opex budget for decentralized operations
- the idea of a capped opex budget for centralized operations (what is relevant here for the Polkascan proposals)
- the idea of experimenting on such funding
- the fact that a council member does not vote on own proposal
- the idea of the pre-proposal made by Polkascan and the resulting Q/A, included in the proposal
- the idea of the treasury being used for supporting the ecosystem (obviously)
What I did not like / do not support
Riot Flooding
- Mixed topics discussions in the Riot Direction channel
- Various discussions and proposals got mixed up
This makes reviewing such a proposal much more time consuming than it should be.
Proposal rush
This is by far my biggest concern as I think many other issues may have been solved/answered with a little more time.
The fact that such proposal has been kept 'closed circle' and rushed: were there some announcements on more open channels such as the "Kusama Watercooler"?
The council members have been 'pinged' repeatedly in a short amount of time and I question how much of an impact it may have.
Do we want future treasury application to show up in the Direction channel and ping the council repeatedly several times a day?
Other potential applicants not in the channel or not having the time to follow the flow of related and unrelated comments in the channel just did not hear about the option to submit similar or competing proposals.
Some good questions were not properly answered, reinforcing the feeling what the process has been rushed.
Budget blur
I am not arguing the KSM conversion here. A proposal needs to contain an amount in KSM, how this number is calculated can be shared, or not. Proposals are judged on the KSM amount, not on how this amount is calculated.
I would have liked to understand a bit more the 500€/month figure, where does it comes from, what does it cover? what does it not cover?
The costs seem to be a mix of engineering time + infrastructure costs.
As far as I know, the engineering is covered by the web3 grants. So the grant appears to be covering only 'cloud infrastructure'? Is that so?
Proposal medium
Using an editable (hackmd/github) medium as support for a proposal is good when it comes at editing and adding content such as Q/A for instance.
But that means that council members need to track any diff of the proposal at the risk of not judging based on the real/final proposal.
Conflict of interests
The political danse of "ok, since you vote for me, I leave the council to let you in, I will come back anyway", although I do understand the concern
I support the fact that the Polkascan team did not vote on their proposal. The rest is a bit of a show and was likely not required.
Proposal scope & reporting
- the lack of reporting engagement: the proposal is requesting funds, ensuring a 'non profit' mode but does not mention any kind of reporting regarding how and how much of the funds will be spent.
Especially related to Q5. some reporting would allow better forecasting what future budgets should be and allow optimisation.
WISHES and PROPOSALS:
Clearer scope
The scope could have been described more clearly.
Call for tender
As a network, we saw major support from the council to allocate part of its budget to support infrastructure. We should/could have consulted providers (such as and including polkascan) to evaluate the scope and budget, requested each provider to make a proposal and evaluate those proposals.
The Council needs to be clear whether the budget to spent is related to one project or whether other similar projects can now expect similar outcomes for a similar proposals.
3 steps proposals:
Brainstorming:
That's the Riot and other forums time with Q&A. Things will move, proposals may change.
This the open discussion time were the proposal can take shape.
Freezing
Whatever support is used, the proposal document is frozen.
When using Hackmd or Github, that can be a simple signature/hash of the file. Using IPFS here makes it convenient as Council members don't need to spend any time checking for signatures and hashes.
Voting
The voting is based on the frozen document in its current state.
It is take it all or leave it.
Transparent reporting
Blockchain aims at being transparent. So should be treasury proposals. It should not end once the KSM land into an account.
Comments (6)
Comments (6)
quoting my response in the channel here, with some added context:
I agree with Shawn here
[regarding leaving council to get more votes, after declaring you wouldn't vote for your own proposal], I think the process is established and you're on council in the first place because people believe that you should be making these decisions.
cp287 has also made similar statements, focusing on the game theory of the issue - moving the conflict of interest offchain and into informal relationships does not help anyone. The ideal outcome is that the motion passes without needing to "vote for yourself" but my personal position is that if the decision is between an obvious conflict of interest (voting for yourself) and an obscured conflict of interest (leaving council to have another councilor vote for you, because you got their handshake agreement offchain), the obvious choice is the one that is more transparent.
I also generally find offchain/ephemeral/informal collaboration around onchain activities as more opaque than trying to decide things individually based on public information
This is the core here: I consider "Kusama Direction" a necessary evil that we should avoid unless... necessary. I agree with your position on 3 step proposals, and that is how I picture governance working best and scaling towards effective action more quickly. Basing decisions off of evolving discussions has alot of overhead that it is clear that the majority of councilors do not have bandwidth for - the tradeoff here is that we vote for potentially unpolished proposals, but at least on Kusama, I can live with that - and indeed, I believe we will get more value out of having more action and execution and less discussion/polishing of ideas, at this stage.
At the very least, the polishing should not happen in small channels with only the council participants taking part directly.
We appreciate the support we got van the Council and we appreciate the time some this Community has spent on having a dialog with us and providing us with feedback.
A mechanism for continuous dialog between the Community/Council and an Ecosystem Service Provider is one of the core contributions we tried to offer through our work in the past few weeks.
I do not intend to reflect to much, because in general I believe that our actions have had sufficient results.
That said I will briefly touch the items Chevdor points out and how we intend to address those going forward.
Riot Flooding
In my role as a Council Member the Riot discussions have been very valuable to think about the role of Council Member. You cannot develop ideas in isolation.
Proposal rush
Any entity making a treasury proposal will require the Council's attention.
I do not believe it is necessarily wrong to ask for attention when you really want to get things done.
That said, we will no longer use the Kusama Direction channel to push through our proposals. I will address our process for subsequent proposals in a bit.
Budget blur
I agree that a KSM amount should be in the proposal. That said, Polkascan Foundation has it expenses in EUR and there is significant price volatility and conversion slippage in play. We were very transparent about the calculation of the sum we asked for. When the proposals were voted on the exact KSM amounts were available. We will make sure to have the KSM amount available sooner (during freezing phase).
Regarding the origin of the 500 EUR/month; I really feel we explained it sufficiently in the Social Contract. It is for operational expenses that can be attributed to having the Kusama network on Polkascan.io. This includes duplicate setup for dedicated servers, monitoring tooling and approximately one runtime upgrade per month. The later should definitely not be seen as engineering expenses; these are configurations that digest the changes of the runtime upgrades. These are not platform expenses. These are expenses that can be attributed to maintaining support for Kusama on Polkascan.io. Last but not least the Social Contract is not static. We explained in various Q&As that we will use our future relationship to increasingly provide more transparency and accountability on cost-drivers and cost-attribution in the Social Contract. There is a balance between detail and getting things done.
Proposal medium
This was the first proposal. The lessons learned here are that a collaborative editable HackMD medium is good for Q&As.
That said at the time of the treasury proposals we already moved the Social Contract to our github and announced that we will be taking issues and pull requests.
This should remove the concerns raised.
Conflict of interests
This is the items we had most difficulty with. It is suggested that we influenced the vote by dropping off the Council.
Let me start by saying that it is really hard to get a treasury proposal approved (and rightfully so).
It is really a conundrum. We have come to conclusion that we will use our future Council Membership (if any) to vote on our own proposals.
We have always been clear that with Polkascan project we want solve the sustainable funding for ecosystem providers. Our best way to solve that is to set the example as such a service provider and to work on best practices. Being on the Council provides us additional means to further these goals. Being the first is hard.
If you cannot vote on your own proposal there is a serious disadvantage in getting a sufficient majority to get your proposal to pass. If we cannot be on the Council because of our high moral standards we do ourselves and those we were entrusted by with our Council Membership a disservice.
In the end public permissionless blockchains have different ethics than a legal entity, such as a company or a government. I have come to appreciate Cp287's, Shawn's and Jam's views regarding conflict of interest. (in contrast to Jaco's and Chevdor's)
There is a final thought I'd like to share on conflict of interest and that is that it should be clear who's interests you represent. I (Emiel) represent the interests of Polkascan Foundation first an foremost. That said I do believe that there is a very very high overlap of serving the interests of Polkascan Foundation, Kusama network, the Polkadot Ecosystem and the Substrate Ecosystem. But my point: whenever I am asking for funding it will be used to further the mission of Polkascan Foundation which has legal by-lays that require us by lay to execute the mission of making multi-chain data accessible. So if I am advocating for getting funding it will go to our Polkascan Foundation's funds. This is something that could gain wider adoption in this ecosystem. E.g. whenever employees of Parity Technologies or Web3 Foundation get tips or make treasury proposals the reward should really go to the employer and not to the employee. It is for the employer to decide what happens with the reward. It is the employer that should have that authority.
Proposal scope & reporting
It is not true that there is no reporting engagement. Polkascan is providing a service (polkascan.io) in a similar way that is has provided that service in the past 8 months. This is a high quality service and we have taken measures to ensure this quality standard. In general there is a monthly price and a clear expectation of a service that is provided in return. Polkascan.io has been around long enough for people to actually make a judgement about that service. That said, reporting could perhaps be improved and could become part of the Social Contract for subsequent service terms. Three month terms provide a good balance between defining a service we can budget for.
Next steps / process
- Our service term runs from 1 May 2020 to 31 July 2020.
- Our Social Contract is on Github: https://github.com/polkascan/social-contract/tree/master/kusama
- Our subsequent service term will run from 1 August 2020 to 31 October 2020.
- We will accept changes (github pull requests) and have dialog (github issues) with the community on the Social Contract until 4 July 2020. This is 4 week before the start of the subsequent service term. At that date we will freeze our master branch.
- We will announce this Freeze in the Kusama Direction channel and will accept changes from the Council Members until 18 July 2020. That final result will be the content of the next Treasury Proposal.
- Given a three day voting period by the Council this will hopefully get us funding for the next term and gives us a bit over a week to put the funding to work.
quoting my response in the channel here, with some added context:
cp287 has also made similar statements, focusing on the game theory of the issue - moving the conflict of interest offchain and into informal relationships does not help anyone. The ideal outcome is that the motion passes without needing to "vote for yourself" but my personal position is that if the decision is between an obvious conflict of interest (voting for yourself) and an obscured conflict of interest (leaving council to have another councilor vote for you, because you got their handshake agreement offchain), the obvious choice is the one that is more transparent.
This is the core here: I consider "Kusama Direction" a necessary evil that we should avoid unless... necessary. I agree with your position on 3 step proposals, and that is how I picture governance working best and scaling towards effective action more quickly. Basing decisions off of evolving discussions has alot of overhead that it is clear that the majority of councilors do not have bandwidth for - the tradeoff here is that we vote for potentially unpolished proposals, but at least on Kusama, I can live with that - and indeed, I believe we will get more value out of having more action and execution and less discussion/polishing of ideas, at this stage.
At the very least, the polishing should not happen in small channels with only the council participants taking part directly.
We appreciate the support we got van the Council and we appreciate the time some this Community has spent on having a dialog with us and providing us with feedback.
A mechanism for continuous dialog between the Community/Council and an Ecosystem Service Provider is one of the core contributions we tried to offer through our work in the past few weeks.
I do not intend to reflect to much, because in general I believe that our actions have had sufficient results.
That said I will briefly touch the items Chevdor points out and how we intend to address those going forward.
Riot Flooding
In my role as a Council Member the Riot discussions have been very valuable to think about the role of Council Member. You cannot develop ideas in isolation.
Proposal rush
Any entity making a treasury proposal will require the Council's attention.
I do not believe it is necessarily wrong to ask for attention when you really want to get things done.
That said, we will no longer use the Kusama Direction channel to push through our proposals. I will address our process for subsequent proposals in a bit.
Budget blur
I agree that a KSM amount should be in the proposal. That said, Polkascan Foundation has it expenses in EUR and there is significant price volatility and conversion slippage in play. We were very transparent about the calculation of the sum we asked for. When the proposals were voted on the exact KSM amounts were available. We will make sure to have the KSM amount available sooner (during freezing phase).
Regarding the origin of the 500 EUR/month; I really feel we explained it sufficiently in the Social Contract. It is for operational expenses that can be attributed to having the Kusama network on Polkascan.io. This includes duplicate setup for dedicated servers, monitoring tooling and approximately one runtime upgrade per month. The later should definitely not be seen as engineering expenses; these are configurations that digest the changes of the runtime upgrades. These are not platform expenses. These are expenses that can be attributed to maintaining support for Kusama on Polkascan.io. Last but not least the Social Contract is not static. We explained in various Q&As that we will use our future relationship to increasingly provide more transparency and accountability on cost-drivers and cost-attribution in the Social Contract. There is a balance between detail and getting things done.
Proposal medium
This was the first proposal. The lessons learned here are that a collaborative editable HackMD medium is good for Q&As.
That said at the time of the treasury proposals we already moved the Social Contract to our github and announced that we will be taking issues and pull requests.
This should remove the concerns raised.
Conflict of interests
This is the items we had most difficulty with. It is suggested that we influenced the vote by dropping off the Council.
Let me start by saying that it is really hard to get a treasury proposal approved (and rightfully so).
It is really a conundrum. We have come to conclusion that we will use our future Council Membership (if any) to vote on our own proposals.
We have always been clear that with Polkascan project we want solve the sustainable funding for ecosystem providers. Our best way to solve that is to set the example as such a service provider and to work on best practices. Being on the Council provides us additional means to further these goals. Being the first is hard.
If you cannot vote on your own proposal there is a serious disadvantage in getting a sufficient majority to get your proposal to pass. If we cannot be on the Council because of our high moral standards we do ourselves and those we were entrusted by with our Council Membership a disservice.
In the end public permissionless blockchains have different ethics than a legal entity, such as a company or a government. I have come to appreciate Cp287's, Shawn's and Jam's views regarding conflict of interest. (in contrast to Jaco's and Chevdor's)
There is a final thought I'd like to share on conflict of interest and that is that it should be clear who's interests you represent. I (Emiel) represent the interests of Polkascan Foundation first an foremost. That said I do believe that there is a very very high overlap of serving the interests of Polkascan Foundation, Kusama network, the Polkadot Ecosystem and the Substrate Ecosystem. But my point: whenever I am asking for funding it will be used to further the mission of Polkascan Foundation which has legal by-lays that require us by lay to execute the mission of making multi-chain data accessible. So if I am advocating for getting funding it will go to our Polkascan Foundation's funds. This is something that could gain wider adoption in this ecosystem. E.g. whenever employees of Parity Technologies or Web3 Foundation get tips or make treasury proposals the reward should really go to the employer and not to the employee. It is for the employer to decide what happens with the reward. It is the employer that should have that authority.
Proposal scope & reporting
It is not true that there is no reporting engagement. Polkascan is providing a service (polkascan.io) in a similar way that is has provided that service in the past 8 months. This is a high quality service and we have taken measures to ensure this quality standard. In general there is a monthly price and a clear expectation of a service that is provided in return. Polkascan.io has been around long enough for people to actually make a judgement about that service. That said, reporting could perhaps be improved and could become part of the Social Contract for subsequent service terms. Three month terms provide a good balance between defining a service we can budget for.
Next steps / process