So we investigated Discourse to confirm if it is worthy of being the Fedora Badges frontend

Project Discussion
, ,
1

Yes, we did.

In the wake of the vast community support for the use of Discourse as the Fedora Badges frontend and the fact that now both Ask Fedora and Discussions would now merge into one unit, we pretty much had to. Please note that it looked like an “everything looks like a nail when I have a shiny new hammer” case when I started off looking into this, but when I delved deeper into the Discourse software and the studies that @mattdm has done regarding this - I started getting more and more creative ideas as to how we can bend Discourse to suit our needs. So what did we end up finding?

TLDR[1]

Add some convenient-to-make changes here and there, and Discourse should be worthy of being the frontend for the Fedora Badges system.

NIWTRTLV[2]

As Discourse is a flexible open-source software with support for custom community-made plugins and the fact that we have a managed infrastructure subscription for the same, it really depends on how willing we are to embrace the new frontend interface. It comes down to not just engineers/designers/sysadmins from within the community and those from the Community Platform Engineering team - but also to the entire community who would be using this system down the line.

Investigations performed…

Being an annexure to the original investigation[3], this functionality, for the most parts, was treated as something which is nice to have. It took a team of one around a couple of weeks of slow inspection to get to the conclusions we have reached. The treatise can be found here[4].

Starting interactions…

The experiment[5] integration[6][7] of Fedora Discussions with Fedora Badges was not only successful but it also brought these badges to the forefront and a part of active discussions. No longer would the acquired badges be left behind gathering electronic dust, but these now can be (and arguably, have been) set as custom titles and the top three selected by the users can be flaunted about in the user card. Here’s how I imagine certain discussions to go in this forum when folks have these set up.

  1. After seeing that @jakfrost has a “Nest With Fedora 2022 Attendee” badge…

    image
    image768×73 9.7 KB

    AD: Hey, I saw you attended Nest With Fedora 2022. Did you happen to attend that $(ARBITRARYTALKNAME)?
    SS: Oh yes, I did. It was pretty fun and I got to learn a lot of new things too. Did you know that $(ARBITRARYFEDORAFACT)?

  2. After seeing that @spot has a “In Search of the Bull (Tester I)” badge…

    image
    image757×67 8.94 KB

    AD: Hey, that is a really shiny badge “Tester I” you got there. Do you mind telling me what $(ARBITRARYFEDORACONTRIBUTION) you did to get it?
    TC: Of course not. So first you do $(ARBITRARYFEDORACONTRIBUTION), then you do $(ARBITRARYFEDORACONTRIBUTION) and then you get the badge!

  3. After seeing that @riecatnor has SOOO MANY badges…

    image

    AD: Hey, you have so many shiny design-related badges. I would like to start contributing to Fedora Design but I don’t know how I can…
    MN: Not a problem, let me onboard you to the team. Join $(ARBITRARYFEDORACHATROOM) and attend our meetings on $(ARBITRARYMEETINGROOM)

This is just scratching the surface about the types of interactions made possible with the integration but in the larger scheme of things, folks can expect the following to happen.

  1. New contributors getting inspired from the badges[8] received by someone else, and understanding where they can start with their contributions.
  2. Existing contributors actively finding new places[9] to put their efforts into and discovering new avenues of participation to earn cool shiny badges.
  3. Existing contributors trying to level up[10] their badge path to gain an edge over their fellow contributors in a friendly contribution-based competition.
  4. All contributors engaging in conversations[11] around badges, and the scenario that led them to get those - which can lead to a greater sense of bonding.
  5. All contributors setting a certain badge as their custom title to mark an occasion[12] (say, Fedora Week of Diversity, Creative Freedom Summit etc.)

The move of having Discussions f.p.o. as the frontend for the Fedora Badges system, not only relieves our contributors from building yet another frontend from the ground up but also helps them focus more on the parts of the system that needs more attention, i.e. the backend. The fact that this involvement makes Badges a very involved part of the community and its discussions, just happens to be an added plus that we can take advantage of.

Technically speaking…

