Web: As a Gitcoin core developer, I want to change the logic around bounty states and expressing interest, so the data model is easier to work with and there are less bugs introduced.

[octavioamu]

User Story

As a Gitcoin core developer, I want to change the logic around bounty states and expressing interest, so the data model is easier to work with and there are less bugs introduced.

Description

Today we have some primary components of the system that manage the logic of the application, like:

Bounty states

• Open (bounty with anyone working, can have applicants)
• Work started (someone approved)
• Submitted (someone submitted work)
• Expired (bounty extended the limit time)
• Cancelled
• Done (someone got paid)

Bounty type

• traditional
• contest
• cooperative

Interest

• Pending: (true/false) and work plan
  
  
  
  • Today we use pending for 2 diff rules:
  
  
  • Permissionless bounties are pending false by default
  
  
  • If the bounty is Approval required the pending is true by default and then when the user is approved to work it changes to "false"
  
  

Permissionless or approval required
Just control the default of the pending flag

The logic is built on top of these elements:

• traditional: 1 worker approved to work, one get paid
• contest: Many worker approved to work, one get paid
• cooperative: Many worker approved to work, Many get paid

Bounty States Reasoning

It seems that original design of the bounty states for contest or cooperative bounties makes sense, as these types of bounties were to remain "open" by design (as to encourage as many contributors to come and do work, and also by the fact that the bounty supported more than one submission). The problem is each of these types of bounties behave differently from each other; contest and cooperative bounties don't have the same states as traditional bounties.

You can see the difference. On top of this, the logic behind expressing interest also contains loopholes that results in lost user data. This complicates the queries that are performed in five (if not more) locations:

1. how the states are managed within the dashboard groups
2. how the states are surfaced on the issue explorer via the filters
3. how the state appears on the the issue details page
4. how the logic of the interest state populates the issue details activity log
5. bounty limit

Solution

1. The harder solution is the do an overhaul of the logic around bounty states and expressing interest. This would mean minimal changes to the UI, and instead, an augmented data model that accounts for funder and contributor behavior.

2. The incremental solution is to implement design changes to each of the separate dependencies, and then slowly migrate all existing data model functionality to the new data model (essentially option 1 but with stop-gap solutions as a pre-solution as the big "move" occurs).

Dependencies

This is a list of the dependencies that will currently be augmented or fixed by changing the logic around bounty states as outlined in this ticket - on each individual dependency, stop gap solutions are provided.

1. how the states are managed within the dashboard groups (https://github.com/gitcoinco/web/issues/5080)
2. how the states are surfaced on the issue explorer via the filters (https://github.com/gitcoinco/web/issues/5174)
3. how the state appears on the the issue details page (https://github.com/gitcoinco/web/issues/5036)
4. how the logic of the interest state populates the issue details activity log (https://github.com/gitcoinco/web/issues/5173)
5. bounty limit (https://github.com/gitcoinco/web/issues/3782)

This list of dependencies can be worked on with smaller lift while this ticket encompassing the logic around bounty states will be a larger effort and will require a piecewise parallel migration.

[octavioamu]

@danlipert @thelostone-mc Guys feel free to edit/add/change informations

[danlipert]

Looks great! I think - interest need to have the current action "work plan" and we can stop using the activity to manage the logic in the UI. is the best solution as well.

[octavioamu]

@PixelantDesign @frankchen07 @willsputra

[owocki]

@octavioamu asked for my input here... so here goes..

i tend to think in terms of end user stories; could someone articulate why the current state is sub-optimal for end-users? do we have evidence of complaints from users here?

to me it makes sense that contest/coop bounties skip start work / submitted states (because... welll... they are open even if someone else is working on them). but i want to detach from my ego here (i built it this way back in the day) and think about this from first principles..

maybe we need to do a better job of communicating the why/what here..

[octavioamu]

Oh don't feel as "the decisions were bad taken" Actually the point is the system has grow a lot on services and needs, and when adding new features like Dashboard, hackathons, etc feels that some updates on the general logic are needed.

[owocki]

maybe breaking status into two states internal_status and ui_status would help... that way we can manage a consistent flow on the former and the user one seperately

[octavioamu]

yes, maybe that can be more easy to implement also.

[frankchen07]

discussion between dan / octavio / frank

1. setting up the bounty model in the models.py (to be discussed and hashed out)

2. write to the new model in all places where the old model exists

3. implementations move over in chunks (not all in sprint 19)

[octavioamu]

Pasting here the original issue since some stuff related to the removal of the interest was deleted

Today we have some primary components of the system that manage the logic of the application, like:

Bounty states

Open (bounty with anyone working, can have applicants)
Work started (someone approved)
Submitted (someone submitted work)
Expired (bounty extended the limit time)
Canceled
Done (someone got paid)
Bounty type

traditional, contest, cooperative
Interest

Pending: (true/false) and work plan
Today we use pending for 2 diff rules:
Permissionless bounties are pending false by default
If the bounty is Approval required the pending is true by default and then when the user is approved to work it changes to "false"
Permissionless or approval required
Just control the default of pending flag

The logic is built on top of this elements

traditional: 1 worker approved to work, one get paid
contest: Many worker approved to work, one get paid
cooperative: Many worker approved to work, Many get paid
Bounty states
The problem is each of this type of bounties behaves different from each other, contest and cooperative bounties doesn't have some state of traditional bounties and this complicates the queries groups on dashboard and the understanding of states of a bounty on the platform, and the actions needed from the funder side.

The states work started and submitted are good indicator of actions of a bounty, when a bounty is submitted the funder knows there is a PR to review and paid.

I understand this diff states on diff bounties types could be related to the need of showing the bounty as open in case of contest or cooperative, but we can solve the design problem without affection the logic of the rules. For example having states for UI diff than states of a bounty. Today we translate "open" to "ready to work" in explorer, maybe we need to have both "ready to work" and "submitted" for example in a cooperative bounty where people already submitted work. Or be more direct on the actions waiting from the both sides personas "Accepting submissions" is more clear of what I can do on that bounty if Im a contributor, and the state of the bounty "submitted" is more clear to the funder.

Other possible solution is adding states just for funders like "waiting funder" if fulfillments or new applicants to approve. This also will be a way to force the funder to reject the others applicants he doesn't want or payout the ones already submitted just to remove "waiting funder" state, this is currently another problem since most contributors are limited to apply (not to be actually working) on up to 3 bounties (I made a proposal about that limitation to be able to limit actually the work, not the application to work #3782).

image

Interest
The other problem is about bounty detail, we use activity + interest to display different actions. But if someone is stopped to work, the interest is removed, with that the action reference "work started" doesn't exist anymore, if the user applies again, then there is not relation between that action and the interest and that complicates the understanding of an application of that user since the plan will be attached to all his "work started" activities.

Activity should be created only when the interests is successfully
Activity need to be referenced by id with that interest so we can have a more stable way to display the information.
If the user "stop work" ( or is stopped) we shouldn't delete the interest.
work plans need to be related with the right activity or better, interest need to have the current action "work plan" and we can stop using the activity to manage the logic in the UI.
Today there are many checkers of diff elements to understand the state of a user application on a bounty as "pending" is used for 2 diff actions depending on the bounty type.
So we need to check if pending is false, bounty type rules, if there are others applicants, if there is a fulfillment on that bounty, if the fulfillment is from the same user and then find the right activity to attach the correct action buttons. This process is expensive and can easily introduce bugs on the UI, as today the common bugs we had seen are:

Repeated actions
Missing fulfillments (not rendered on the UI)
Wrong order of applicants
This is needed to be able to correctly implement the new design in bounty details #5036