Just wondering if there is anyone around here that is actively (or semi-actively) maintaining the Fedora Badges system(s).
The reason for this query is that we are currently working on the datanommer / datagrepper transition to Fedora Messaging, and Fedora Badges is revealing itself to be a special side-case.
The majority of applications use the datagrepper JSON API to interact with the store of messages that datanommer stuffs into its database. However, badges appears to have direct access to the datanommer DB using the datanommer.models module (which we use in datagrepper too, obviously) Note too that FMN also hase this direct access rather than using datanommer
This in of itself doesnt seem to be a huge issue to the migration, as the grep method of datanommer.models has not changed its API (which is all these apps use to get data with), so in theory, we just need to update datanommer.models on these applications and everything should be hunky-dory.
However, neither of these applications are running currently on staging, so there is nowhere fo us to test this out.
Long story long, just wondering if anyone is aware of any activeish maintainers of these items so we can discuss further.
cheers, ryanlerch
On Tue, Aug 17, 2021 at 6:49 AM Ryan Lerch rlerch@redhat.com wrote:
Just wondering if there is anyone around here that is actively (or semi-actively) maintaining the Fedora Badges system(s).
The reason for this query is that we are currently working on the datanommer / datagrepper transition to Fedora Messaging, and Fedora Badges is revealing itself to be a special side-case.
The majority of applications use the datagrepper JSON API to interact with the store of messages that datanommer stuffs into its database. However, badges appears to have direct access to the datanommer DB using the datanommer.models module (which we use in datagrepper too, obviously) Note too that FMN also hase this direct access rather than using datanommer
This in of itself doesnt seem to be a huge issue to the migration, as the grep method of datanommer.models has not changed its API (which is all these apps use to get data with), so in theory, we just need to update datanommer.models on these applications and everything should be hunky-dory.
However, neither of these applications are running currently on staging, so there is nowhere fo us to test this out.
Long story long, just wondering if anyone is aware of any activeish maintainers of these items so we can discuss further.
Hey Ryan,
We can for sure work something out and update the necessary bits. Would you mind opening up a ticket and mentioning me so I can look at this?
Cheers,
Hey Ryan,
Sure, Please mention me in the ticket too, For me to collaborate and work on it.
-- Nasir Hussain
On Tue, Aug 17, 2021 at 11:24 AM SmootherFrOgZ lxtnow@gmail.com wrote:
On Tue, Aug 17, 2021 at 6:49 AM Ryan Lerch rlerch@redhat.com wrote:
Just wondering if there is anyone around here that is actively (or semi-actively) maintaining the Fedora Badges system(s).
The reason for this query is that we are currently working on the datanommer / datagrepper transition to Fedora Messaging, and Fedora Badges is revealing itself to be a special side-case.
The majority of applications use the datagrepper JSON API to interact with the store of messages that datanommer stuffs into its database. However, badges appears to have direct access to the datanommer DB using the datanommer.models module (which we use in datagrepper too, obviously) Note too that FMN also hase this direct access rather than using datanommer
This in of itself doesnt seem to be a huge issue to the migration, as the grep method of datanommer.models has not changed its API (which is all these apps use to get data with), so in theory, we just need to update datanommer.models on these applications and everything should be hunky-dory.
However, neither of these applications are running currently on staging, so there is nowhere fo us to test this out.
Long story long, just wondering if anyone is aware of any activeish maintainers of these items so we can discuss further.
Hey Ryan,
We can for sure work something out and update the necessary bits. Would you mind opening up a ticket and mentioning me so I can look at this?
Cheers,
Xavier.t Lamien
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Aug 17, 2021 at 4:24 PM SmootherFrOgZ lxtnow@gmail.com wrote:
On Tue, Aug 17, 2021 at 6:49 AM Ryan Lerch rlerch@redhat.com wrote:
Just wondering if there is anyone around here that is actively (or semi-actively) maintaining the Fedora Badges system(s).
The reason for this query is that we are currently working on the datanommer / datagrepper transition to Fedora Messaging, and Fedora Badges is revealing itself to be a special side-case.
The majority of applications use the datagrepper JSON API to interact with the store of messages that datanommer stuffs into its database. However, badges appears to have direct access to the datanommer DB using the datanommer.models module (which we use in datagrepper too, obviously) Note too that FMN also hase this direct access rather than using datanommer
This in of itself doesnt seem to be a huge issue to the migration, as the grep method of datanommer.models has not changed its API (which is all these apps use to get data with), so in theory, we just need to update datanommer.models on these applications and everything should be hunky-dory.
However, neither of these applications are running currently on staging, so there is nowhere fo us to test this out.
Long story long, just wondering if anyone is aware of any activeish maintainers of these items so we can discuss further.
Hey Ryan,
We can for sure work something out and update the necessary bits. Would you mind opening up a ticket and mentioning me so I can look at this?
Ok -- we have this ticket open on datanommer if that helps:
https://github.com/fedora-infra/datanommer/issues/151
cheers, ryanlerch
It appears that the conversion fo python3 on fedbages was done about a year ago -- but never released or deployed into production.
There is some discussion on this ticket here:
https://github.com/fedora-infra/datanommer/issues/151
and also an infra ticket here:
https://pagure.io/fedora-infrastructure/issue/10192
cheers, ryanlerch
On Tue, Aug 17, 2021 at 6:25 PM Ryan Lerch rlerch@redhat.com wrote:
On Tue, Aug 17, 2021 at 4:24 PM SmootherFrOgZ lxtnow@gmail.com wrote:
On Tue, Aug 17, 2021 at 6:49 AM Ryan Lerch rlerch@redhat.com wrote:
Just wondering if there is anyone around here that is actively (or semi-actively) maintaining the Fedora Badges system(s).
The reason for this query is that we are currently working on the datanommer / datagrepper transition to Fedora Messaging, and Fedora Badges is revealing itself to be a special side-case.
The majority of applications use the datagrepper JSON API to interact with the store of messages that datanommer stuffs into its database. However, badges appears to have direct access to the datanommer DB using the datanommer.models module (which we use in datagrepper too, obviously) Note too that FMN also hase this direct access rather than using datanommer
This in of itself doesnt seem to be a huge issue to the migration, as the grep method of datanommer.models has not changed its API (which is all these apps use to get data with), so in theory, we just need to update datanommer.models on these applications and everything should be hunky-dory.
However, neither of these applications are running currently on staging, so there is nowhere fo us to test this out.
Long story long, just wondering if anyone is aware of any activeish maintainers of these items so we can discuss further.
Hey Ryan,
We can for sure work something out and update the necessary bits. Would you mind opening up a ticket and mentioning me so I can look at this?
Ok -- we have this ticket open on datanommer if that helps:
https://github.com/fedora-infra/datanommer/issues/151
cheers, ryanlerch
Hey all! I blame infinitely-long Covid-times for this lapse in memory. I know there was an investigation into moving Fedora Badges to Badgr. Where did that lead?
On Wed, Sep 1, 2021 at 8:36 AM Matthew Miller mattdm@fedoraproject.org wrote:
Hey all! I blame infinitely-long Covid-times for this lapse in memory. I know there was an investigation into moving Fedora Badges to Badgr. Where did that lead?
Did not know about this investigation -- but after poking around badges these past weeks (related to the datanommer work), it appears there was some work done to convert to badgr apis done this time last year in fedbadges (the backend):
https://github.com/fedora-infra/fedbadges/commits/develop
This appears to have been done at the same time as converting to python3 -- no this was never deployed -- badges still is running on Python2 / RHEL7
beyond seeing these commits -- no further information is known by me,
cheers, ryanlerch
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Sep 01, 2021 at 12:41:30PM +1000, Ryan Lerch wrote:
Hey all! I blame infinitely-long Covid-times for this lapse in memory. I know there was an investigation into moving Fedora Badges to Badgr. Where did that lead?
Did not know about this investigation -- but after poking around badges these past weeks (related to the datanommer work), it appears there was some work done to convert to badgr apis done this time last year in fedbadges (the backend):
Okay, thanks -- so it looks like Snehal is probably who I should talk to.
I was looking a little bit at Badgr, and one of my concerns is that it's open core, with a lot of functionality we need (SSO, qr codes, mass awarding) and some we really want (pathways) as the proprietary parts. If we have to implement those ourselves, that means we'd be on a constant fork (possibly one regarded as hostile). And at that point, that might be as much or more work than reviving Tahrir.
Marie pointed me to another possibility, BadgeOS.
This is a wordpress plugin and meant for wordpress-based sites, but, hey, we already have some wordpress, and we might be able to adapt it. We'll still need a custom plugin for the actual fedora messaging and fas stuff, and possibly other things I have no idea about.
They are also a "core features free" business model, but they tell me ther "premium" addons are actually all open source under the AGPL. So that's a lot more appealing to start, and I think we could get some budget here to have _their_ team worrying about those plugins for us while we worry about the Fedora-specific stuff.
On Wed, Sep 01, 2021 at 09:30:01PM -0400, Matthew Miller wrote:
Okay, thanks -- so it looks like Snehal is probably who I should talk to.
Oh! And for the record, I found this from Nest last year:
https://docs.google.com/presentation/d/1pV6wQsBSt195jjR2whPQS9jHDzn9Zlo8KMME...
I talked to the BadgeOS people, and I found this really, really promising. I think maybe that's the direction we should move in. But, I don't want to step on the feet of anyone who is working on Badgr, or invalidate any hard work that went into that!
On Thu 2 Sep 2021, 02:30 Matthew Miller, mattdm@fedoraproject.org wrote:
On Wed, Sep 01, 2021 at 12:41:30PM +1000, Ryan Lerch wrote:
Hey all! I blame infinitely-long Covid-times for this lapse in memory.
I
know there was an investigation into moving Fedora Badges to Badgr.
Where
did that lead?
Did not know about this investigation -- but after poking around badges these past weeks (related to the datanommer work), it appears there was some work done to convert to badgr apis done this time last year in fedbadges (the backend):
Okay, thanks -- so it looks like Snehal is probably who I should talk to.
I was looking a little bit at Badgr, and one of my concerns is that it's open core, with a lot of functionality we need (SSO, qr codes, mass awarding) and some we really want (pathways) as the proprietary parts. If we have to implement those ourselves, that means we'd be on a constant fork (possibly one regarded as hostile). And at that point, that might be as much or more work than reviving Tahrir.
Marie pointed me to another possibility, BadgeOS.
This is a wordpress plugin and meant for wordpress-based sites, but, hey, we already have some wordpress, and we might be able to adapt it. We'll still need a custom plugin for the actual fedora messaging and fas stuff, and possibly other things I have no idea about.
FAS aside as that's mandatory let's look at what we have and what we can move to. The current Fedora messaging integration relates really heavily to "capture all the things" and then award Badges. I'm wondering how valuable and incentive driven that is given many Badges are passively earned. With a new system its a new chance to reimagine what a Badge should be awarded for. That might give flexibility and not a hard coupling at a system level to Fedora Messaging. Could the levels be inferred from another app and awarded even manually once a time period for example
They are also a "core features free" business model, but they tell me ther "premium" addons are actually all open source under the AGPL. So that's a lot more appealing to start, and I think we could get some budget here to have _their_ team worrying about those plugins for us while we worry about the Fedora-specific stuff.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Sep 02, 2021 at 07:32:37PM +0100, Leigh Griffin wrote:
FAS aside as that's mandatory let's look at what we have and what we can move to. The current Fedora messaging integration relates really heavily to "capture all the things" and then award Badges. I'm wondering how valuable and incentive driven that is given many Badges are passively earned. With a new system its a new chance to reimagine what a Badge should be awarded for. That might give flexibility and not a hard coupling at a system level to Fedora Messaging. Could the levels be inferred from another app and awarded even manually once a time period for example
Well, I do not want to move from automated processes to something where a human needs to take a long time checking lists and pushing buttons. That's a recipe for the whole thing to just stop working. In fact, if anything, I'd like to see us automate as many badges that are now manual as possible.
Plus, instant gratification is important -- waiting for someone to do it once a quarter will absolutely not be as effective as letting someone earn their badges in the middle of the night when they feel inspired.
But anyway, I'm pretty sure that there are things which we _do_ want from both Fedora Accounts and the message bus. This amount of observability into actions people take is really powerful and one of the reasons we can do cool things in the first place.
So once that's needed, I don't think there's really much difference between needing 10 and needing 10,000 -- both are more than 1.
On Thu, Sep 2, 2021 at 8:23 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Sep 02, 2021 at 07:32:37PM +0100, Leigh Griffin wrote:
FAS aside as that's mandatory let's look at what we have and what we can move to. The current Fedora messaging integration relates really heavily
to
"capture all the things" and then award Badges. I'm wondering how
valuable
and incentive driven that is given many Badges are passively earned.
With a
new system its a new chance to reimagine what a Badge should be awarded for. That might give flexibility and not a hard coupling at a system
level
to Fedora Messaging. Could the levels be inferred from another app and awarded even manually once a time period for example
Well, I do not want to move from automated processes to something where a human needs to take a long time checking lists and pushing buttons. That's a recipe for the whole thing to just stop working. In fact, if anything, I'd like to see us automate as many badges that are now manual as possible.
I'm generally all for Automation but that creates a glue layer that becomes a thing that unless developed and actively maintained and can put us right back at a conversation point when tech stacks move forward :)
Plus, instant gratification is important -- waiting for someone to do it once a quarter will absolutely not be as effective as letting someone earn their badges in the middle of the night when they feel inspired.
Are there any insights or quantifiable data about the impact Badges have? Is it a subset of Badges that are more impactful? What I'm trying to get at here is are all Badges equal or are a subset more valuable and hence something to maybe bring to the design level conversations?
But anyway, I'm pretty sure that there are things which we _do_ want from
both Fedora Accounts and the message bus. This amount of observability into actions people take is really powerful and one of the reasons we can do cool things in the first place.
Out of curiosity, what does the observability drive or end up at? I'd love to tie that closer to the need and ask as we explore this with the community
So once that's needed, I don't think there's really much difference between needing 10 and needing 10,000 -- both are more than 1.
Needing no, for sure, maintaining and building, possibly :P
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Sep 02, 2021 at 09:12:51PM +0100, Leigh Griffin wrote:
I'm generally all for Automation but that creates a glue layer that becomes a thing that unless developed and actively maintained and can put us right back at a conversation point when tech stacks move forward :)
[...]
Are there any insights or quantifiable data about the impact Badges have? Is it a subset of Badges that are more impactful? What I'm trying to get at here is are all Badges equal or are a subset more valuable and hence something to maybe bring to the design level conversations?
I think you've got two separate questions here, and are not so secretly hoping that the answer to one of them will lead to there being less work for the other. I'm for less work too, so I sympathize. :)
But, I think they really are separate issues. We definitely want to revisit our overall strategies as part of this. In fact, one of the thing the badgeos folks specialize in is developing comprehensive gamification strategies, and we very well might want to take advantage of that as a consulting engagement. I think there are roughly three goals:
1. To help onboard new people — or folks who have been around into a new team. Badge paths show what you can do next to get more involved, or perhaps need to do next to get membership in a certain group.
From the message bus activity I've been watching (https://mattdm.org/fedora/fedora-contributor-trends/, but soon to be replaced with Josseline's new better system), we've consistently had about 225 regular contributors to the project every week (and, each week, about 100 other contributors who do some small thing but aren't engaged other weeks). I'd like to double that, and to do that, we need better onboarding paths.
2. To reward people for things they've done.
Badges are both little rewards in themselves (the gamification aspect, which we've seen to be quite enjoyable and inspiring to some Fedora folks), and we can also use badge pathways to send swag packages to folks who have reached a certain level of activity (or done specific things).
3. To showcase the activity of the project overall.
Part of the original design was meant to be tied into Fedora Hubs, but that never came to fruition. We'll need to figure out another way to make a showcase, but overall badges make a nice way of showing off all of the constant activity within the project.
The other issue, of glue... well, I have the pretty strong belief that having systems which talk to each other is what makes a lot of this possible. We can give badges for chairing a project meeting in Matrix/IRC because that connection exists. We can have badges based on Discussion sign up, or for helping people on Ask. We can give badges for submitting a change to docs as a PR, and other badges for accepting that PR. A lot of projects just have code commits and bugs from which to populate their picture of the world, and since we have all of this interconnectedness, we can better lead people to, reward people for, and showcase people's achievements in all these non-coding areas — as well as, of course, dist-git, koji, bodhi, copr, and so on.
On Thu, Sep 2, 2021 at 11:02 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Sep 02, 2021 at 09:12:51PM +0100, Leigh Griffin wrote:
I'm generally all for Automation but that creates a glue layer that
becomes
a thing that unless developed and actively maintained and can put us
right
back at a conversation point when tech stacks move forward :)
[...]
Are there any insights or quantifiable data about the impact Badges have? Is it a subset of Badges that are more impactful? What I'm trying to get
at
here is are all Badges equal or are a subset more valuable and hence something to maybe bring to the design level conversations?
I think you've got two separate questions here, and are not so secretly hoping that the answer to one of them will lead to there being less work for the other. I'm for less work too, so I sympathize. :)
haha my efforts here are to make sure we don't end up in a situation in 5-10 years time where history repeats itself. I'm a fan of questioning the past to influence the future!
But, I think they really are separate issues. We definitely want to revisit our overall strategies as part of this. In fact, one of the thing the badgeos folks specialize in is developing comprehensive gamification strategies, and we very well might want to take advantage of that as a consulting engagement. I think there are roughly three goals:
To help onboard new people — or folks who have been around into a new team. Badge paths show what you can do next to get more involved, or perhaps need to do next to get membership in a certain group.
From the message bus activity I've been watching (https://mattdm.org/fedora/fedora-contributor-trends/, but soon to be replaced with Josseline's new better system), we've consistently had about 225 regular contributors to the project every week (and, each
week, about 100 other contributors who do some small thing but aren't engaged other weeks). I'd like to double that, and to do that, we need better onboarding paths.
That's a really cool hidden gem, first time I have seen it!
To reward people for things they've done.
Badges are both little rewards in themselves (the gamification aspect, which we've seen to be quite enjoyable and inspiring to some Fedora folks), and we can also use badge pathways to send swag packages to
folks who have reached a certain level of activity (or done specific things).
To showcase the activity of the project overall.
Part of the original design was meant to be tied into Fedora Hubs, but that never came to fruition. We'll need to figure out another way to make a showcase, but overall badges make a nice way of showing off all
of the constant activity within the project.
The other issue, of glue... well, I have the pretty strong belief that having systems which talk to each other is what makes a lot of this possible. We can give badges for chairing a project meeting in Matrix/IRC because that connection exists. We can have badges based on Discussion sign up, or for helping people on Ask. We can give badges for submitting a change to docs as a PR, and other badges for accepting that PR. A lot of projects just have code commits and bugs from which to populate their picture of the world, and since we have all of this interconnectedness, we can better lead people to, reward people for, and showcase people's achievements in all these non-coding areas — as well as, of course, dist-git, koji, bodhi, copr, and so on.
It definitely makes it possible but it comes with a risk factor! Thanks for the insight though this was helpful to talk through
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I am really glad we are having this conversation! I have been a big part of the Badges project over the years and its definitely close to my heart, so we can keep that bias in mind ;) I have also been sad to see development declining on the project as it just isn't new and shiny anymore, and the technologies underneath don't seem too exciting for anyone for to work with. I would like to think if we brought it to a more modern place, the Websites & Apps team would be interested and able in being part of maintenance and perhaps development of features.
The last time I put some effort into reviving things on the development side was in 2019 at Flock in Budapest. We had a short hackfest to identify the needs of the project, we also looked at usability and did some testing. From that we were able to pull together enough direction and work to bring on an Outreachy intern: Snehal, mentored by Misc & Sayan. Snehals internship was over before the work was completed. I believe this is the work with badgr and python 3 that is referenced earlier in this thread.
All of Matthew's points about the value of badges are spot on! I have a couple more points to add.
1. This app was introduced in 2013 and after 8 years of integration with our ecosystem it is now ingrained in Fedora's culture. Badge designs range from community "inside jokes" and if you look through the designs you will see our collective humor is entrenched in the designs. I have had *many, many* conversations with Fedora folks over the years about badges, and how much they *LOVE* them. We would have a lot of very very disappointed people if badges were to retire.
2. Our badges system puts us in front of an important issue in open source volunteer communities- how to provide recognition and incentive. We should try to be a model of how to do this, and hopefully do it well. I have heard stories of other communities looking to us for ideas of how to do various things, and I hope we can keep the Badges success story going.
3. Badges help empower our contributors by allowing them to reward each other. This helps solidifies folks identities as leaders of initiatives/projects/teams.
4. Badges is an *amazing* onboarding tool for the Design Team as well as application tool for Outreachy and other design related mentorships. Beyond that- it would be really sad to see the program end from the design perspective because it showcases the work of dozens of artists from the Fedora community.
In addition to all the points raised here - the creation, distribution and availability of badges through a badging automation system also enhances the trust and confidence in this process. That is, the viewership of these badges can easily understand that they represent a finite piece of accomplishment and can also be easily followed back to the actual accomplishment and achievement themselves.
/s
On Fri, Sep 3, 2021 at 7:06 PM Marie Nordin mnordin@redhat.com wrote:
I am really glad we are having this conversation! I have been a big part of the Badges project over the years and its definitely close to my heart, so we can keep that bias in mind ;) I have also been sad to see development declining on the project as it just isn't new and shiny anymore, and the technologies underneath don't seem too exciting for anyone for to work with. I would like to think if we brought it to a more modern place, the Websites & Apps team would be interested and able in being part of maintenance and perhaps development of features.
The last time I put some effort into reviving things on the development side was in 2019 at Flock in Budapest. We had a short hackfest to identify the needs of the project, we also looked at usability and did some testing. From that we were able to pull together enough direction and work to bring on an Outreachy intern: Snehal, mentored by Misc & Sayan. Snehals internship was over before the work was completed. I believe this is the work with badgr and python 3 that is referenced earlier in this thread.
All of Matthew's points about the value of badges are spot on! I have a couple more points to add.
This app was introduced in 2013 and after 8 years of integration with our ecosystem it is now ingrained in Fedora's culture. Badge designs range from community "inside jokes" and if you look through the designs you will see our collective humor is entrenched in the designs. I have had *many, many* conversations with Fedora folks over the years about badges, and how much they *LOVE* them. We would have a lot of very very disappointed people if badges were to retire.
Our badges system puts us in front of an important issue in open source volunteer communities- how to provide recognition and incentive. We should try to be a model of how to do this, and hopefully do it well. I have heard stories of other communities looking to us for ideas of how to do various things, and I hope we can keep the Badges success story going.
Badges help empower our contributors by allowing them to reward each other. This helps solidifies folks identities as leaders of initiatives/projects/teams.
Badges is an *amazing* onboarding tool for the Design Team as well as application tool for Outreachy and other design related mentorships. Beyond that- it would be really sad to see the program end from the design perspective because it showcases the work of dozens of artists from the Fedora community.
On Fri, Sep 03, 2021 at 07:17:42PM +0530, sankarshan wrote:
In addition to all the points raised here - the creation, distribution and availability of badges through a badging automation system also enhances the trust and confidence in this process. That is, the viewership of these badges can easily understand that they represent a finite piece of accomplishment and can also be easily followed back to the actual accomplishment and achievement themselves.
Yes, well-said!
In fact, one of the things I'd like from a new system is finally getting some of our other currently-manually-awarded badges moved to be automatic.
On Fri, Sep 03, 2021 at 10:57:55AM +0100, Leigh Griffin wrote:
haha my efforts here are to make sure we don't end up in a situation in 5-10 years time where history repeats itself. I'm a fan of questioning the past to influence the future!
Yes, and I genuinely appreciate it. We need to make sure we have a sustainable solution.
That's a really cool hidden gem, first time I have seen it!
Yeah, it's off running off on my own server, and it currently uses fedmsg so it's going to die. And it's some very, very unsustainable hacky scripts. Josseline Perdomo has a new version that we hope to actually have running in Fedora community infra soon and which we can make more visible.
It definitely makes it possible but it comes with a risk factor! Thanks for the insight though this was helpful to talk through
:)
infrastructure@lists.fedoraproject.org
-
Leigh Griffin -
Marie Nordin -
Matthew Miller -
Nasir Hussain -
Ryan Lerch -
sankarshan -
SmootherFrOgZ