pitch: Extending Application Statuses in RoundImplementation

[0xKurt]

Inspired by a previous discussion (#11), I propose extending the application statuses in our round smart contract to provide greater granularity and flexibility.

Currently, our round smart contract utilizes a 2-bit system to store application statuses. However, as our platform evolves and new requirements emerge, it has become apparent that the existing status implementation lacks the necessary granularity and flexibility. Therefore, I propose extending the application statuses to a 4-bit system to accommodate a wider range of states and provide clearer information about the application's lifecycle.

In the existing implementation, the application statuses are defined as follows:

0: Pending
1: Approved
2: Rejected
3: Canceled

However, the usage of 0 to represent a pending application can be ambiguous and unreliable when relying on chain data. Additionally, it does not clearly distinguish between an absence of an application and a pending status.

I propose introducing an extended set of application statuses to address the limitations of the current implementation. Here's a suggested set of application statuses using a 4-bit system:

0: No application
1: Pending
2: Approved
3: Rejected
4: Approved, but Reapplied
5: Rejected, but Reapplied
6: [Additional Status]
n: ...

By introducing new statuses, we can better track the lifecycle of applications and provide more meaningful information to participants. The inclusion of "Approved, but Reapplied" and "Rejected, but Reapplied" allows us to differentiate between initial approvals/rejections and subsequent reapplications.

[lmcorbalan]

@KurtMerbeth What do you think about changing the bitmap approach?
e.g. Having a status property on the Application struct could make the code more readable, easy to understand and provide even greater granularity and flexibility.

[0xKurt]

If you run a round with hundreds of applications and you have to iterate over multiple applications to update their status, it is very gas consuming.

Using the bitmap just saves a bunch of gas. I agree on what you said, but it would be a really expensive approach. (Especially for mainnet rounds)

[lmcorbalan]

Oh I see! That explains it all, agree

[nfrgosselin]

@KurtMerbeth I'm supportive of expanding the scope of application statuses that the protocol can handle. I'm curious — would the scope of this AIP also include creating a standard set of application statuses? I'm torn between allowing the flexibility of customizable statuses with also wanting to preserve some level of data usability.

[0xKurt]

We def should have a standard set, else it will be messi to build frontends on top of it.

[codenamejason]

I agree, we should not allow for 'custom' statuses and use a standard set. A later AIP could address changes to any of the proposed status's.

[boudra]

@KurtMerbeth How would the reapplied statuses be used in practice? at the moment project application history is available to be queried, if a project applies to a round and they have application index 1, that application gets rejected, then they reapply with application index 2 that is accepted, this would be another application right? so you would end up basically with two applications:

• app 1: rejected
• app 2: accepted

With this information you know that the project was accepted in their second application, and this would be the source of truth, or are you thinking that we would update an application instead of creating a new one?

[codenamejason]

I like the idea of an organization @KurtMerbeth then the reputation is much more manageable by the projects/ideas under it.

[thelostone-mc]

I think that @lmcorbalan 's case is actually the "normal" case rather than an edge case for direct grants. It's very common for a direct grants program to have an open RFP (submit a great idea you want to build) and for projects to submit multiple applications/ideas for it.
The way I see it, the meaning of a Project depends on the context, for QF Round it represents the combination of Builder+Idea and on the context of Direct Round it is just Builder and the Application is the Idea. Who knows what it would mean on a third context.

@lmcorbalan @meg-fsc After reading that I see the validity of having multiple applications.
My only concern is that allowing a project to have different distinctly different applications makes things trickier in the following means:

• Tracking the history of an idea and how it's progressed over rounds becomes trickier. This I think is something we would want to track as a project. Each project should have its own lifecycle/history to track IMO.
• If anyone wanted to retrieve a project's application Id, assuming they know only know the project ID, they would have to go through all the applications and figuring out which is the right application might be trickier (we had this issue while @0xZakk was building out the sweepstake contract)

If reputation is what we are worried about (which we should), I do like exploring having an organization contract which maybe adds the layer of unifying reputation. This might be worthwhile exploring as opposed to having a project to be able to submit multiple ideas.
We'll take this into account when we review our design this week and make sure we account for this scenario.

[gravityblast]

I don't think we need another abstraction on top of the project. The organization with the reputation is already the Project itself, and instead of having multiple projects you have multiple applications. The application itself should have its purpose and description instead of cloning the current project snapshot. This will allow projects to update the application without having to update the project and then the application again. And projects can be updated without touching an application already submitted.

If anyone wanted to retrieve a project's application Id, assuming they know only know the project ID, they would have to go through all the applications and figuring out which is the right application might be trickier (we had this issue while @0xZakk was building out the sweepstake contract)

this would be the same if you have an org id, you would need to check all the projects and then all the applications.

I like the idea of having Orgs more than Projects, but mostly as naming, and it makes more sense!
But in @lmcorbalan's case they would need an Org, and then a new project every time they apply to a round.
Instead if we just have a project (or Org) and a specific metadata for each application would allow them to have a clear description of the project/org and a specific description for each round.

Moreover, I think having multiple applications or not should be an option of the contract, so round operators can decide if projects can apply multiple times or re-apply resetting their application status.

[gravityblast]

/cc @meg-fsc

[meglister]

Agree with this approach @gravityblast

[gravityblast]

In an ideal world, every project has just one status.

Having a clear distinction between Projects and Applications was a deliberate decisions we took when we decentralized gitcoin to avoid the same problems we had in cgrants.
In an ideal world actually Allo could apply to an Infra round with 2 applications: 1 to support zkrollups, 2 to support another chain. each application can receive votes and they have different descriptions, but the project and team is the same, because they need to bring their own reputation with both the applications.

[gravityblast]

/cc @KurtMerbeth @thelostone-mc @meg-fsc

[gravityblast]

I propose introducing an extended set of application statuses to address the limitations of the current implementation. Here's a suggested set of application statuses using a 4-bit system:

I think we could go on for ever if we try to support all the possible statuses that a round operator can use.
For this reason I think the used bits for the status should be an arguments of the constructor.
I propose to have a minimum of 1 bit (or 2), and the first 2 (or 4) statuses hardcoded in the system:

• 0 for undefined of pending
• 1 for approved
• maybe also 2 and 3 like in the current system

At round creation the round operator can add more as long as 256 can be divided by the total number of statuses.
If people build on top of the protocol I'm sure they need pending/approved and maybe rejected, but they don't need other round specific statuses.

[gravityblast]

/cc @KurtMerbeth @thelostone-mc @meg-fsc @boudra