image
image901×501 12.1 KB

In the internal entity chart, the Discourse frontend can be a drop-in replacement for the Liberation entity[13]. The remaining parts would, more or less, stay the same as we still want the Database entity to be the “single source of truth” to all the entities involved in the Fedora Badges system. As it stands, the interactions for the proposed Discourse frontend entity would be pretty much the same as that of the Liberation entity[14] so the internal workflow would not change much from the one proposed previously[15]. This is an excellent result as this helps dedicate the efforts put in by the contributors to the parts of the system that could really use their attention i.e. the entities that constitute the backend like Accolades API entity, Messages Consumer entity, Accolades CLI entity, Database entity and Collection entity.

Please note that this does not mean that the frontend side of things would involve work. Owing to the fact that the current catalogue of badges on Discourse[16] leaves a lot to be desired, it is something that would require frontend designers and engineers to rework the same and to make it look “fedorable”[17]. The leaderboards (each for weekly, monthly and all-time) have to be implemented as well so even these require assistance from the folks who are well-versed with the frontend technologies but a lot of these functions would be streamlined as we would not be creating things from the ground up and simply build upon an already-established and well-documented Discourse plugins ecosystem. The platform makes use of HTML, CSS, and JavaScript for its frontend while Ruby for its backend, as mentioned in their repository[18].

Backup plan

We can always make the current integration work with the newly created system, just in case the suggestion to utilize the Discourse frontend is not accepted by the community or if it proves to be too difficult to implement. By highlighting our badges on the Fedora Discussions forum, using them as custom titles, and putting them on the user cards, we can develop our own frontend while making sure that they are not left behind gathering electronic dust. Please note that, in this case, the integration would be deemed as a “nice to have” feature and not as a “needed” one to ensure that the more important parts are looked into first.

So what do you think?

This is when I stop speaking and open myself up to what you folks have to say. Please answer the poll with your preference and help us understand your choice by commenting below. As this decision would lead to us, paying more attention to either of the parts on a branching road, I strongly recommend following up your choices with feedback and counting for those choices only which were explained. The options marked with [NEEDED] are more likely to be implemented on priority while the options marked with [NICE TO HAVE] are likely to be implemented at later stages or when the situation requires them to be implemented.

What should be our approach towards building the frontend for the Fedora Badges system?
  • [NEEDED] We should build our own frontend from the ground up for the Fedora Badges system.
  • [NEEDED] We should have Discourse as the primary frontend for the Fedora Badges system.
  • [NICE TO HAVE] We should build our own frontend while having integration with Discourse for the Fedora Badges system.
0 voters

If you have reached this part of the textual content, I would like to thank you for spending your valuable time reading this detailed analysis. Please feel free to reach out to me or comment down below if you have any questions and I would be glad to be of assistance.

  1. Acronym for “Too Long Didn’t Read” ↩︎

  2. Acronym for “No I Want To Read The Long Version” ↩︎

  3. https://fedora-arc.readthedocs.io/en/latest/badges/index.html ↩︎

  4. https://fedora-arc.readthedocs.io/en/latest/badges/discourse_integration.html ↩︎

  5. A magical one, if I may add ↩︎

  6. Go comment under this thread if you haven’t already to be a part of this experiment ↩︎

  7. ↩︎

  8. Folks, who are new to the community, are mostly at a loss of where they can contribute and it is better to have something pique their interest in a natural manner than having stuff assigned. ↩︎

  9. In a community as vast as Fedora Project, discovering new SIGs, workgroups and teams organically can be difficult - unless something lucrative shows up and incentivizes folks to participate there. ↩︎

  10. The leaderboards and rankings are there for a reason and it helps mark out members who have been contributing extremely well and inspiring other members to do the same as well. ↩︎

  11. In a community where folks meet each other over textual conversation and video conferencing platforms to serve a purpose, it is nice to get a reason to have a water cooler chat, every now and then. ↩︎

  12. I am drawing parallels to a run-of-the-mill social media trend here as it really helps make people aware of a certain event or occasion happening so that even they can participate and contribute in it. ↩︎

  13. https://fedora-arc.readthedocs.io/en/latest/badges/prop_rewrite_entities.html#internal-entities ↩︎

  14. https://fedora-arc.readthedocs.io/en/latest/badges/prop_rewrite_interactions.html#la ↩︎

  15. ↩︎

  16. https://discussion.fedoraproject.org/badges ↩︎

  17. We should really consider having this trademarked if we haven’t, you know. ↩︎

  18. ↩︎

