We can totally use the context that you have gathered around the Fedora Badges system while working with it all these years.
Coming to the badges design template implementation part, I think that we still have a long way before we get there. That, of course, does not necessarily mean that folks cannot work on it alongside the foundational UI/UX design and engineering work - in fact, they are encouraged to do so. That would only help us to be able to swiftly plug in the work and test the compatibility of it all when we reach somewhere around Step 7 and Step 15 of the proposed roadmap.
I cannot emphasize enough how important the documentation part is - to a point that I seem to have explicitly stated it being one of the outcomes of multiple roadmap stages, as you have rightly pointed out. I like to think that the stronger and more comprehensive documentation we have, the more we empower our contributors to partake in the process of building the system with us. We really appreciate your assistance in strengthening our documentation.
Nuxt is used for SPA’s, it only turns into static if the option is turned on. It’s used more for it’s file based routing and conventions/configs. Vuetify can be used alongside it. A more flexible alternative would be TailwindCSS.
I don’t know if this is something that I just misheard or totally imagined, but I don’t see Discourse listed in in the list of proposed technologies. Discourse has a badges feature that has been neat to engage with on other forums I check out.
Are there plans to integrate Discourse into the new badge system? Is it too complicated or not worthwhile enough to add it into the mix?
While the Nuxt’s SPA mode can be helpful in auto-generating the routes, structuring the project in a standard manner, provide with a baseline scaffolding, auto SEO improvements etc. with a batteries-included approach, it would also limit the flexibility of doing them all the way we see fit.
As I mentioned before, we are still open to the choice of component libraries. I, for one, am still a bit sceptical about Vuetify because we plan on using exclusively Vue 3 with Vite here + 100% composition API and the last I heard, Vuetify had the Vue 3 support still in its infancy.
Let us find a component library built atop Tailwind CSS rather than using it as-is to keep ourselves from making the frontend a big challenge. Fedora Badges is already a complex system having around 6 internal and 4 external entities so it would be unfair to assign all the skill points to just one thing
One thing that we wish to achieve with the remake of Fedora Badges is to provide some semblance of a system that other FOSS communities can get inspired from and extend from. The fact that having our systems bound to third-party service that is not managed by our infrastructure and engineering community just puts me off. I mean, if the folks actively working on developing the system have limited access to what happens there (and how), we cannot empower new contributors to participate even if we have all the intentions to do so. These were my ideological reasons.
Coming to my more technical reasons, the badges implementation in Discourse, leaves a lot to be desired. There is no proper implementation of leaderboards and I am not sure if folks can manually add new badges into the system and award them as they see fit. Surely, we can make efforts to add those things but it would be a lot of bending Discourse to fit our purpose (difficult) than to make something which natively has our purpose (easier). Although, if we follow up on the experiment that @mattdm did[1], we totally can add viewing of badges here as a “nice-to-have” goal.
Note: I would be unavailable for the discussions during the weekends. See you folks on Monday.
Discourse is open source software, and has a pretty flexible plug-in system. I can see this objection were it proprietary software, but that’s not the case. Why not leverage existing open source infrastructure where we can?
We’ve been bitten by trying to go it alone on community infrastructure projects before — I love the idea, but if that’s the plan let’s make sure we have a sustainable approach.
That’s not quite true. Maybe not “proper”… but not far off.
The user list serves as a leaderboard over different periods — here, for example, for “Likes Received”: Fedora Discussion received. It doesn’t do badges, but could be extended to.
There is a new thing, “Discourse Gamification”, which is specifically to make leaderboards. Discourse Gamification - plugin - Discourse Meta. This also does not currently work with badges, but it’s on the upstream roadmap.
That said, Discourse certainly isn’t a complete solution. Most of the component projects you’ve listed above would still need some separate existence…
It could provide a leaderboard and end-user interface for seeing your own badges and those of others.
It could also serve as the authoritative database of awarded badges. [1]
With some more work, it could also provide a workflow for awarding arbitrary badges. [2]
On the other hand, we’d still need something separate for:
The message bus consumer and rules engine
Time-based scripts
QR codes and magic links
And, like the who-has-the-badges database, it could hold the authoritative images and descriptions, but I don’t think that’s really best.
There is also the badge-path thing I’d like to have, and that might be harder to fit in. I can see some ways to make it work, but a dedicated UI would be easier.
The easiest way I can see to do this: a special category where people could post in per-badge topics, which would create message-bus notifications which would feed back into the system… ↩︎
We most certainly can have some kind of integration between the Discourse platform and the actual Accolades API entity, so folks can see the badges they have acquired (and those of others) from within the Discourse interface. The other entities, as you have rightly pointed out, would have to be separate projects serving their purpose that this interface can feed off from.
The badge path, for one, is something that might get introduced in the future in the Discourse Gamification plugin but it’s uncertain right now if it would. As a result, I think having a read-only integration (like we do now) would be a good start for this “nice-to-have” feature which we can, of course, expand to adding new badges, awarding contributors and much more such actions.
One advantage of using it would be that our stack would be the same as the Websites and Apps team, and we could take advantage of the components’ library being built and keep the look and feel uniform across the projects.
@t0xic0der et al. thanks a lot for the very detailed analysis. I have only read the information/discussion in this thread so far, but I will go through the documents mentioned in the footnotes as well.
The conclusion to rebuild rather than refactor confirms opinions that have been voiced before. In particular I talked to @erolkeskin quite a bit about revamping badges before. Unfortunately he didn’t make it to our kick off meeting in December, but I’d really like to hear him chime in as well. I will give him another shout out by e-mail as well.
Since I’m not a developer, I will stay out of the discussion on APIs and frameworks. I would like to volunteer for the implementation and documentation part, having experienced first hand how daunting the lack of proper documentation can be.
I might be able to provide more feedback once I’ve read through all the documents. I’m still coming out of year-end hibernation.
@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
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.
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.
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.
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.
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.
