Bounty/Grant Submission AIP (AIP-005)

AIPs
,
1

Hey everyone, I’ve created a draft for an AIP regulating bounty/grant submission, as well as directing a location on Discourse for the technical discussions regarding that bounty/grant. I’ve uploaded the AIP to Github, and am sharing the link below. We can discuss the details under this forum thread.

I also think about some features that we can add to this AIP but I’m not sure, so please make your comments.

  1. We talked about some bounty/grants that are relatively big so they will have milestones. We can add something to track the milestones in that document and ask the bounty/grant workers to update this document with each milestone. We’ll have the record of each milestone, and someone else come and pick up where it’s left if the bounty/grant worker stops continuing the bounty after a milestone for some reason. However, we cannot call it completed and I couldn’t decide how to label a half-completed bounty/grant in the bounty board.

  2. We may add a document that’s listing all the completed bounties/grants in the main project repo. When completed, summary of each bounty/grant can be added to that document, along with the proper keywords. It may make things easily findable in case there’re hundreds of bounty/grants in that folder.

  3. We can add a e-signature system on Github. The bounty/grant would be completed if it gets 3 out of 5 GBC member signatures. However, this can have bad outcomes such as GBC members approving a bounty/grant completion without knowing the details, so I believe each bounty/grant should be verbally approved in a GBC meeting. Even if we were to consider using an e-signature system, I would propose instead converting each bounty/grant into a smart contract. I believe this approach would be a worthwhile effort.

Please review the AIP draft and think about my ideas. Since we officially started developing Project Quiver and I would like to have all the bounty/grant submissions in the same format and proper location, I think we need to act fast on this one. We can discuss your ideas under this forum thread. Looking forward to seeing your feedback.

2 Likes
2

Is this where the Information Note would live? Inside the Bounty/Grant Unique ID folder?

info-note-location
info-note-location1920×1081 77.8 KB

2 Likes
3

Yes, this is what I have in my mind! I think one unique folder for each bounty will keep everything tidy, since all the deliverables will be there with the Information Note.

I’m not sure about the bounty/grant ID though, have we ever discussed something like that?

4

Thank you, Alperen.

I think this is a good AIP and will help us have clear guidelines for organizing all of the bounties and grants. A few points/questions:

  • Should we include a link to any templates mentioned?
  • For the sake of not having a huge dump of information on Discourse all at once, should we enforce a bi-weekly progress update on discourse? This could help the worker with documentation. Not sure if this is added work. I am just worried we’ll have someone working on something for a while and then try to cram all of their documentation at once?
  • How often will we expect the workers to make updates to their github? Will we just monitor that to get an idea of how they are progressing?

Regarding the additional features:

  1. I don’t know of a good way to track milestone progress. I guess there can be an additional .MD file in the github repo that is detailing the progress. Seems like the easiest way to keep track. Maybe an inclusion to the AIP can be some kind of milestone tracking template?
  2. I think showing that on the main repo is a good idea. We could also include a table of contents that just shows the bounty # and title.
  3. Yeah I think for now that can work. In the future I think there is other ways to automate it but that might be outside the scope of this AIP?
1 Like
5

Should we include a link to any templates mentioned?

I thought it was easy to find the draft from the link, it’s my mistake. Agreed, link attached.

For the sake of not having a huge dump of information on Discourse all at once, should we enforce a bi-weekly progress update on discourse? This could help the worker with documentation. Not sure if this is added work. I am just worried we’ll have someone working on something for a while and then try to cram all of their documentation at once?

I don’t think there’ll be an information dump on Discourse since the formal submission will be on Github. The technical discussions will be on Discourse when needed. Let’s say the bounty/grant worker has two options for landing gear and he wants to get some ideas from the rest of the team. He’ll write it down on Discourse and the discussion will be logged there.

For the sake of popping up on search engines, we can also copy the final submission Information Note to regarding Discourse forum thread.

We can encourage the workers to post updates on Discourse about their progress but forcing it may be an extra work.

How often will we expect the workers to make updates to their github? Will we just monitor that to get an idea of how they are progressing?

