Concluding Fedora Badges ARC investigation

@t0xic0der I’ll be happy to volunteer to be part of the development team. I’m quite new and still trying to understand the various projects that constitute Fedora Badges as well as gradually going through their documentation. Can’t wait to get started :slight_smile:


Welcome aboard @idadel and thank you for volunteering!

Do visit the links mentioned in the footnotes of this post to quickly get up to speed about the system in its
current state and feel free to reach out on the Fedora Badges Matrix chat[1] for any assistance.

  1. ↩︎

I finally found the time to read through the ARC document. Thanks for all the work and for writing it down in a way that is easy to follow and comprehend.

Being relatively new to Badges myself, I lean on CPE’s expertise regarding suggested APIs and frameworks. I was already leaning towards a rewrite, yet the analysis of the current state of Badges has convinced me that it is the only feasible way forward.

One thing that made me scratch my head is the CM interaction [1]. Why would the Messages Consumer need to access Collection directly rather than through the Accolades API? It’s also the only interaction between entities not going through the API.

It’s been mentioned in the ARC and by various people here, but it cannot be stressed enough:

Document, document, document!

Lest we want to travel down this road again in a decade.

  1. Interactions possible — ARC notes documentation ↩︎


Hi @gui1ty,

One thing that made me scratch my head is the CM interaction [1]. Why would the Messages Consumer need to access Collection directly rather than through the Accolades API ? It’s also the only interaction between entities not going through the API.

The Collection entity is nothing but a normal Git repository consisting of the artworks and related rules/conditions for awarding folks. As a result, interaction with the Git repository does not require passing through the Accolades API entity as any updates made to the Collection entity can be traced using the Git history. That is the reason why the CM interaction does not involve the Accolades API entity and is probably the only one like that.

Totally! The roadmap[1] itself has like 5 occurrences of the word “document” so we couldn’t emphasize more on it.

  1. ↩︎


A good alternative for the CLI would be using the Rust language:
Click → Clap
Requests → Reqwest
keep YAML or TOML and use Serde to parse it

I’ve had a good experience using it. However, I understand that the other parts are in Python and this would be a new language for newcomers to learn. Nevertheless, there are many people interested in Rust, and it could attract more volunteers.

Again it’s just a suggestion so that we evaluate possible alternatives, the proposed stack is solid as well.

While there may be many people interested in using Rust, the number of people able/willing to package Rust libraries for Fedora appears to be limited. See this message and the replies on the devel mailing list for example.

I mentioning this to take into consideration, not as an objection on using Rust or any other language for that matter.

I would need more information on your proposal in order for me to be able to make comments on it. Do you propose to have the CLI written in a different language and the applications that the CLI interacts with in a different one instead of having a monolithic approach towards it?

Not just that it would be a learning curve[1] for folks but keeping in mind that the entire infrastructure has applications and services written in Python, it would slow down the progress significantly for an initiaive[2] that is already expected to take a long time to complete, to compensate for the learning time. Attracting new volunteers at the cost of participation from the existing ones (from within the Fedora Websites and Apps team, the Red Hat Community Platform Engineering team, the Fedora Infrastructure team etc.) does not resonate with me.

Here again, I understand (and appreciate) your enthusiasm but I got to see what makes it convenient for all (read, most) of our stakeholders to contribute and be a part of the Fedora Badges system. As it stands, we would like to hand as many hands on deck as possible and I would like to put my bet on the hands that are currently available and contributing so far. Echoing @penguinpee’s statement, this is something that can cause more issues down the lines, should we have tools, projects, applications etc. that would necessitate their availability in RPM.

  1. which I personally do not mind ↩︎

  2. I should use this word sparingly before either @eocarrol or @amoloney scold me ↩︎

One thing we could consider is that after we get to the point of having a MVP and a plan to migrate from Badges 1.0 → 2.0, then we could look at expanding the developer tooling around the rewritten stack. I concur with other thoughts about picking up a new stack, but just because we don’t start with it now doesn’t mean we couldn’t revisit later, once we have something on a more solid foundation.