[Discussion] Guiding principles Shimmer Grant Committee

The community works on establishing a Shimmer community-committee-based grant program.

The draft of the full proposal can be found here: Shimmer Community Grant Committee Idea - Google Docs
A set of questions and thoughts to work on here: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

Such a grant committee will need a set of rules that will define the boundaries of its operation and help clarify its purpose, its goals, and what should or should not happen in such a program.

Currently, the guiding principles are denied like this:

Guiding principles for funding decisions:

  1. A proposal must be relevant to the Shimmer network and its ecosystem.

  2. A proposal that segregates individuals, organizations, or communities based on sex, race, color, ethnic or social origin, genetic features, language, religion or belief, political or any other opinion, membership of a national minority, property, birth, disability, age or sexual orientation will be declined.

  3. The committee will prioritize projects with the highest positive impact on the ecosystem compared to the received funding.

  4. Projects that can guarantee a backflow of capital/ investment into the community treasury will be evaluated more positively.

  5. The proposer or team must be capable of delivering the proposed project. Valuating this is a responsibility of the committee.

  6. If a project receives a grant and will deliver code, the code must be open source (under MIT or Apache 2.0 license). Projects in development must allow the grant committee to access any private repos for review, and these projects will only receive the final payout after fully open-sourcing their code.

  7. The requested budget must match industry standards for comparable tasks. If a proposal requests way above fair market value, the committee may either reject the proposal or cut the funding to settle at fair market value.

  8. If a project has already received funding from the Tangle Ecosystem association, it cannot receive funding from the community treasury for the exact scope of work again. But additional funding for extensions or further developments of such a project can be granted by the committee.

  9. A proposal that creates any conflict of interest from members of the proposing team or committee members must be reported to the committee lead. Committee members with conflicts of interest are not allowed to process, comment or vote on a proposal.

We would like to hear opinions on that and see if we can / need to improve certain things, include more topics or should remove certain things.

Edit notice 07/09 - added point 6

Edit notice 08/09 - used the text @DigitalSoul.x proposed in his comment for point 2

8 Likes

Hi Phylo, and thanks for putting this all together! I like that some items have been eliminated or combined to make the document very short and concise.

One item that I mentioned last week was that perhaps we should stipulate that grants can only be offered to projects willing to open source their code. Since these are community funds, the IP is essentially community property if grants are used for development. So, if a project fails to deliver after accepting a grant, the community should have the option to pick up where the team left off and continue development if it makes sense.

Do you think there is an issue with this or that perhaps it doesn’t belong in the guiding principles?

1 Like

Right…access to a repo at a minimum for any committee members (if not a public repo) could be beneficial to assess performance.

2 Likes

Agreed, it doesn’t need to be made public if projects are keeping development close to the vest, but it should be open to committee members and evaluators. If the project is eventually abandoned it could be made public.

1 Like

Oh yes, good point, Rob. I think it needs its own mention here, and I have added a sentence. Let me know what you think!

1 Like

This is great, Phylo! Thank you for adding this. While I could be satisfied with your wording I might personally offer slightly different text:

“If a project receives a grant and will deliver code, the code must be open source (under MIT or Apache 2.0 license). Projects in development must allow the grant committee to access any private repos for review and these projects will only receive the final payout after fully open-sourcing their code.”

1 Like

Sounds great Rob, lets take that!

1 Like

Thanks @Phylo. Very informative.