5 Likes
2

Gosh, I’d love to be a fly on the wall when @mattdm reads this. I’m sure he’ll be delirious. And I’m not referring to Covid (all the best @mattdm). :wink:

I’m a bit torn apart. On one hand I really like the idea of integrating badges into what is to become the primary meeting place for Fedorians. Apart from that it saves some work, I like the idea of flashing your badges as some people do on their Wiki page. After all, these are your badges and you should be able to take them with you, show them off.

On the other hand, having its own frontend would make Badges an exportable, stand alone product. A bit like what Mozilla tried to achieve when they started out.

How about adding a fourth option to the poll?

[NICE TO HAVE] We should have Discourse as the primary frontend for Fedora while making sure Badges can also be used without Discourse using its own frontend.

Thanks for the investigation once more @t0xic0der[1]

  1. Once the new Badges is live, I will propose a badge for 10+ footnotes in an article. I imagine an octopus with a sticky note in seven of its limbs and a pen in the eighth. :laughing: ↩︎

4 Likes
3

Which one of the following, @gui1ty? Tell me please before I get fired LOL.

image

I like to think that we should be able to develop the Accolades API and document the endpoints in such a way that interested folks should be able to hack something up that lets them export Badges and show them off, in a place of their choosing.

Unfortunately, that would stretch the teams involved in making these happen pretty thin and the last thing that we would want to do now is to put work on the shoulders of folks, who would already be engaged in the project for a period of at least 12-15 months. Not to mention, we would have to add one more entity in the system which would state actions received from the external entities, to the Accolades API entity - with the current ones being the Liberation frontend entity or Discourse frontend entity and the Accolades CLI entity.

That definitely sounds like the kind of badge, I would like to have.

(Thinks)

Wait a minute…

1 Like
4

LOL — thanks!

@t0xic0der This looks amazing. It’s going to be a little while til I have enough free brain-space to digest it properly and respond. But thanks for looking into it so thoroughly.

More soon, I promise :classic_smiley:

3 Likes
5

Yeah, if Discourse can be leveraged for the functionality, no reason to reinvent the wheel.

1 Like
6

Hiya folks- I have some thoughts about this one :slight_smile: thank you @t0xic0der for your in depth review.

  • My personal feeling is that Badges on Discourse feel quite hidden and it feels like an add on to a forum versus a central part of Fedora’s culture (e.g. a unique website that we have visited and pointed to for 10+ years). While I think Discussion is a central and important part of our communication, Badges don’t feel visible to me here. ( I will note that I think the one plus side to this is it could draw more users to Discussion.) Badge related text next to someone’s name could initiate interaction, but I think it would be rare?
  • Having a unique URL and website for badges shows the importance of the project to Fedora’s culture as a whole. It is also a very fun and exciting way to show off the Fedora brand aesthetic that lies outside of our “products” pages or documentation. Discourse is nice and clean for what it is: a forum for discussion- but does not reflect the fun and friendly nature of badges. I think we could make some really fedorable, slick, and reflective of the new Fedora brand with a unique site.
  • When you dig into a Badges page for a user on Discourse, the text overwhelms the badge art (we have some room to enlarge the art, but not much), and as a whole- is not a great user experience for viewing badges, imo. I think it might require simplifying our badge style quite a bit in order for them to be readable which would create a lot of work for the badge design illustrators.

