gitcoinco
Data migration from existing bounty types
User Story: As a contributor I want the bounty explorer to reflect the new naming conventions holistically So that there is consistency with what im looking at/for
Acceptance Criteria
GIVEN I have bounties that fit the exisiting bounty types - Traditional, Cooperative, or competition WHEN i deploy the new bounty creation workflow that includes the trimmed down bounty type list THEN any existing bounties that = Cooperative or competion should reflect "Multiple" AND this should reflect on the bounty explorer filters
Notes: We will need to run this on deployment
Also need to include migration for the "never_expires" flag for existing bounties.
The question below refer to what we store in bounty_type in the DB?
Currently in production we have: - traditional - cooperative - competition
What shall we have in the future? Option A: - traditional - cooperative (use this for "multiple" project type from now on) - competition (we do not create this type any more ...) Option B: - traditional - multiple (and rename the bounty type from cooperative or competition to multiple) Option C: - traditional - cooperative (not used any more for new bounties) - competition (not used any more for new bounties) - multiple (use for new bounties)
I would suggest option C, as it does not require updating old bounties (which makes a rollback possible - worst case scenario of course), and we handle the new multiple bounty type in the queries and in the UI.
Handling of project types: - in the BE: - traditional - cooperative - competition - multiple - in the FE: - traditional - multiple (which contains cooperative, competition, multiple) -> we can migrate cooperative & contest to multiple later, but this cannot be undone. Keeping it at the moment in case we need to roll back (worst case scenario).
The only thing that needs migration is the 'never_expires' flag. As script to set that flag for bounties with an expiration dat far into the future exists: determine_bounties_never_expires_field