RFE: Badge paths

[mairin]

A commonly requested feature is having a formal sequence representation for badges in a series. The sequence should have a particular order. Examples of badge series that exist today:

• Badge artist series (ex https://badges.fedoraproject.org/badge/apprentice-badge-artist-i)
• Badge milestone series (ex https://badges.fedoraproject.org/badge/baby-badger)
• Tester series (ex. https://badges.fedoraproject.org/badge/in-search-of-the-bull-tester-i)

We need a way to store:

• What series is this badge a part of
• What badge came before it, if any
• What badge comes after it, if any
• (Or simply which order # is the badge in the series, where the first is 1 and the second is 2, so on and so forth.)

This can help drive onboarding, especially where teams have mapped out badge paths to help a new contributor gain experience.

Related ideas along this line have been requested a few times, see:
#270
#204
#250

Some of the other RFEs request specifying how many {action}s you have to take to get the next badge. I don't think that is necessary and it makes it a harder problem to solve. I think simply storing what badge comes next, and having a section of the UI when you log in that displays the 'next' badges for the ones you've already earned so you know what badges you're closest to earning next would go a long way and would essentially solve the same problem.

We'd like to use badge paths in hubs too, and I think it makes the most sense to implement them in badges and display in hubs.

[mairin]

Some things I don't understand and would like clarity on:

https://git.fedorahosted.org/cgit/badges.git/tree/rules/ambassadors-sponsor.yml

So each badge has a list of attributes at the front. Is that where we'd put this? Can the attribute be empty or non-present? So we'd have these new attributes with example values(suggesting the name 'series' because 'path' might be overloaded):

series: Badger Artist
number_in_series: 1

Or would the yaml be the wrong place to store this?

If the yaml is the right place, and if these can be optional fields, then i think these other steps need to happen:

• update fedbadges to read in the new fields:
  • add them to the constructor, with a check to see if they exist since they're optional (somewhere around https://github.com/fedora-infra/fedbadges/blob/develop/fedbadges/rules.py#L73 )
  • add them to the db in the constructor, somewhere around here https://github.com/fedora-infra/fedbadges/blob/develop/fedbadges/rules.py#L120
• tahrir's db would need to be updated with the new fields. this would involve using alembic to do the migration.
• tahrir's UI would need to have components added to indicate series / series numbers for badges.