My thought is that using Discourse could potentially reduce effort on re-hauling Badges, but it will still take plenty of long term maintenance. It would certainly take a lot of effort on the badge design side to make them more compatible with discourse specs. Maybe the issues I see with mixing the styles and goals of Discourse and Badges can be addressed? Although I clearly have a strong preference, I would defer to those who are re-hauling and doing long term maintenance for Badges. In the end, if we simply cannot maintain a unique badges website long term, I would make my peace and work to embrace the new solution.

5 Likes
7

Hye Akash,

This is a good writeup. I’m not sure how to vote in the poll. Here are my questions and you’ll see why I’m not sure how to vote:

  1. Does Discourse provide an externally accessible API? E.g. so we could display a team’s bdge set in their docs page as an embed? (“Here are the badges we recommend you earn to join the Fedora Design Team.”)

  2. Does using Discourse preclude the oft-wanted / dreamed for feature of having badge paths or somehow linking badges together? Either a grouping mechanism (all the design team related badges), or tagging system (all badges tagged w newbie, or best a sequential system (first badge 1 > then badge 2 > then badge 3 and youve learned X skill set!)

  3. Could Discourse’s badges system be used as a backend for a separate custom designed UI? (related to question 1) Could we get best if both worlds / admin & maintenance for the backend from Discourse but the flexibility of a custom user experience at badges.fpo?

  4. Do we have any flexibility to customize how badges appear in Discourse? Can we move the menu item to be more prominent? Can we do custom CSS on the badge list page? Can we make a custom badges landing page and have badges.fpo point to it?

I share the same concerns @riecatnor has around the visibility and appearance of the feature in Discourse, so as a front end as-is i’m thumbs down but that doesn’t mean the backend is necessarily useless as part of the solution? And I also dont understand the customizability of the Discourse frontend (I was kinda anoyed with limitations in it whe we initially branded this shindig) so I’m not sure if it’s fair to write off completely, so I analyze on an as-is basis.

2 Likes
8

Huh. I have the complete opposite feeling — I feel like badges are kind of an “in the know” thing, where you have to go to a whole separate site to even see that you have one. That’s got its own kind of fun, but doesn’t feel as central as I think they should be! [1]

The Discourse integration is kind of hacky now but we could do a lot more. Having top badges better presented on user cards (click someone’s avatar) would be a pretty easy first step.

I’m not opposed to this (and it doesn’t necessarily conflict with making badges more visible and integrated into Discourse — we can do both!) but I kind of echo the same feeling I had to the first point: to me, a different site feels less like a showcase and more like … isolation. I think that if we do have a new, separate frontend, it’d be good for it to be at URL like fedoraproject.org/badges. [2]

Yeah, I did nothing to style or improve those pages. They’re designed for use with Discourse’s default badges, which just use a few abstract shapes (and repeat those!). See Discourse Meta for how that looks. We could change this to reduce the size (and amount!) of text, change the userlist on individual badges, etc. And similarly we can improve how they’re displayed on user pages (and as I said, the user cards, too).

  1. This is all fallout from not getting Hubs, but I’ll refrain from letting that make me depressed and move on… ↩︎

  2. I’m not opposed to moving Discussion under fedoraproject.org/discussion, for that matter. But one thing at a time! ↩︎

1 Like
9

Yes. It’s very, very good in this way. If you take basically any page, like https://discussion.fedoraproject.org/badges/246/apprentice-badge-artist-i and add .json, you get, well: https://discussion.fedoraproject.org/badges/246/apprentice-badge-artist-i.json

And, there are some administrative API calls here: Discourse API Docs

I don’t think it precludes it, but it doesn’t give it to us automatically either.

Badges can be in (one) badge groups (and there can be arbitrary badge groups). So we could use that to link them (although we probably actually want to use that for what the current Fedora system calls “tags”, which are bigger categories like Design.[1] Badges can also have a “type”, which seems to be hard-coded “Bronze”, “Silver”, “Gold” but might be extendable.

But I think to really have the dream feature, we’d need to do some work to add additional metadata.

Yeah, that should be doable if we would choose to go that route. And conversely I think we could also go the other way and make badges better integrated here even if we go with a separate site for the “primary” UI.

Im order: Yes, yes, yes, and… “yes, if that page is a customized version of https://discussion.fedoraproject.org/badges, but if we want to do more than that with fundamentally different features, we’d need to write a plugin, which we totally could do but increases the scope of the work”.

  1. Fedora Badges allows multiple tags per badge, which is a mismatch. But we don’t seem to have made heavy use of that. ↩︎

3 Likes
10

One potential concern that I have is that the badges system is currently an in house maintained thing and moving it to Discourse creates a new vendor/platform specific dependency on them that doesn’t currently exist. If something happens with Discourse (a shady buy out or the company abruptly goes under), then we could lose the badges or have to quickly build something like we already have but under much less good circumstances.

All that to say, I definitely welcome a better integration between Fedora badges and Discourse badges. I happen to like the current badges.fedoraproject.org site and think it’s pretty neat. Sometimes it’s a helpful and fun tool to look people up when I want to quickly reference where they’re involved in the project, etc.

I also hope we can continue to support QR code or links to acquire badges for events like SCaLE or Nest.

2 Likes
11

Currently tags are mainly used for two things:

  1. Categorizing badges for grouping badges on the user’s page
  2. Keywords for easy searching

Unfortunately, the second use is not applied consistently. Finding badges is therefore at times a hit and miss. I also feel these two use case should be separated. The category is defined when a badge is released. Keywords should be editable. Tags can currently only be added, not edited or removed in the UI.

That’s what I had in mind, among other things, when I wrote:

12

This is probably my lack of expertise speaking, but since Discourse is open source, couldn’t we take the whole operation in-house to continue using it if the company went under for whatever reason? Yes, they’re helping us by hosting and maybe doing some admin, but otherwise we could be doing that ourselves and development doesn’t necessarily have to stop either.

I guess my thinking is that if we’re concerned about putting badges under Discourse because the Discourse company might go under, then we shouldn’t have our main form of asynchronous communication with them. Put another way, if we can trust them with our whole forum, I think we can also trust them with our badges.

13

One q I forgot to ask:

What does the workflow look like, given needed artwork, to create a new badge on discourse? Does it handle the logic the current system does (eg grant all who are in x fas group or filed x number of tix a badge) or would it need to rely on special self-service badge granting links?

1 Like
14

I would like to see things a bit differently and say that with the integration in Discussions[1], interaction with the Fedora Badges system would become a lot more “organic” and “streamlined”. Let me go into further detail as to how it becomes so.

  1. The “existing catalogue present on a different location” approach, which dates back almost 10 years, is more akin to a “treasure chest”. It is something that people will pop open time every now and then, and show to other folks - but they cannot quite carry it along all the time. Maybe because it’s either too inconvenient to do so (the frontend located in a separate location altogether), it’s not needed right now (no events, occasions or awarding happening at the time or no leaderboards lookup required) or it’s difficult (read, unwieldy) to refer to the badges in an external conversation. As a result, the interaction with the current is critically limited.

  2. The “integration with the existing platform” approach, which I have recently presented the investigation for, is more akin to a “badge attached to your chest/backpack”. It is something that people will carry along all the time and will always be seen by the folks you interact with. Equipping a suitable badge as a custom title or having them on the user card has certain advantages as then when folks get involved in a conversation, they not only present their views but their equipment also speaks about where they are coming from. It is something I got inspired by the platforms like Reddit which have “user flairs”, making these badges 10x more useful.

Agreed! I admit that in its current state, the badges catalogue frontend[2] available on Fedora Discussions looks ugly and barebones but maybe that is kinda the point. @mattdm was able to set it all up in a (relatively) short time and with (relatively) less effort and we got that. The platform does its best to handle (most) complications and include (most) batteries out-of-the-box with the plugin system to ensure that the folks working on it are able to focus solely on the task at hand. Therefore, building something with a “fedorable” look and feel is very possible with its use, to the point that it would become (rather borderline) unrecognizable that it is indeed Fedora Discussions that we are in. Automatic redirects from the existing badges can be set up to point to that present on Fedora Discussions.

Say, for instance,

  1. Fedora Badges can be set up to point to Fedora Discussion
  2. https://badges.fedoraproject.org/badge/fedora-week-of-diversity can be set up to point Fedora Week of Diversity badge on Fedora Discussion

And many more similar redirects to ensure we have similar (if not the exact same) URL formats.

Here again, I would like to circle back to the point where I agreed with the fact that the current badges catalogue frontend on Discourse looks ugly and barebones. But at the same time, it is flexible enough for us to make it look like however, we want it to look like, as I have mentioned before. I do not expect any significant changes required regarding the badges artwork themselves as a result, as the styling of that page (and any other pages) can fall onto the frontend folks.

My thought is that using Discourse could potentially reduce effort on re-hauling Badges, but it will still take plenty of long term maintenance. It would certainly take a lot of effort on the badge design side to make them more compatible with discourse specs. Maybe the issues I see with mixing the styles and goals of Discourse and Badges can be addressed? Although I clearly have a strong preference, I would defer to those who are re-hauling and doing long term maintenance for Badges. In the end, if we simply cannot maintain a unique badges website long term, I would make my peace and work to embrace the new solution.

I suppose I could have been a bit more verbose but we are looking at something that would be clearly a non-issue. This integration would not (in a million years) require us to be really compliant with the Discourse badges specification and it would rather be the other way around i.e. making Discourse work the way we want it to. Also, the use of something batteries-included can significantly reduce the effort for both the short-term development and long-term maintenance but it would really be helpful if you help me understand the pain points, apart from the artworks[3].

  1. which has now arguably become the primary location for all our async conversations, in the wake of the Ask Fedora merge ↩︎

  2. https://discussion.fedoraproject.org/badges ↩︎

  3. because we can totally use our specifications and metadata as they are ↩︎

1 Like
15

Hi @duffy, hope you’re doing well!

@mattdm seems to have answered more of your questions[1] so I would address this part.

A picture helps explain things a lot better than thousands of words so here’s one

image
image1176×550 15.1 KB

As I have stated in “How to go about it?” section[2] of the ARC treatise about the Discourse integration, the only entity of the system that would be affected would be the proposed Liberation frontend entity. The remaining backend entities stay as useful as they have been (and arguably are) in the current implementation of Fedora Badges. This essentially means that we are pretty much in control of all the information that we have in our system and the only thing that gets added to the equation is the Discourse frontend, which would have to abide by the API endpoints that the Accolades API entity would be providing.

Regarding the frontend customization side of things, I personally think that we could use some more exploration on that front to understand to what extent we can customize things here. From what I understand, it should not be difficult or opinionated tooling but I suppose it would be best answered by the folks who would indeed be involved in making these things happen[3]. We would like to keep all doors open, just in case, it becomes too big of a hassle to make one small thing happen just because it is something that the Discourse folks never thought would become a problem or a requirement.

  1. but totally feel free to let know if there are things that require more attention or explaining and I would be glad to do so ↩︎

  2. https://fedora-arc.readthedocs.io/en/latest/badges/discourse_integration.html#how-to-go-about-it ↩︎

  3. or @mattdm if you would have ideas around it ↩︎

1 Like
16

Hi @vwbusguy, hope you’re doing good!

Please allow me to quote one of my previous answers to help save me some effort.

As I have mentioned in “How to go about it?” section[1] in the ARC investigation[2] about the Discourse integration, it is only the frontend that we propose on transitioning to that of the already widely used and arguably the primary place of all the conversation, Fedora Discussions. This essentially means that our proposed system is resilient enough to have every other information about “who received what badge and when”, the badge artworks (and related awarding rules) and the way these are to be interacted with, under our control. What we are proposing is for the Discourse frontend to become one of the (if not the only one) primary interfaces that interact with the Accolades API to get things done.

The proposal has been made only after we were able to confirm the reliability of these platforms with the corporate offering use over multiple years now. Basically both Ask Fedora[3] and Fedora Discussions[4] have been in use for a long time as a platform for our asynchronous support-based and community-based conversations respectively and for housing our discussion histories reliably enough to link back to them as and when we feel like. I would not disregard the possibility of events like shady buyouts or company downfalls happening[5] but at the same time, I would also not let my practical and objective observations incline towards my previously-exhibited scepticism[6][7] around this.

One of the cool things that would end up happening if we go ahead with the integration of Fedora Badges with Discourse is that it would no longer be necessary to explicitly point out where new members can contribute and where the existing members are actively contributing as it all becomes a part of their identity within this forum. With the use of badges set on custom titles and user cards, people can share about the subcommunities (SIGs, workgroups, teams etc.) that they have been contributing to, the elections that they have voted for, the events they have participated in and much more, a lot more organically during discussions and that makes these badges lot more useful items than just being fancy collectables.

We should be able to. No problems with that!

  1. https://fedora-arc.readthedocs.io/en/latest/badges/discourse_integration.html#how-to-go-about-it ↩︎

  2. https://fedora-arc.readthedocs.io/en/latest/badges/discourse_integration.html ↩︎

  3. https://discussion.fedoraproject.org/ ↩︎

  4. https://discussion.fedoraproject.org/ ↩︎

  5. as we have all witnessed what happened to our friends maintaining one of the widely used IRC networks ↩︎

  6. Yes, I previously disregarded the use of Discourse as the frontend entity for the Fedora Badges system when my thoughts around it were not as well-formed as they are now ↩︎

  7. ↩︎

3 Likes
17

So in short - the Discourse backend isn’t proposed to be used at all, the pre-existing functionality of the Badges backend would be in place, but rewritten?

So if I was looking to interact with badges would I realistically be going thru the Discourse API, or one exposed by the new badges backend? What makes the most sense / would be best to support?

From reading the ARC link (which I missed the first read in a footnote, whoops!), it seems like the bulk of the effort is on the backend. So if there was a risk relying on Discourse it’s prolly low since so much is going to exist outside of discourse. Although have you looked at whether or not customizing Discourse to the extent needed is going to negatively impact our support?

It would be nice to have badge achievements closer to where Fedora folks are / socialize / chat. Discourse is only one piece of that though - any thoughts about Matrix integration? Simplest (and what happened in the old days of badges) was a bot notifying when a user was awarded a badge; we had a filter on the design channel bot messages so any design team related badge achievement was sent to channel which was nice and gave the team an opportunity to congratulate the recipient / celebrate the achievement and also for new members to ask for advice on how to earn it themselves. Maybe an automated digest posting of badges awarded on a monthly basis to the community blog (we’ve done this in the past manually authored) or some form of widget integration there?

In short the Fedora community is more than Discourse, so I wonder how that might impct the possibility of having a plurality of front end integrations across Fedora social hubs (including matrix and the community blog)?

1 Like
18

I think there would be a choice. Since both, Badges backend and Discourse, provide an API, both could be utilized to interact with badges. The choice depends on the kind of interaction. All of this should be well documented. With respect to Discourse, I’d consult Discourse Meta [1].

Whatever frontend, Matrix, Blog, Wiki, etc., needs to consume badges, should consult the backend API. That’s the Accolades API in @t0xic0der’s schema. Querying a user’s badges is a basic requirement. Other criteria, like user’s having earned a certain badge, will also be supported. If there’s a new, special requirement, the API can always be extended.

Of course, we need a clear view on current (and past) consumers to implement all required functionality in the API.

  1. https://docs.discourse.org/ ↩︎

1 Like
19

I like the idea of greater Matrix integration too, but other than the announcement bot idea, I’m not sure exactly where that would go, because there’s not really much by way of user profile pages. As far as I know, there’s just a bare-bones thing with your avatar image, like this:

image

But maybe we could work with Element on something?

20

dont know which topic to reply to.

I just have one external badge, but I think it doesnt work? Not sure how I registered the Fedora discussion account, that may have been externally and not through Fedora accounts?

But the badge for voting on the Fedora badges site is not displayed here.