- Status: Early draft proposal
- Last update: 2023-8-22
Provide a grant policy for the Tusky project that is:
- Legal
- Fair
- Transparent
- Observable by non-project members
- Verifiable by project donors
This is not about incurring expenses for the project while purchasing assets or entering into contracts. That is the [[Expense policy]].
A grant is the payment of money to one or more people to accomplish a specific piece of work in a specific timeframe.
For example, work that:
- Implements a specific feature
- Reviews user feedback for the last N months and proposes concrete documentation improvements
- Reviews every screen in the app for accessibility issues, and produces a report with the findings and actionable suggestions
A grant proposal must contain the following information, which will be made public:
- Title
- Synopsis of the work to be done
- A description of the expected benefits to the project and / or users
- A concrete list of deliverables
- A proposed schedule for delivery
- GitHub and Mastodon usernames
- Your biography, with enough information to explain why you can complete the grant
- The requested amount for the grant
- The proposer may decide to break their proposal down in to a series of milestones, with a payment for reaching each milestone. This is strongly recommended.
We considered whether grant proposals should be "blinded" -- i.e., the group approving the proposal would not know the identify of the person making the proposal.
This has some benefits as a way of reducing bias in the approval process.
However, some bias is beneficial. For example, it is useful to know who is proposing to work on a specific project for three months, as their track record of delivering (or not) projects on time and to an expected level of quality is an important piece of information when deciding whether or not to approve the grant.
It must also contain the following information, which will not be made public:
- The proposer's nationality and residency
This is so the project can comply with any laws governing commerce between residents or nationals of particular countries.
All proposals will be published at TODO to gather feedback, and to provide examples to future proposers of successful and unsuccessful grants.
The Tusky Mastodon account will post a link to each new proposal.
Grant proposals are reviewed once every calendar month, and must have been available for public comment for at least two calendar weeks before review by the project.
Therefore, if your proposal is published less than two weeks before the proposal review meeting in a given month it will be reviewed at the meeting the following month.
Grants are reviewed by the following people: TODO
If a proposal is accepted by the review team the proposer is notified,
The public repository of proposals will be updated to show the proposal has been accepted.
The team may decide to decline a proposal. Reasons for this may include one or more of (and are not limited to):
- The project does not have sufficient funds for the proposal at this time
- A competing proposal was deemed to be more important
- The proposer does not have a track record of successfully delivering projects of the proposed scope
- The project does not have anyone free to liase between the proposer and the project
- The proposal did not contain enough detail for the team to decide
The public repository of proposals will be updated to show the proposal has been rejected.
The review team may have actionable feedback for the proposer on ways they could change their proposal so it could be approved. If it exists this feedback will also be made public.
After accepting a proposal, someone from the project is assigned to work with the grantee during the grant period.
They are responsible for:
- facilitating regular communication between the grantee and the project
- helping remove any roadblocks that are identified
- E.g., grantee has been waiting many days for a review by someone else on the project, and cannot make progress without it
- raising any concerns with the proposal team
The grantee is responsible for regularly communicating the current state of their work, and anything that is blocking their work. They must flag issues that will affect the work (e.g., "this change is going to affect much more of the code than I expected") as early as possible.
The grantee is strongly encouraged to track the amount of time they are spending on the project to continue to improve their estimation skills.
The project may decide to end the grant early, for reasons including, but not limited to:
- It becomes clear that the proposer is unable to complete the expected work in the time
- The proposer becomes unavailable or stops communicating with their project liason
The proposer may also decide to end the grant early for whatever reason.
If the proposal included proposed payments for specific milestones, and some of those milestones have been reached... TODO
- Where is the line between grants and employment? If someone repeatedly, successfully, applies for a grant and is paid multiple times, is there a risk that they could legally be treated as an employee?
- Is there a minimum age for a grant recipient?
- What are the tax implications?
- Who can make a proposal?
- Apart from any legal restrictions on nationality or country of residence, do any other controls need to be in place?
- Can a member of "Tusky contributors" submit a proposal?
- If they're on the review team they have to recuse themselves, obviously
- How do we avoid bias (either real, or apparent)?
- What type of work is not suitable for a grant proposal?
- PR review
- Cleaning the issue tracker
- Running the release process (?)
- Ongoing user support (?)
- Should there be a cap on the amount of money that can be requested in a grant proposal?
- Should there be a cap on the duration of a grant proposal?
- I think so. Probably 1 month max, people are terrible at estimating how long a piece of work will take
- Should we have a fixed hourly rate, and suggest that people submit grant proposals with an expected amount of time, rather than a total cost?
- Pro
- Some people will low-ball their worth, and submit proposals that effectively under-pay them. And vice-versa of course. Paying people a fixed rate per proposed hour avoids that.
- Con
- People are notoriously bad at estimating how long something will take them. What happens if someone says it will take 10 hours, they get in to it, and it takes them 20?
- That's the risk they assumed. The review team can always ask questions if they think the time estimate for a proposal is off.
- Similarly, someone puts in a proposal for 10 hours and it takes them 3. Do they get paid for the other 7?
- Yes. The project is paying the grantee for the results, not the time.
- Does this allow competing proposals? Someone makes a proposal saying it will take 2 weeks, someone else copies it and says it'll take them 1 week.
- Yes it does. Is that something we care about?
- People are notoriously bad at estimating how long something will take them. What happens if someone says it will take 10 hours, they get in to it, and it takes them 20?
- Pro
- Could we also describe grant proposals for work we want done but don't have the time for?
- Like a "bounty" for doing the work.
- People could "bid" on the proposal by saying how much time it will take them
Putting this together I reviewed how other projects do this sort of thing for ideas and best practices. Most of them are a lot larger than Tusky.
However, it's much easier to put some processes in place while the project is small.