OpenSquare off-chain voting platform

[wliyongfeng]

Project Abstract

In short, you can see this proposed platform as snapshot in the polkadot ecosystem.

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• The total funding amount of the project is below USD $30k for first-time grant applications and $100k for follow-up ones.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Thank you for submitting a grant application.

We've assessed your submission and have found that it requires a higher level of technical detail in order to be considered for review. We encourage you to expand on it by providing a more precise specification/technical details. The section on project details in the application template is a good reference as to what type of information we expect applicants to provide, and these category-specific requirements contain more precise guidelines depending on what type of software you're building.

An area of the application that we often find to be insufficiently elaborated are the milestone deliverables. At a minimum, please indicate what languages/technologies you will be using to implement each deliverable, and provide a technical summary of its expected functionality. Note that deliverables should be tangible, reusable by other teams and in most cases not already present in the ecosystem. If they are, you will need to provide a comparison to existing implementations and explain why it makes sense to fund your approach. Also see our FAQ for a breakdown of what we fund and what we don't.

Let us know as soon as you're done with your changes, and we'll give your application another look!

[Noc2]

Just to add. This looks really good, but could you update the milestone deliveries according to our template: https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#milestone-1-example--implement-substrate-modules Also adding more technical information about the license, testing, programming language, polkadot.js extension etc. Apart from that I think user stories are already good deliveries. Maybe also see milestone 1 of this application: https://github.com/w3f/Grants-Program/blob/master/applications/bright_treasury.md#milestone-1--idea-creating--proposal-submission--in-app-logins

[wliyongfeng]

@Noc2 Thanks for the feedback. Have correct the deliveries format.

I tried to give more technical implementation details in the deliveries table code cell and implementation notes. But still not very sure with the 'a higher level of technical detai', please tell me if they are still not enough.

[alxs]

Just a note in case there's any more feedback: no need to force-push any more. This is just for the initial PR, subsequent commits are useful as they allow us to see the changes.

[Noc2]

Thanks for the update and sorry for the late reply. I’m happy to go ahead with it. But feel free to remove Deployment & Promotion. That’s something that we usually don’t support via grants, but obviously it’s great if you do it anyway.

[wliyongfeng]

Thanks for the update and sorry for the late reply. I’m happy to go ahead with it. But feel free to remove Deployment & Promotion. That’s something that we usually don’t support via grants, but obviously it’s great if you do it anyway.

Removed and for sure we will deploy it to collaborate with communities and for your better future review.

[alxs]

@wliyongfeng I agree, this actually looks very good. I don't remember exactly what was missing the first time, but perhaps I was a bit trigger-happy with the 'details-missing' label. Looking forward to the results!

[mmagician]

To be honest, I don't clearly see how having another platform next to Polkassembly would help the ecosystem, especially that you'd get fragmentation of the user base -> results from off-chain voting would be less representative of the real vote.
I get the feeling that you're trying to differentiate from Polkassembly just "for the sake of it":

• no for registration
• yes for signatures

In the end these are two different mechanisms towards having "credible" votes and you haven't provided justification for why one is superior to the other.

While it's true that we generally via Grants Program we support multiple implementations for the same functionality, these usually doesn't have an impact on the global outcome (e.g. the staking rewards collector will be used by a single user, and the ecosystem doesn't suffer if one user goes with implementation A and another user with implementation B). In this case however, my assumption is that a community member will either cast their votes on platform A or B, not both (tracking all the proposals happening is already considerable amount of work, let alone tracking/commenting on multiple platforms).

All that said...it would be great not to rely on a single platform in case the development there ceases. But since polkassembly is open-sourced anyway, that risk is greatly reduced.

I'm still on the fence with your proposal. Have you perhaps considered proposing new features to be merged into polkassemby instead?

[wliyongfeng]

Hi, @mmagician .

Understand, and we will be happy if polkassembly can have rich of features that we expected. We received same concern when we develop dotreasury and Statescan. I think we don't have to discuss too much about questions like, why subscan while there are polkascan, why google while there are yahoo. Yes, we can add these proposed features to polkassembly, but I'm very worried and hesitated about following truth:

• I have to setup polkassembly and understand every code to contribute my expected features
• Every of my PRs have to pass the review. It main include some rules like code style, test coverage requirement, etc
• We have to use some tech stack that we don't like. Actually we checked the code of polkassembly and it's the truth that we're not familar with some tools or libraries

For the reasons above, contributing to polkassembly directly will cost at least double time/cost. And we believe many contributors will quit if the requirement is contributing to similar projects.

What we expect is to deliver the features with least time and lowest cost. Then let's see what happens, maybe let some products merge to one if possible.

About the fragmentation, we don't think polkassembly contains all the features we proposed and we don't think that we don't have to do it since polkassembly may have it in the future. And we can let this platform down or just redirect to polkassembly, when polkassembly support it.

representative of the real vote

We don't expect this off-chain voting/polls will take place of on-chain voting. We expect community members engate more in ecosystem building, while I think the reason for many community members not vote on-chain is just avoid gas. And it may also provide ways of voting for Statemine and ERC-20 assets easily.

[mmagician]

I have to setup polkassembly and understand every code to contribute my expected features
Every of my PRs have to pass the review. It main include some rules like code style, test coverage requirement, etc

Well, these are expected when contributing to any codebase. I would strongly argue that the second point is an advantage rather than a disadvantage, since it enforces good coding practices, which leads to cleaner, and especially safer, code.

We have to use some tech stack that we don't like. Actually we checked the code of polkassembly and it's the truth that we're not familar with some tools or libraries

Again, this is going to be true for any codebase. You will find that the tech stack you use is unfamiliar to other community members and that they prefer to work with different tools. Consider this: if every time that I encounter a new project that I'd like to contribute to, I decide to re-build most functionality from scratch with a different tech stack that I'm more comfortable with, then open source won't get anywhere. I acknowledge there some diversity is needed, but I strongly disagree with the reasons you provided above for diversification.

[wliyongfeng]

I would strongly argue that the second point is an advantage rather than a disadvantage

Sure for one codebase robustness, but maybe not for fast and low cost features delivery. What we expect is to provide a off-chain solution like snapshot quickly.

Honestly I don't care about the code quality of polkassembly, and don't want to take the trouble to add features to polkassembly. And as I said, after this delivery, polkassembly developers can copy the features to their repo, and we can even make our voting off if you think it should be on polkassembly officially.

I strongly disagree with the reasons you provided above for diversification.

The main reason is the time & cost. And most of our code is open source too.

[semuelle]

@wliyongfeng, my only question is: if you jump through the hoop of storing the voting data on IPFS, will you make the location & format publicly available? Or what is the benefit of using IPFS?

[wliyongfeng]

@semuelle
Thanks for the comment. Sure, we try to make it public and not be private collection. Benefits of using IFPS:

• User can get the IPFS link of their voting/proposal data immediately. It will be a proof that we can not just keep the data, not show it and affect the result.
• In case of data loss and we can recover the data in a better way if our server with database down.

@mmagician
Sorry if my comments are still not convictive, but still hope to get your support. Supporting statemine assets will be our next plans, and I think it will make more sense while they may have no any on-chain governance. We tried to narrow the scope to build some basic modules first and for better review.

We will be very glad to merge some of features to polkassembly or other platforms if they verified works, and of course, at a better time.

[semuelle]

My comment regarding IPFS was more along the line of others being able to build alternative UIs or features around the data, but either way, I'm happy to support this.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