I imagine Github submission as the final submission for the whole bounty/grant. When completed, the worker will post the Information Note and the deliverables on Github and request a review and approval. Everyone has different workstyles, I don’t want to force them to comply one working technique. At the same time, if the bounty is relatively big, it’ll have milestones, which will require submissions for the work done on before that milestone (also referring to my discussion #1 here). I believe it’ll keep things on track and won’t let them drift too much.

  1. I don’t know of a good way to track milestone progress. I guess there can be an additional .MD file in the github repo that is detailing the progress. Seems like the easiest way to keep track. Maybe an inclusion to the AIP can be some kind of milestone tracking template?

Agreed, at the beginning of each information note there can be milestones section, in which you’ll list your milestones for that bounty. For each milestone submission, you’ll have to fill the chapter for your milestone and merge it to the rest of the doc. I can modify the template that way.

  1. I think showing that on the main repo is a good idea. We could also include a table of contents that just shows the bounty # and title.

Agreed, makes perfect sense, it’ll be great if we do both actually.

  1. Yeah I think for now that can work. In the future I think there is other ways to automate it but that might be outside the scope of this AIP?

Agreed, I just wanted to clarify if you guys want to integrate the e-signature feature on Github. The rest was just my opinions on the matter, as a future reference.

Thank you Erick for your feedback, those were really good points. Please let me know if you disagree on any of them!

6

I think the reference information note that you created provides a lot of clarity to this process and would make it easy for someone taking their first bounty to get it completed.

Is there a good place for this type of document to be stored in the AIPs repository @sleety?

1 Like
7

We could maybe create a new AIPs/templates repo. It could store our (currently loose) AIP template & AIP vote text template as well.

Maybe it would be better to allow people to just clone a project structure so they don’t misplace anything, and inside this project is the InformationNote.md template? :thinking:

2 Likes
8

CleanShot 2024-11-25 at 08.32.36@2x
CleanShot 2024-11-25 at 08.32.36@2x412×206 2.4 KB

  1. Discourse Forum Integration
    For each approved bounty or grant, a corresponding Discourse forum MUST be set up, mirroring the GitHub folder hierarchy for consistency.
  • How do think we can mirror the folder hierarchy in Discourse? Would we need to update our discourse categories to have a new category for each Project?
  • Each forum SHALL use proper tags for the bounty or grant.
  • So, using Discourse’s terminology - are you imagining this would look like:
    Project Category
1 Like
9
  1. Information Note Requirement:
  • After submission, the Information Note SHALL NOT be modified, excluding the status section.

Would adding ‘Remarks’ to the document not contradict this? Do you mean "the Information Note SHALL NOT be modified by the applicant?

From the GBC’s perspective, what if the scope of the grant changes? Would they not be able to update the new deliverables? Would they have to append all these changes to the information note? Or would all this just go in “Remarks”

1 Like
10
  1. Structured Folder System:
    All deliverables SHALL be located in the designated folder.
    • All pictures MUST be placed in a folder named “picture”, under the bounty or grant folder. This will help viewing other main deliverables easily.

I would prefer a separate /assets folder at the same level as /AIPs, with a new folder for each AIP e.g. /aip-5

Like the way EIPs are structured here:

CleanShot 2024-11-25 at 09.32.48@2x
CleanShot 2024-11-25 at 09.32.48@2x832×780 27.3 KB

1 Like
11

AIP needs an extra --- to format the table correctly (e.g. dao-aips/AIPs/AIP-004.md at patch-1 · alperenag/dao-aips · GitHub)

Done!

How do think we can mirror the folder hierarchy in Discourse? Would we need to update our discourse categories to have a new category for each Project?

As far as I could see, we can create sub-categories on Discourse, so a folder hierarchy is possible. While each project will have a category and sub-categories, each topic will be using the shared tags, making it easy to find all the topics on one subject.

So, using Discourse’s terminology - are you imagining this would look like: Project Category

I wanted to mean each Discourse topic shall use proper tags, sorry for confusion. Made the adjustments for Discourse terminology!

12

From the GBC’s perspective, what if the scope of the grant changes? Would they not be able to update the new deliverables? Would they have to append all these changes to the information note? Or would all this just go in “Remarks”

Actually I do not want any bounty/grant info note to be revisited after completion, since it may create compatibility problems between different parts & damage the accountability. If a landing gear design is faulty on one aspect and needs to be revisited, there’ll be a new bounty/grant referencing the old one. It’ll be stated in the ‘Status’ section.

Would adding ‘Remarks’ to the document not contradict this? Do you mean "the Information Note SHALL NOT be modified **by the applicant** ?

The remarks section is for the bounty/grant submission also, making it essential for the completion of the work. It’ll be like a evaluation of your own work, filled by you. However, I believe I couldn’t clearly define the submission, what I wanted to express was the final submission for review. Changed that part a bit and integrated the “GBC creating the github folder and info note template” idea, so I hope the new version clears any question mark.

1 Like
13

I don’t have a strong case against this, so I can make the change. However, I feel like this setup might be easier for everyone involved. The bounty/grant worker can quickly access their folder, and viewers can easily see all the related assets in the same folder. Is there something that I’m missing? lol

14

Besides the last discussion, I made all the modifications that we talked about, and made some adjustments to the overall flow. There’s even a diagram showing the flow chart, particularly for @errrks.eth . So I’m kindly asking for everyone’s review again, hoping to push it to sentiment vote this week!

4 Likes
15

Thank you for the updates!

image
image1035×691 62.2 KB

For the chart, I think the Discourse topic should be created by the person submitting the grant. Was there a reason you wanted it created by the GBC?

1 Like
16

Yes, the idea is to follow the same folder structure with github, which will be created by the GBC. It’ll be harder for the individual to assess that one, especially since the github folder structure is created by GBC.

1 Like
17

I would also prefer that the discourse topic is created by the person working on the grant.

Also:

  • For each bounty or grant, the GBC MUST create the aforementioned folder and provide the link to the bounty/grant worker.
  • For each task, the task completer MUST create the aforementioned folder.

If people have to create folders for tasks anyway I think they can also create them for the grants and bounties. If its not up to standard it will not be merged. The GBC can provide the hierarchical structure to the worker in case of acceptance of the bounty/grant.

On a personal note, I think the caps MUST, SHALL, SHOULD etc. disturb the reading flow, but I understand why its there.

2 Likes
18

The first motivation is the need of an information note template. The information note will have the bounty/grant application document and we don’t have the application form in that format, so the information note template will be created by the GBC.

In addition, task completers and grant completers won’t always be the same people. We’re expecting all the task completers to be aligned with the project whereas it’s not mandatory for the bounty/grant completers. A grant completer may not have any idea how that project operates as long as he has all the inputs and successful outputs for their study.

Combining two aspects, it makes more sense to me for creating the folder through GBC and placing the information note to be filled in that folder. For better organization and documentation, I’d like to keep it as is.

I’d like to have @sleety and @Benjamin’s decisions on those words written as “bold” since they’re the main AIP editors, I can modify them as they want.

2 Likes
19

I wouldn’t want to deviate from the RFC 2119 guidelines as they are tried and tested at this point.

I agree it’s sometimes difficult to read them (and even harder to write) but it does force authors to think clearly about outcomes. It adds greater specificity and clarity to their AIPs, imo we should keep it :slightly_smiling_face:

4 Likes