Closed Bug 889884 Opened 12 years ago Closed 12 years ago

[research] Open Badges!

Categories

(support.mozilla.org :: General, defect, P2)

Product:
support.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2013Q3

People

(Reporter: rrosario, Assigned: willkg)

References

Details

(Whiteboard: u=contributor c=badges p=3 s=2013.14)

One of our big goals of 2013Q3 is to integrate into the Open Badges infrastructure and implement a first set of badges. There are a lot of things to figure out. * backend infrastructure: api, events * ui: badge list on profile pages, recent badges awarded pages, etc * awards: what badges get awarded for what events, etc. This bug is about learning about open badges and django-badger and whatever else we need. Then come up with a plan to start tackling it with followup bugs. There are some things that we can probably get started on already and we should.
Making this 3pts to block off a good chunk of time. Adjust accordingly.
Whiteboard: u=contributor c=badges p= s=2013.14 → u=contributor c=badges p=3 s=2013.14
:r1cky :willkg, this bug is quiet i hope this means the research went well :-) as the self-appointed SUMO open badges "driver" I am always available to answer any questions you might have, please don't hesitate to IRC me or ask question in this bug OR email me
Roland: Sorry--I didn't start working on the research side of things until yesterday. I'm only covering the backend infrastructure part of the research. The ui stuff will depend on the backend infrastructure and will get figured out in other bugs. We're depending on you for the awards stuff. I'll know more and fill in details over the next week.
Here's the high-level rough low-down: 1. We want to add support for SUMO to act as an Issuer of badges and possibly also as a Displayer. 2. Badges require users' email addresses and use Persona for identity. We probably want to block on switching SUMO over to Persona. 3. We should use django-badger (https://github.com/mozilla/django-badger) and that'll get us most of the way there backend-wise. The rest of the work is related to the actual badges we want to provide and also the ui/ux requirements. However: 1. I can't tell for sure if django-badger adds both Issuer and Displayer support. It might just do Issuer support. If that's the case, we'll have to figure out the Displayer side ourselves. 2. There are a few issues in the django-badger tracker that suggest it doesn't work with Django 1.5. Also, it's failing Travis right now, doesn't have great docs and could use some serious TLC. Pretty sure Les said as much when we were talking about it a year ago. 3. django-badger uses South for migrations, but Kitsune uses schematic. We might need to switch or things will get messy. Looking into that and/or switching will require some serious work. I'm not sure we have other options. Maybe other people will use django-badger? Maybe we increase the likelihood of that if we brush off the dust and build some momentum for it again? Work break down for implementing the backend infrastructure for badges in Kitsune: 1. We want to block on switching SUMO to Persona. (Is this bug #889814?) 2. We probably need to block on switching Kitsune to South. (No bug for this, yet) 3. Someone is going to need to spend a week (at least) working on django-badger to get it into a more functional state and make sure it works with Django 1.5. It might require more time than that. 4. We should create a bug for adding the infrastructure for issuing badges along with a test badge. This isn't worth creating until at least item 1 is done and someone has spent some time on item 3. While we're doing all that, someone else should get the ui/ux stuff figured out so that we can do that implementation work in the same time frame and have stuff to test with. Pretty sure that covers this bug. I'm ok with creating a rough shell for item 4, but I can't fill in details until I or someone else spends more time with django-badger cleaning it up.
(In reply to Will Kahn-Greene [:willkg] from comment #5) > Here's the high-level rough low-down: > > 1. We want to add support for SUMO to act as an Issuer of badges and > possibly also as a Displayer. > > 2. Badges require users' email addresses and use Persona for identity. We > probably want to block on switching SUMO over to Persona. > hi will (and thanks for the excellent research!) can't we just do what web-dev badges uses? i.e. make an API call to the whatever badge server web-dev badges uses? or am i missing something here? as far as I know web dev badges don't require persona but i am probably missing something here :-) ! it might have something to do with the fact that web-dev badges uses github ids rather than SUMO or persona ids
SUMO will probably act as a Displayer which means I think it needs to know backpack ids which can be figured out from the Persona email address that owns that backpack. Ergo, the email addresses SUMO accounts use need to be the same otherwise SUMO will award badges to the wrong email address. Since the two need to be the same, I think it behooves us to block on switching to Persona first and thus avoid all the mismatch edge case hooplah. But you're right--we could do it without switching to Persona. I just think it's more work and will result in irritating and confusion for contributors. The webdev script doesn't do display at all. It just looks at repositories on Github and awards badges to the committer email addresses in the git commits. I'm not sure how they deal with badge verification which is an important part of issuing. I haven't looked at the webdev script in a while. Maybe they use the Mozilla baking service? django-badger has a series of listeners and can do progress badges and meta badges. We could either use django-badger or write all the stuff ourselves. If django-badger is in good enough shape, I'd rather use that than write it all ourselves.
(In reply to Will Kahn-Greene [:willkg] from comment #7) > SUMO will probably act as a Displayer [again thanks for the prompt and thoughtful response] I don't think SUMO needs to act as a displayer, just an issuer for the initial release of algorithmically issued badges. Displayer can come later in my opinion. My apologies for not making that clear. Is it practical/would it be OK for SUMO just to be an issuer of Open Badges for the initial release? Awesome comments about Persona. I still don't really understand why we need Persona and why it would be confusing without Persona. However I am tired and hungry :-) so I will do my homework about this and if I am confused I'll ping you in IRC.
SUMO definitely needs to display badges, otherwise why are we doing this? :) The https://badges.mozilla.org/ site is used for webdev badges and I think there are plans so that badges from other places can be pushed there in the future. I'm not an expert with the Open Badges protocol so I don't know all the details on what can and can't be done. I am pretty sure the way to go here is to use django-badger within kitsune. CCing :lmorchard for any thoughts here.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #9) > I am pretty sure the way to go here is to use django-badger within kitsune. Forgot to link: https://github.com/mozilla/django-badger
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #10) > (In reply to Ricky Rosario [:rrosario, :r1cky] from comment #9) > > I am pretty sure the way to go here is to use django-badger within kitsune. > > Forgot to link: https://github.com/mozilla/django-badger gah, I should;ve read comment 5 first.
(In reply to Will Kahn-Greene [:willkg] from comment #5) > 1. We want to block on switching SUMO to Persona. (Is this bug #889814?) I don't think this is really a blocker. Email addresses just need to match for pushing to the backpack, right? Pushing to the backpack shouldn't block us from issuing badges on SUMO anyway. Or maybe I am missing something? > 2. We probably need to block on switching Kitsune to South. (No bug for > this, yet) Can we just create schematic migrations when we need to update the django-badges schema? > 3. Someone is going to need to spend a week (at least) working on > django-badger to get it into a more functional state and make sure it works > with Django 1.5. It might require more time than that. I've seen pull requests that have this working. They just need some reviewing, etc.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #9) > SUMO definitely needs to display badges, otherwise why are we doing this? :) > LOL :-) Yes of course we want to display badges on SUMO *eventually* but if it's easier/faster to issue them from SUMO in the first release and display them elsewhere that's fine (and then display them on SUMO in a subsequent release). Isn't that what web dev does, issue the badges from their server and display them on the badge issuing server? And we will have a precedent for displaying SUMO badges in a week or 2 with manually issued badges. We are going to manually issue about half a dozen SUMO Open badges to the graduates of the technical writing program and these badges won't be displayed on SUMO obviously.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #12) > (In reply to Will Kahn-Greene [:willkg] from comment #5) > > 1. We want to block on switching SUMO to Persona. (Is this bug #889814?) > > I don't think this is really a blocker. Email addresses just need to match > for pushing to the backpack, right? Pushing to the backpack shouldn't block > us from issuing badges on SUMO anyway. Or maybe I am missing something? If we're not switching to Persona where we guarantee that the email address tied to our SUMO account *is* the Persona identity they're using for their backpack, then I don't think we can figure out the backpack id from the email address when we go to display badges. So like I said earlier, we might not *have* to switch to Persona first, but it will probably alleviate a lot of irritation and confusion if we do. I could be wrong, but that's how I'm reading their wiki pages. > > 2. We probably need to block on switching Kitsune to South. (No bug for > > this, yet) > > Can we just create schematic migrations when we need to update the > django-badges schema? That might work. I'm still in the "Looking into that and/or switching will require some serious work." boat. > > 3. Someone is going to need to spend a week (at least) working on > > django-badger to get it into a more functional state and make sure it works > > with Django 1.5. It might require more time than that. > > I've seen pull requests that have this working. They just need some > reviewing, etc. The Github issues system includes pull requests, so I was just lumping all that in together as a bunch of work to be done whether that's review work, testing work, coding work--whatever. The pull request I saw was several months old and had some commits in another repository that fixes some things. Straightening all that out will take a non-trivial amount of time. I was guessing a week.
Roland: I'm now confused. I'm going off of the requirements that are in the description. It sounds like you have a different set of requirements that I'm not aware of and can also do everything without any implementation on our side. So... what's going on?
I talked with Ricky and he mentioned https://github.com/mozilla/badges.mozilla.org which I hadn't seen before. I'll look at that tomorrow or Monday. Also, I was under the impression we wanted to show non-sumo badges, too, which would require us to be a Displayer. Ricky pointed out Mozillians is for that--we just need to show SUMO badges. Given that, we don't need to be a Displayer and can probably drop the Persona requirement because we don't need the backpack id. Updated high-level low-down: Here's the high-level rough low-down: 1. We want to add support for SUMO to act as an Issuer of badges 2. We should use django-badger (https://github.com/mozilla/django-badger) and that'll get us most of the way there backend-wise. The rest of the work is related to the actual badges we want to provide and also the ui/ux requirements. However: 1. There are a few issues in the django-badger tracker that suggest it doesn't work with Django 1.5. Also, it's failing Travis right now, doesn't have great docs and could use some serious TLC. Pretty sure Les said as much when we were talking about it a year ago. 2. django-badger uses South for migrations, but Kitsune uses schematic. We might need to switch or things will get messy. Looking into that and/or switching will require some work. Ricky posits that we can ignore this and just hand-write the schematic migrations when we update django-badger. That's entirely possible. Work break down for implementing the backend infrastructure for badges in Kitsune: 1. We might want to block on switching Kitsune to South but maybe just hand-write our migrations for now. (No bug for this, yet) 2. Someone is going to need to spend a week (at least) working on django-badger to get it into a more functional state and make sure it works with Django 1.5. It might require more time than that. 3. We should create a bug for adding the infrastructure for issuing badges along with a test badge. This isn't worth creating until at least item 1 is done and someone has spent some time on item 3. While we're doing all that, someone else should get the ui/ux stuff figured out so that we can do that implementation work in the same time frame and have stuff to test with. Pretty sure that covers this bug. I'm ok with creating a bug that roughly covers what's required for item 3, but I can't fill in details until I or someone else spends more time with django-badger cleaning it up.
(In reply to Will Kahn-Greene [:willkg] from comment #5) > 1. I can't tell for sure if django-badger adds both Issuer and Displayer > support. It might just do Issuer support. If that's the case, we'll have to > figure out the Displayer side ourselves. django-badger main covers the Issuer side of things, with the assumption that you'll push badges into the OBI Backback and use that for Displayer services. You may want to hop into #badges and ask about this. That said, django-badger *does* have views to display badges per user, users per badge, etc. > 2. There are a few issues in the django-badger tracker that suggest it > doesn't work with Django 1.5. Also, it's failing Travis right now, doesn't > have great docs and could use some serious TLC. Pretty sure Les said as much > when we were talking about it a year ago. It's probably been 4-6 months since I seriously worked on django-badger, mainly due to lack of interest and me getting busy elsewhere. It could totally use some TLC & docs. > 3. django-badger uses South for migrations, but Kitsune uses schematic. We > might need to switch or things will get messy. Looking into that and/or > switching will require some serious work. I bet you could ignore the South migrations and just transliterate them to schematic. There isn't a lot going on there, I don't think. > I'm not sure we have other options. Maybe other people will use > django-badger? Maybe we increase the likelihood of that if we brush off the > dust and build some momentum for it again? I would be delighted if that's what happens, and would love some help on the project. We have plans to also launch badges on MDN using django-badger, but the bug has not risen in priority enough to actually take off. > Work break down for implementing the backend infrastructure for badges in > Kitsune: > > 1. We want to block on switching SUMO to Persona. (Is this bug #889814?) This *might* not be a big deal if you have reliable email addresses associated with user accounts. But, users *will* need to sign into the OBI backpack using Persona, if you push badges there > 2. We probably need to block on switching Kitsune to South. (No bug for > this, yet) I would say this isn't a big deal. > 3. Someone is going to need to spend a week (at least) working on > django-badger to get it into a more functional state and make sure it works > with Django 1.5. It might require more time than that. I can help here, though it would be nice to have some more contributors
(In reply to Roland Tanglao :rolandtanglao from comment #6) > can't we just do what web-dev badges uses? i.e. make an API call to the > whatever badge server web-dev badges uses? or am i missing something here? > as far as I know web dev badges don't require persona but i am probably > missing something here :-) ! it might have something to do with the fact > that web-dev badges uses github ids rather than SUMO or persona ids badges.mozilla.org has an API, yes. But, please don't use it for SUMO. badge.m.o is a service mainly intended for groups that want to issue badges, but don't have a site from which to issue them. As an example, there is no webdev site, unless you count the blog. So, we have this python script that scrapes up email addresses from github commits, and issues badges on behalf of the webdev group. Then, to claim the badges, a Persona login to badges.m.o is required. For a site like SUMO, though, you'll want to look into integrating django-badger and issuing badges from your site directly.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #9) > SUMO definitely needs to display badges, otherwise why are we doing this? :) So, I was in a conversation with Mozillians folks a few months ago about badge display. One of the things we wanted to do, was to pull together all Mozilla-related badges issued to a mozillian, and allow them to display them on their Mozillian profile. That way, you could just show SUMO-issued badges on SUMO, but punt over to Mozillians for an expanded display of badges. There hasn't been much progress on this, though, in part because I've been busy and in part because we just haven't talked about it again. > The https://badges.mozilla.org/ site is used for webdev badges and I think > there are plans so that badges from other places can be pushed there in the > future. I'm not an expert with the Open Badges protocol so I don't know all > the details on what can and can't be done. Yeah, the idea with badges.m.o is that it's a service for badges that don't otherwise have a home. But, badges.m.o does *not* host a backpack - ie. badges from elsewhere *cannot* be pushed into badges.m.o. This is delegated over to the main OBI backpack at backpack.openbadges.org > I am pretty sure the way to go here is to use django-badger within kitsune. +1
Thanks for your input here Les, it's really helpful! (In reply to Les Orchard [:lorchard] from comment #19) > So, I was in a conversation with Mozillians folks a few months ago about > badge display. One of the things we wanted to do, was to pull together all > Mozilla-related badges issued to a mozillian, and allow them to display them > on their Mozillian profile. > > That way, you could just show SUMO-issued badges on SUMO, but punt over to > Mozillians for an expanded display of badges. Yeah, I meant that SUMO needs to display SUMO-issued badges, not all badges. I guess that means it doesn't need to be a Dispayer in the Open Badges protocol sense. Sorry for the confusion.
(In reply to Will Kahn-Greene [:willkg] from comment #14) > If we're not switching to Persona where we guarantee that the email address > tied to our SUMO account *is* the Persona identity they're using for their > backpack, then I don't think we can figure out the backpack id from the > email address when we go to display badges. If you use django-badger and just want to display locally-issued badges, there are views for that. So, in that case, you don't need to worry about backpacks. But, if you use OBI Backpack Displayer API to show off badges from beyond SUMO, it *does* have a means for converting from email to backpack ID: https://github.com/mozilla/openbadges/wiki/Displayer-API#converting-email--user-id I did a kind of hacky pull request to Mozillians a few months ago that uses this on the server-side, rather than as a JS include: https://github.com/mozilla/mozillians/pull/390/files#L1R335 > > > 3. Someone is going to need to spend a week (at least) working on > > > django-badger to get it into a more functional state and make sure it works > > > with Django 1.5. It might require more time than that. > > > > I've seen pull requests that have this working. They just need some > > reviewing, etc. > > The Github issues system includes pull requests, so I was just lumping all > that in together as a bunch of work to be done whether that's review work, > testing work, coding work--whatever. The pull request I saw was several > months old and had some commits in another repository that fixes some > things. Straightening all that out will take a non-trivial amount of time. I > was guessing a week. Yeah, I would say django-badger could use a week or so of freshening up & bringing it up to snuff with Django 1.5. I might be able to carve out time to help with that, but more help is always helpful.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #20) > Thanks for your input here Les, it's really helpful! Cool! I haven't been doing much with badges for a bit, but would be glad to see it get momentum again > Yeah, I meant that SUMO needs to display SUMO-issued badges, not all badges. > I guess that means it doesn't need to be a Dispayer in the Open Badges > protocol sense. Sorry for the confusion. If all you want to do at first is issue and display badges locally, django-badger should get you there. The Open Badges infrastructure stuff can just kind of sit there for future expansion. You can defer pushing to a backpack, displaying with Mozillians, etc until future iterations. I think we're still sort of ironing out all the details with that stuff as an organization, anyway.
(In reply to Will Kahn-Greene [:willkg] from comment #16) > I talked with Ricky and he mentioned > https://github.com/mozilla/badges.mozilla.org which I hadn't seen before. > I'll look at that tomorrow or Monday. For what it's worth, that code behind badges.m.o is just a really minimal Playdoh site that uses django-badger. It might show an example of how to use django-badger in Playdoh, but it doesn't add much more than that.
(In reply to Will Kahn-Greene [:willkg] from comment #15) > Roland: I'm now confused. I'm going off of the requirements that are in the > description. It sounds like you have a different set of requirements that > I'm not aware of and can also do everything without any implementation on > our side. So... what's going on? hi will: My apologies for any confusion! nope no secret badge requirements for algorithmic badges elsewhere :-). Just that etherpad at: https://etherpad.mozilla.org/sumo-algorithmic-badge-issuing We do have other wiki pages and spreadsheets for manually issued SUMO badges but they don't concern you (I think) since no code needs to be written and manually issued badges will peacefully :-) co-exist with algorithmically issued badges, am I right? (Just in case here's a link to the first manually issued badge for SUMO, the SUMO technical writing program badge: https://wiki.mozilla.org/User_talk:Rtanglao/SUMO-Q2-Q3-2013-badge-conversion-points#One_2013_Technical_Writing_Program_Badge ) The question you seem to be asking is: Q:What do code does sumo-dev need to write to minimally satisfy initial algorithmic badge release requirements A from Roland: From my naive viewpoint, just the code to issue the badges. We want and need the code to display the badges but that can come later if doing it later makes sense. And we'd love (in the fullness of time not initially) the bells and whistles that Les and Ricky are discussing as well. I think the subsequent comments from r1cky and les answered this question and more :-) But if this further confused you or you have other questions that aren't answered, let's have a quick chat over vidyo next week with kadir to clarify, just let me know when is best for you on Monday or Tuesday of next week.
Ok. Sounds like comment #16 covers everything and the plan going forward. I'll create a shell bug to cover the work, but we need to spend some time with django-badger before doing the work on Kitsune.
That covers this bug. Thank you all for your input!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 897057
You need to log in before you can comment on or make changes to this bug.