feat: Regional Community DAO

[leohhhn]

Description

WIP

[Gno2D2]

🛠 PR Checks Summary

🔴 Pending initial approval by a review team member, or review from tech-staff

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)
🔴 Pending initial approval by a review team member, or review from tech-staff

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: leohhhn/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Pending initial approval by a review team member, or review from tech-staff

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 Not (🔴 Pull request author is a member of the team: tech-staff)

Then

🔴 Requirement not satisfied
└── 🔴 If
    ├── 🟢 Condition
    │   └── 🟢 Or
    │       ├── 🔴 At least 1 user(s) of the organization reviewed the pull request (with state "APPROVED")
    │       ├── 🔴 At least 1 user(s) of the team tech-staff reviewed pull request
    │       └── 🟢 This pull request is a draft
    └── 🔴 Then
        └── 🔴 And
            ├── 🟢 Not (🔴 This label is applied to pull request: review/triage-pending)
            └── 🔴 At least 1 user(s) of the team tech-staff reviewed pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[jeronimoalbi]

Yes, the idea is that devs should explicitly check it.

Following that idea it would be good that the fact is mentioned in the Propose() method docs.
Documentation is something that should be improved 👍

Not checking that the creator address is a DAO member makes the proposing open to other use cases where devs might want to create proposals without enforcing membership.

[jeronimoalbi]

Could be simpler:

Suggested change

	// RenderableProposal makes sure that the proposal is renderable
	RenderableProposal interface {
	ProposalDefinition
	Render() string
	}
	// Renderable makes sure that the proposal is renderable.
	Renderable interface {
	Render() string
	}

This interface might be a good candidate to be defined in a p/nt/commondao/ui package.

[jeronimoalbi]

Definitely a good feature to have, default render support for proposals, or DAOs so users can opt in.
It would be good to consider having a p/nt/commondao/ui or p/nt/commondaoui for render related features and default render logic.

At some point I tried to have render defaults so they could also be used in commondao realm, but I found it was somehow limiting when adding links between types like DAO, proposal and vote for example, or when dealing with pagination because the rendered content was highly dependent on the realm render logic and the paths being resolved.

[jeronimoalbi]

In this case and the other majority check functions the second boolean result means that a majority was reached and voted for the same voting choice when result is true otherwise it means that currently there is no majority winner. For SelectChoiceByAbsoluteMajority() majority is met when more than 50% of the members voted the same choice.

There might be cases where devs would have to define their own majority check functions if the ones pre defined here won't work for their use case.

It might be good to add more majority check functions to cover more cases. A nice to have :)

Quorum can be checked using the IsQuorumReached() function, there are also a couple of pre defined quorum constants to be used with that function. All defined within the proposal.gno file.

[jeronimoalbi]

You could also move this into a Validate() error method.
Validate is called before execution, if it fails then Execute() is not called.

Just in case, have in mind that right now Validation() and Execution() errors don't make the transaction fail, so using panic is the right move if you want the TX to fail and are expecting to change the state to eventually be able to successfully execute the proposal or if you plan to implement a way to change the proposal status yourself.

Right now, and before returning an error within the Execute() method, it's important to make sure that the actual state changes are done after the current state is validated. Maybe changing commondao proposals to have an expiration date after which proposals could be invalidated would be a safer solution, so any execution error would panic by default 🤔. I'm not really sure about what would be the best approach. Thoughts on this would be helpful.

Otherwise returning an error in either of those will potentially lead to save any state changes done before returning the error and the proposal state will be updated to failed.

I will give a though on how to improve this behavior because right now doesn't seem right.

[leohhhn]

Let's add MustValidate & MustExecute?