This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a
>(such as this one) can be removed.See the Maintenance Grants Process on how to submit a proposal.
- Team Name: Legal name of your team (e.g. JsonCorp)
- Payment Address: In the case of fiat payment, please share your bank account privately with [email protected] via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) payment address. Please also specify the currency. (e.g. 0x8920... (DAI))
- Level: 1, 2 or 3
⚠️ The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.
If this application is in response to an RFP, please indicate this on the first line of this section.
If this is an application for a follow-up grant (the continuation of an earlier, successful W3F grant), please provide name and/or pull request of said grant on the first line of this section.
Please provide the following:
- If the code name of the project is not descriptive, a tag line (one sentence summary).
- A brief description of the project.
- How will the project you want to take for maintenance help the ecosystem of Polkadot / Substrate / Kusama, and what problems does it try to solve?
- An indication of why your team is interested in supporting this project.
- Outline of why the specific projects should continue being supported.
Please provide a list of the repo(s) that need maintenance and further development:
- https://github.com/<project_organisation_1>/<project_1>
- https://github.com/<project_organisation_2>/<project_2>
- https://github.com/<project_organisation_3>/<project_3>
- Name of team leader
- Names of team members
- Contact Name: Full name of the contact person in your team
- Contact Email: Contact email (e.g. [email protected])
- Website: https://duo.com
- Registered Address: Address of your registered legal entity, if available. Please keep it in a single line. (e.g. High Street 1, London LK1 234, UK)
- Registered Legal Entity: Name of your registered legal entity, if available. (e.g. Duo Ltd.)
Please describe the team's relevant experience. If your project involves development work, we would appreciate it if you singled out a few interesting projects or contributions made by team members in the past. For research-related grants, references to past publications and projects in a related domain are helpful.
If anyone on your team has applied for a grant at the Web3 Foundation previously, please list the name of the project and legal entity here.
- https://github.com/<your_organisation>
- https://github.com/<your_organisation>/<project_1>
- https://github.com/<your_organisation>/<project_2>
Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.
- https://github.com/<team_member_1>
- https://github.com/<team_member_2>
- https://www.linkedin.com/<person_1>
- https://www.linkedin.com/<person_2>
If you've already started implementing your project or it is part of a larger repository, please provide a link and a description of the code here. In any case, please provide some documentation on the research and other work you have conducted before applying. This could be:
- links to improvement proposals or RFPs (requests for proposal),
- academic publications relevant to the problem,
- links to your research diary, blog posts, articles, forum discussions or open GitHub issues,
- references to conversations you might have had related to this project with anyone from the Web3 Foundation,
- previous interface iterations, such as mock-ups and wireframes.
This section should specify what kind of tasks and responsibilities the maintainer team will cover during future development. If you have already outlined a list of issues/bugs or pull requests that need further development - you can specify them here to provide more context on what tasks you will close.
Also, make sure the current project owners are willing to review/accept your contributions (a note here: if you're fully taking over the project, it will make more sense for the current owners to transfer the repository to your organization. If you can't get in touch with them, you may, of course, work on a fork).
Below we provide example maintenance responsibilities.
Issues we want to fix:
- There's a bug in the JsonRPC library that affects its speed.
- Massive lack of documentation and part of it is outdated.
- Code has no comments, and it's tough for new developers to understand the code and contribute.
Our responsibilities:
- We will maintain the project's documentation.
- We will answer issues and discussions.
- We will fix new bugs as we receive and help contributors who have pull requests get any needed information.
⚠️ Note that all code should be published under an open-source license during the maintenance period.
- Start Date: Date, when you plan to start with the maintenance work.
- Sprint/Period Duration: Duration of the sprint/period (e.g. 4 weeks)
- Total Duration: Duration of the entire maintenance contract (e.g. 1 year)
- Full-Time Equivalent (FTE): Average number of full-time employees working on the project throughout its duration (see Wikipedia, e.g. 2 FTE)
- Max budget per sprint/period: Requested max budget in USD per sprint/period (e.g. 7,000 USD). Cost for each period need to be provided in USD; if the grant is paid out in Bitcoin, the amount will be calculated according to the exchange rate at the time of payment.
- Hourly rate: Amount of budget per hour, since it’s unlikely that the maintenance of the project requires the exact same workload each sprint.
⚠️ Note that you will need to provide a comprehensive report of the work done at the end of each month, including the list of issues/bugs/pull requests worked on, time spent on each of these, & finally, the associated cost. The time allocation & price will likely vary from month to month, depending on the nature of the project you're contributing to. The report should be in the form of a Milestone Delivery, again like the typical procedure. W3F will make the payments only after the successful merge of each individual report.
Please include here
- how you intend to use, enhance, promote and support the projects in the short term, and
- the team's long-term plans and intentions in relation to it.
How did you hear about the Maintenance Grants Program? Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.
Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:
- Work you have already done.
- Whether there are any other teams who have already contributed (financially) to the project.
- Previous grants you may have applied for.