Skip to content
This repository was archived by the owner on Mar 16, 2022. It is now read-only.
This repository was archived by the owner on Mar 16, 2022. It is now read-only.

how to correlate users to automatically issue badges #23

Open
Open
how to correlate users to automatically issue badges#23
Labels
bdg-agendaAgenda to be discussed in coming meetings

Description

@ryzokuken
ryzokuken
opened on Apr 12, 2018

While thinking stuff about the automation workflow for issuing badges, I came upon this:

Because we're using GitHub's webhooks to trigger the badge issuance methods, we'd have access to the GitHub details of the user (here: contributor) under consideration. However, the badgr API will need the details from their badgr which may (and probably will) be different.

In order to correlate users, we would have a few options, a subset of which is:

  1. Make a database mapping our contributors' GitHub credentials to their Badgr credentials and use it while issuing badges.

  2. Automatically issue a badge to a badgr user with the same username (thus forcing username consistency upon contributors) [BAD]

  3. Automatically issue a badge to a badgr user with the same email (thus forcing email consistency upon contributors) [RELATIVELY LESS BAD]

@nodejs/badges and others, please vote on these and if possible, propose better ones.

Activity

  1. amiller-gh commented on Apr 12, 2018

    @amiller-gh
    amiller-gh
    on Apr 12, 2018
    Member

    Are you sure we need each recipient to have an active Badgr account to issue badges? It seems like /v2/badgeclasses/{entity_id}/issue will allow you to pass any email address, regardless of if its associated with a Badgr account. The recipient data model appears to be:

    interface {
  // Either the hash of the identity or the plaintext value
  identity: string;

  // Type of identifier used to identify recipientEnum:
  type:  "email" | "openBadgeId" | "telephone" | "url";

  // Whether or not the identity value is hashed.
  hashed: boolean;

  // The plaintext identity
  plaintextIdentity: string;
}

    I'm not entirely sure what plaintextIdentity means, but the data model leads me to believe we can pass it any email and it should notify that person that they have a badge to claim.

    I have a hunch that people won't already have Badgr accounts and they'll be making them to claim these badges 😉 So I vote for #3!

  2. ryzokuken commented on Apr 13, 2018

    @ryzokuken
    ryzokuken
    on Apr 13, 2018
    ContributorAuthor

    @amiller-gh they don't need to have a badgr account, but if they do, and it has different credentials (associated email) then #1 works best.

    That said, I'm in favor of #3 as well, because it is much more foolproof than #2 while still involving us to do much less work than #1.

  3. Tiriel commented on Apr 13, 2018

    @Tiriel
    Tiriel
    on Apr 13, 2018

    Not sure creating a whole database is a good idea either. It would need much maintenance, associated platform issues and cost.

    I'd say option 3 as well!

  4. maddhruv
    added
    bdg-agendaAgenda to be discussed in coming meetings
    on Apr 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bdg-agendaAgenda to be discussed in coming meetings

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions