Grantmaster

[Zaniyar]

Project Abstract

GrantMaster is a comprehensive web application tailored to managing grant applications and deliveries for the W3F Grants Program, leveraging data from GitHub repositories. The primary aim is to streamline the grant management process for the Web3 Foundation grant committee, providing an interactive and user-friendly interface for better navigation and data management. GrantMaster encompasses a range of components, including an efficient crawler for data extraction, a REST API for data access, and a visually engaging frontend. The application is built to support transparency, ease-of-use, and a seamless transition from the existing system, bolstering the growth and development of the Dotsama ecosystem.

Grant Level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application (Apache 2.0).
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[randombishop]

Thank you for this application @Zaniyar. I am glad that you decided to tackle that RFP.

One question about your approach: you propose a button to trigger the data reading and updating the database. But can you elaborate on how exactly this will work? Will it read everything again and search for differences and make the updates? Cause that could be pretty slow and under-optimal right? Or does it remember the last state and do some kind of git fetch/ git update and work on the diff? Also how does it manage PRs and actions like comments, PR approvals, etc.?

Also, did you consider having the update scripts callable through an API and have us add some github actions in the repos so that the scripts can be ran automatically when the repos receive PRs or merges? That way, we won't have to click buttons to update things. And could make the update scripts focus on the changes only, triggered by the github repo itself.

Please provide as many details as possible about how the data update scripts will work and include them in the deliverables tables.

Also, can you please add to the application:

• the programming languages and frameworks that you will use for the different components.
• a documentation for the database schema as part of the deliverables.

Thank you very much!

[Zaniyar]

@randombishop thanks for the feedback. I've gone ahead and added the DB schema to the proposal as TypeScript interfaces. It's a rough draft and can change when things become clearer during development, but I see this as a good starting point.

The tech stack, including use of Mongoose for dealing with schemas, is detailed under the "Project Details" section. Let me know if this meets your expectations or if you need any additional information.

I also appreciate the suggestion of a push-based system (GitHub Actions) over a pull-based one (manually starting the crawler). It does make the data syncing simpler, so I'm planning to roll with that. The idea is to have a configurable crawler that can selectively update specific applications or deliveries and can parse the data from GitHub Actions for incremental updates.

Does this approach sound good to you? If it does, I'll get the proposal updated accordingly.

Looking forward to your thoughts!

[randombishop]

Thanks @Zaniyar !

Yes, in your own words, "the idea to have a configurable crawler that can selectively update specific applications or deliveries and can parse the data from GitHub Actions for incremental updates." sounds very good to me.

Just add this to the deliverables then ping me and I will mark this application as ready to review for the rest of the committee.

[Zaniyar]

@randombishop thanks, I've made the following changes:

• I've added a chapter that describes the data synchronization approach
• I've updated the project's milestones to reflect these changes

Please have a look again when you have the chance.

[randombishop]

Thank you @Zaniyar !

The approach looks good to me now.

I have some final details to suggest to the specifications: the entities represented in your DB schema cover grants, milestones and deliverables; but not the actual deliveries and evaluations. Can you add these in your list of entities to make sure we are covering the full scope of the data to be parsed and loaded to the database. (It's ok if the definitions are not exact and will change as you implement, as long as the entity is accounted for and included in scope, like you already mention in that section.)

An optional good to have would be Github repositories too, the deliveries will often link to github repos and it would be nice if they were recorded in a structured way.

[Zaniyar]

@randombishop thanks for the suggestions. I've extended the interfaces with the following attributes.

• Grant interface:
  • applicationLink: string;: points to the application doc on GitHub
  • applicationDoc: string;: matches the content of the application doc
• Milestone interface:
  • githubPrs: string[];
  • deliveryLink: string;: points to the delivery doc on GitHub
  • deliveryDoc: string;: matches the content of the delivery doc
  • evaluations: Evaluation[];: i saw that for some of the deliveries there are multiple evaluations, hence I'm using Evaluation[] here

Also, I've added the Evaluation interface:

typescript
interface Evaluation {
author: string;
link: string;
doc: string;
}

I hope that this matches your expectations.
Regarding the GitHub repositories, I think we should just create forks of them on GitHub instead of copying into a database. That way we can update the forks in an easy manner. On the other hand, if we persist them manually it would make the syncing process unnecessarily complex.

As for recording the links to the repos, we can certainly do that. I've added codeRepos: string[]; to the Milestone interface.

Note that for the added complexity I slightly increased the expected FTE as well as the costs while keeping the rate and expected duration unchanged.

[randombishop]

Thanks for the update @Zaniyar !

Yes, I agree that recording github repos is simply for the links and not the data itself. We actually do fork all the repos in our organization so it could be good to keep the records in the database. FYI we also run a script to monitor github activity on these repos (commits, forks, stars, etc.) so the grant management app could be a good place to run these scripts, store this information and display reports; but no need to add it in current scope, could be something to add later on in V2...

Anyways, happy to go ahead with current version and tag this application as ready for review for the rest of the team.

[semuelle]

On hold pending committee review. We'll be in touch shortly.

[semuelle]

Thanks for the application, @Zaniyar. We got several applications for this RFP at the same time, and due to the nature of the RFP we wanted to take a moment to make sure we make the best use of the talent.

We would like to ask you to modify the application to fit into a Level 1 grant covering only the first milestone (or whatever combination of deliverables you deem wise). Based on the delivery of that milestone, we would then evaluate whether we want to proceed with the rest of the proposed roadmap. Would this be possible?

[Zaniyar]

@semuelle I understand. I adjusted the document with the changes I deemed neccessary. I moved the second milestone into the "Future Plans" chapter and updated the prices. Could you have a look?

[Noc2]

Thanks for the update. I'm happy to go ahead with it.

[keeganquigley]

Thanks for the changes @Zaniyar LGTM.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[semuelle]

Hey @Zaniyar, any updates on your milestone? Are you still working on it? Any issues we might be able to help with?

[Zaniyar]

Hey @semuelle sorry, it's taking me a bit longer than expected, but I'm still working on it. I'm confident I can deliver by the end of October. Does this work for you? thx

[semuelle]

Hey @semuelle sorry, it's taking me a bit longer than expected, but I'm still working on it. I'm confident I can deliver by the end of October. Does this work for you? thx

Hey @Zaniyar. It's probably easiest if you submit a pull request with the updated timeline. We have no reason to rush anyone, we just like to stay on top of things.

[Zaniyar]

Hey @semuelle here is the pull request: #2037 - I hope this works for you.