[Discussion] Guiding principles Shimmer Grant Committee

✍ General Governance Community Grants Committee
,
1

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

13 Likes
2

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?

3 Likes
3

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

4 Likes
4

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
5

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
6

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.”

2 Likes
7

Sounds great Rob, lets take that!

2 Likes
8

Thanks @Phylo. Very informative.

2 Likes
9

Hey, great document!

I’m curious, any reason why GNU software licenses are not accepted?
As they offer the 4 freedoms (run, study, share, and modify the software), it seems aligned with the interests of IOTA, Shimmer and the committee. Or maybe I’m missing something?

For context:
https://www.gnu.org/licenses/gpl-3.0.en.html

2 Likes
10

Hey Danielo. Great addition. We did not have them on the “radar” but it is true a good addition - ill put that in the updated version of the proposal. Thanks for the input!

2 Likes
11

should read - Currently, the guiding principles are “defined”. (not denied)

2 Likes