Skip to content

Latest commit

 

History

History
136 lines (86 loc) · 7.76 KB

maintenance-template.md

File metadata and controls

136 lines (86 loc) · 7.76 KB

Project Code Name (e.g. JsonRPC Tools Maintenance)

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: For USDC/USDT and DOT payments, please provide the Polkadot AssetHub address and the currency (e.g. 15oF4... (USDC)). In the case of fiat payment, please also 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.
  • 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.

Project Overview 📄

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.

Overview

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.

Maintenance list

Please provide a list of the repo(s) that need maintenance and further development:

Team 👥

Team members

  • Name of team leader
  • Names of team members

Contact

Legal Structure

  • 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.)

Team's experience

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.

Team Code Repos

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.

Team LinkedIn Profiles (if available)

Development Status 📖

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.

Maintenance Responsibilities 🔩

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.

Overview

  • 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).
  • DOT %: Percentage of Total Costs to be paid in (vested) DOT (>= 50%)
  • 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.

Future Plans

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.

Additional Information ➕

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.