Feedback on Polkascans Treasury proposals #16+#17

6 Comments

References

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.

Up
Comments
No comments here