[R] DHO Badges - Githubissues

sceenius commented 4 years ago

Purpose

Digital Badges are part of the larger credentialing ecosystem. There are many ways to recognize an achievement, and many forms of proof for a variety of needs. A digital badge serves both as recognition of learning or unlocking achievement or confirming a status level AND digital proof of that accomplishment. We have a unique opportunity to create badges in the DHO and to store a proof on chain, allowing other providers to verify/use the badge in their own context (DHO). We also see badges as "signal amplifiers" that multiply your existing work in the DHO. For example, if you work in a 60% committed role earning $10,000, a potential badge could increase your SEEDS and HVOICE tokens by a factor of 1.01 for each salary claim (giving you 100 more SEEDS and HVOICE per claim). If you do not have a role (you do not have a responsibility and/or earn a salary), then the multiplier is 0 and the badge has no value. In other words, the badge only amplifies existing work and is only meaningful inside this context. We can have badges that have a multiplier of 1 (having no impact on your salary) or less than 1 (having negative impact on parts of your salary, e.g. to shift your token portfolio, see token matrix or to take a break/vacation), the combinations in this space are endless.

Approach

1 Create a new object called "Badge" in the DHO 2 Adjust Assignments to be able to apply for a badge 3 Create a new role or badge called "Badge Librarian" as caretaker of the process

1 New Badge Object

name of badge
description of badge (with updated template on accountability being criteria)
icon for badge (to attach to avatar/profile)
- store and retrieve icons on our Cloudron instance with Minio - https://assets.hypha.earth/ (https://github.com/minio/minio)
- stack them visually on the right side of the avatar (see below)
- "layering" of icons on the card - https://fontawesome.com/how-to-use/on-the-web/styling/layering
token multiplier (a quadruple for (H,V,E,S) with each factor [0..10]?, see matrix)
- badges with net positive impact - rewards on compensation, "star for a week", "hero for the day"
- badges with net negative impact - penalties on compensation, "no show"
- badges with both negative and positive impact - rebalancing token compensation (1.2,1.0,0.9,0.9)
- tokens with net neutral impact (factor 1) - qualifications
badges are additive (can be combined to increase value)
(TBD) badges are stackable (e.g. "min XYZ badge or training needed to apply for this badge")
(TBD) badges are interoperable (boundary objects, recognized in other dApps)
badges show in the badge proposals and badge agreements views, with the badge (center) and the badge icon (top right), see image below

2 Modified Assignment Object

same as role application, except:
description says why you earned it (e.g. some evidence/outcome/activity)
no commitment level
no deferred Seeds %
salary component shows token multipliers (as percentage, with 100% == no change == 1x multiplier)
lunar cycle may apply to limit validity of badge
badges are applied when salary is claimed
the voting method for this object type is 1T1V/100/20/3D (active as soon as the unity/quorum threshold has been reached AND min 3 days have passed since threshold )
badges show on the card in the assignment views for both proposals and agreements (see below)

3 New Role or Badge for Badge Librarian

authority to create badges in the DHO
go to person to design new badges for the org
design badge icon
verify multipliers are within range
verify that the badge has minimum task-accountability and maximum task-authority
select name and write description

Initial badges might include: Badge Master, Treasurer, Enroller, Lamp Lighter

When a badge gets assigned, here are the edges that are created:

     member            ---- holdsbadge     ---->   badge
     member            ---- badgeassign    ---->   badge_assignment
     badge             ---- heldby         ---->   member
     badge             ---- assignment     ---->   badge_assignment
     badge_assignment  ---- badge          ---->   badge

sceenius commented 4 years ago

Joost has defined the LL role-badge as follows - note this is in the context of a role since we don't have badges yet.

sceenius commented 4 years ago

Nomenclature - to avoid too much ambiguity what a role and badge is, we add a prefix to DHO specific roles and badges:

1 Roles are dho-role-assignments, or role-assignments 2 Badges are dho-badge-assignments, or badge-assignments

We then have "role fillers" and "badge holders" once the application passes.

sceenius commented 4 years ago

As an alternative to custom icons for each badge we could use https://www.tinygraphs.com/ (similar to the role avatars based on a string like badge name)

sceenius commented 4 years ago

DHO BADGES2 (3)

https://www.flaticon.com/free-icon/treasury_1029891?term=treasury&page=1&position=4 https://www.flaticon.com/free-icon/ticket_1599675?term=ticket&page=1&position=33 https://www.flaticon.com/free-icon/police-badge_745429?term=badge&page=1&position=19 https://www.flaticon.com/free-icon/oil-lamp_3349111?term=lantern&page=1&position=26

gregory-latinier commented 4 years ago

@dappdever is the smartcontract ready for this task ?

mgravitt commented 4 years ago

@dappdever is the smartcontract ready for this task ?

@gregory-latinier No, not yet. I will add it this week. The trickier part will be updating the payment claim calculations, which I'll need to author several tests for. The easy part is setting up the object and moving it from the "proposal" scope to the "badge" scope when it passes. I will do the easy part first and deploy to test so you can add that part of the UI.

mgravitt commented 4 years ago

Here are object specifications for badge and badgeass object types:

NOTE: badge is similar to role and badgeass is similar to assignment

badge

names:
- owner
strings:
- title
- description
- icon
ints:
- husd_coefficient_x100
- seeds_coefficient_x100
- hvoice_coefficient_x100
- hypha_coefficient_x100
  
  NOTE: a number of 100 would be a coefficient/multiplier of 1, and anything below 100 would be a reduction in the payment

badgeass

names:
- owner (proposer)
- assigned_account (account that will be assigned the badge)
strings:
- description
ints:
- badge_id
- start_period_id
- end_period_id

mgravitt commented 4 years ago

Design Proposal

Save badges and badge assignments as documents rather than objects
Create a new table for DocumentIndex as below
UI may query this new table easily or DGraph

// scopes: badges, roles, assignments, members, specific member name, etc. 
 struct [[eosio::table, eosio::contract("hyphadao")]] DocumentIndex
  {
         uint64_t id;

         checksum256 document_hash;
         checksum256 by_hash() const { return hash; }

         time_point created_date = current_time_point();
         uint64_t by_created() const { return created_date.sec_since_epoch(); }

         uint64_t primary_key() const { return id; }
 };

typedef multi_index<name("docindex"),DocumentIndex,
                          indexed_by<name("idhash"), const_mem_fun<document, checksum256, &document::by_hash>>,
                          indexed_by<name("bycreated"), const_mem_fun<document, uint64_t, &document::by_created>>>
          docindex_table;

With this table, the client can easily get a list of all documents tied to a scope.

When a new badge proposal is created, it will:
- validate inputs, including using or assigning a name attribute to be known as badge_code
- create a document for the badge containing all inputs
- add that badge to the DocumentIndex for the proposals scope
When the badge proposal is approved, it will:
- remove the document from the proposals scope of DocumentIndex table
- add that document to the badges scope of DocumentIndex table
When a new badge assignment proposal is created, it will:
- validate inputs, including existence of badge document & member account
- create a document for the badge assignment
- add that badge assignment document hash to the DocumentIndex for the proposals scope
When the badge assignment proposal is approved, it will:
- remove the document from the proposals scope
- add that document to the member-account (e.g. hyphanewyork) scope
- add the member-account (e.g. hyphanewyork) to the scope that matches the badge_code for this badge

So data would be accessible as follows:

in order to see which badges a member holds, a query can be made to the DocumentIndex table using that member's account as the table scope
to view a list of all members holding a specific badge, use the badge_code as the scope (NOTE: this allows for multiple versions of a badge by allowing multiple documents to use the same badge_code)

Finally, when a member claims pay,
- the action can retrieve the list of badges for a specific member using the member name as the scope
- iterate the list of badges and multiple the payment amounts by the appropriate coeffecients (stacked/additive/multiplicative)

sceenius commented 4 years ago

That's fantastic, love the clarity in the contract. One suggestion about the coefficient - let's constrain it so that no "accidents" will happen (e,g, you loose all your income, or worse you owe tokens (!)). I suggest to add a bottom and ceiling of +/- 10%, so [0.9 .. 1.1] for each token.

sceenius commented 4 years ago

From Rieki: I think we'd need higher Unity Quorum thresholds for immediate passing. Don't want 20% to be able to quick vote and overturn an 80% rejection.

Ideally we'd want to be on or near the point of mathematical certainly.

Like 70% quorum and 90% Unity .

Im sure there's an elegant algorithm that can say where the quorum and unity thresholds need to be (like how high quorum at 100% unity vs 80%, etc).

My response: @rieki We could go with 100% consensus, but the 20%+ on quorum will be difficult w/o the circle governance structure. Let me check if we can add this to the badge spec. Also, I see badges as an experiment for a new voting method, so we can adjust that if it creates real issues.

@dappdever Can we add 100% unity to the decide contract? Let's discuss

sceenius commented 4 years ago

Note the edit -

the voting method for this object type is 1T1V/100/20/3D (active as soon as the unity/quorum threshold has been reached AND min 3 days have passed since threshold )

mgravitt commented 4 years ago

Each badge will have the ability to support a "multiplier" for each token type. We have to work with integers because floats are not deterministic when run on multiple servers simultaneously.

So, we can either represent this as a "coefficient" or a "bonus". If it's a coefficient, it should be the number that is multiplied by the token amount to get the resulting amount to be paid. To support amounts at 1/10th a percentage (0.1%), we'll need to multiply the raw coefficient by 1000 to get to an integer. In this case, a coefficient of 101.1% (aka 1.011) would be set/saved as 1011.

Alternatively, we can represent this as a "bonus", meaning it would be a positive or negative number between -10% and 10%. (we would still need to multiply it by 1000 to support 0.0% precision)

My question is: does anyone have a preference?

I don't feel strongly, but I think I prefer coefficient. To me, it's more intuitive, and the payment action will iterate through all badges for that user to create a compound coefficient, then multiply the token quantity by that coefficient.

Using "bonus" would effectively be the same; we'd just add the bonus_x1000 to 1000 to get the coefficients.

sceenius commented 3 years ago

as an fyi - Here's how HolacracyOne (TM) defined badges: https://static1.squarespace.com/static/5d1239a79c02150001db74d4/t/5d80a885d736e97ab1eb9e77/1568712837845/Badge-based+Compensation+App.pdf

About roles and policies (overkill imho):

Add Role: Badge Librarian Purpose: Badges that represent clear, clean, and useful distinctions for the organization Accountable For:

Maintaining and publishing the organization’s official Badge Library
Reviewing and assessing proposed additions or changes to the Badge Library, when complete Badge proposals are submitted by any Role or Partner in the Organization
Assisting other Roles and Partners in crafting Badge proposals, upon their request and upon confirmation that a Role with the power to assign Partners to Roles believes the potential Badge represents a significant consideration in the choice of assignment

Add Role: Badge Bootstrapper Purpose: Highly discerning and conservative Badge grants to bootstrap just enough people into new Badges Accountable For:

Assessing Partners for Badges upon their self-nomination, when there aren't yet enough people who actually hold the Badge and work with the Partner who can reasonably assess

Add Role: Compensation Architect Purpose: The right compensation system for the Organization and its Partners Accountable For:

Designing, implementing, and evolving the Organization’s overall systems & related processes for determining Partner compensation
Defining and publishing the organization's possible compensation tiers, along with general criteria or sample profiles to guide the tagging of a Badge set to an appropriate tier placement

Assessing Badge valuation proposals against other valuations already in the Badge Valuation Database and against the general guidance published by @Compensation_Architect

Add Role: Compensation Administrator Purpose: Accurate recordkeeping of Badges held per Partner and resulting compensation levels Accountable For:

Defining and publishing an authoritative source of which Partners hold which Badges ©2015 HolacracyOne, LLC Page 5 of 9
Publishing and maintaining the official mapping of Badge sets to compensation tiers (the "Badge Valuation Database")
Identifying and publishing a target compensation tier for each Partner based on his/her most valuable Badge set listed in the Badge Valuation Database
Reviewing evidence submitted by any Partner that a Partner has earned or lost a Badge, given the process or mechanism defined in the Badge, and updating Badge and compensation records if clear and compelling evidence indicates a Badge has been earned or lost
Tracking time-based and event-based triggers that expire Badges, and,

Add Policy: Defining Badges The Organization's official “Badge Library” lists “Badges” that are available for Partners to earn in recognition of their skills, talents, capacities, and achievements. Each Badge definition must include a description of the skill, talent, capacity, or achievement that the Badge represents, and may optionally include a process or another mechanism for Partners to gain the Badge and/or lose the Badge.

No one may add, modify, or remove Badges from the Badge Library unless each @Badge_Librarian first confirms he/she sees no Objections to the change, or fails to respond with an Objection within a week of a proposed change. In any case however, no Badge in the Badge Library may be modified or removed while another process or active decision relies on the Badge (although it may be marked as "inactive" and made unavailable for new use, and an updated version may be added for new use instead).

Add Policy: Badge Valuation The "Badge Valuation Database" is a listing of specific sets of Badges, with each set mapped to a specific compensation tier using the tiers defined by Compensation Architect. The full-time compensation level for a Partner may only be set at the highest tier that matches a set of Badges the Partner holds (or the pro-rated equivalent for a part-time commitment).

The Badge Valuation Database may only be modified via a Proposal that results in no Objections from all @Compensation_Guardian's, using the Integrative Decision-Making Process. This Proposal may be made asynchronously to just the @Compensation_Guardian's, using the Constitution's rules for asynchronous processing, or via a special "Badge Valuation Meeting" scheduled by any Partner. All @Compensation_Guardian's must be invited to this meeting, as well as this Circle's elected Facilitator, and it may only be scheduled for 30 minutes. A majority of the @Compensation_Guardian's must attend for the meeting to proceed, and even with a majority it may not proceed if any @Compensation_Guardian requests a reschedule.

At a Badge Valuation Meeting, the Partner who scheduled the meeting may propose one or more new or modified badge set valuations for the Badge Valuation Database, and the facilitator of the meeting will process the Proposal via the Integrative Decision-Making Process, but with only the @Compensation_Guardian's participating in the Objection Round (if the elected Facilitator chooses not to attend, the Constitution's rules for selecting a surrogate apply). Any Proposal that fails to pass within the time allotted for the meeting is automatically dropped. No Partner may schedule a Badge Valuation Meeting within one month of the last such meeting that Partner scheduled.

Through the process defined above, the valuation tied to any Badge set may be lowered, or more Badges may be added to an existing set. In these cases, any Partner whose compensation level was tied to that Badge set may keep their compensation level calculated using the old Badge set and associated valuation for a period of 12 months following the change; at that point, compensation levels due to legacy Badge sets or valuations will automatically expire.

Add Policy: Transitioning to Badge-Based Compensation Any role extending offers for new Partners to join the Organization may give those new Partners an initial compensation level based on a set of Badges the role-filler assumes the new Partner is likely to earn (additional governance may define or limit this authority further). That Partner's compensation may not drop below this initial tier placement for a period of 12 months after joining the Organization (except due to a shift to a part-time relationship or removal from the Organization).

Partners who joined the company before the roll-out of the Badge-based Compensation System may opt to keep their compensation level calculated under the old system until they have enough Badges to provide a comparable or greater compensation level under the new system

sceenius commented 3 years ago

There is an interesting example in the above for a "Business Savvy" badge:

Badge: Business Savvy Levels (each counts as a separate Badge): I have repeatedly demonstrated that…

I can apply professional norms in the business world to my behavior when contextually relevant, and not stick out as an inappropriate young punk in a conventional business
I can participate in a conversation with more experienced business professionals about general business topics, without slowing them down or looking like the clear novice in the room
I can add to conversations about some common areas of business building from direct experience (e.g. operations, management, finance, culture, leadership, etc.)
I can add to conversations about almost any common area of business, while pulling in useful and relevant direct experience, and appear generally "business-savvy" to business pros
I can debate sophisticated business strategies toe-to-toe with other seasoned business leaders, with the feel of someone who has "been there, done that" in business
I can get my hands dirty in all common areas of business building, with the easy, grounded confidence and nuanced wisdom of experience
I can take the reigns of a conventional company as CEO (or equivalent), or build one from the ground up, and grow it through multiple phase transitions in scale/revenue/reach/etc.
I can teach CEO's and entrepreneurs about business building from deep experience, and keep them coming back for more
I have achieved wide recognition as a master in this practice area

Which somewhat matches to the complexity levels of roles (see listed below). So, this batch could be a pre-requisite for a B1-B7 role. There's no need to enforce it in the code, since badges are highly visible - we can just show it on the avatar when the application is happening.

This role follows predefined protocols. When an obstacle is encountered, seek help. Each activity creates value for the organization in accordance with a protocol. Generally recognizes this value and feel aligned with it.
This role accumulates bits of information to diagnose and anticipate problems. Proactivity appears. Trends are noticed and value increases over time. Generally seeks guidance from guides when reaching out in a positive, self-reflecting and empathic way.
This role plans and carries out sequential activities while considering contingencies and alternatives. Recognition of better choices, adaptability & seizing of opportunity to create more value for the organization. Generally self-directed with minimal guidance from circle Guide.
This role manages multiple, interdependent serial activities. Balance resources among a circle. Finds the best internal sources for value creation and chains of activities (e.g. reaching out to and connecting circle leads). Oftentimes in a Circle Guide position. Generally seeks guidance from parent circle or facilitator roles. Strong organizational awareness & service orientation.
This role optimizes, coordinates and performs the function of a circle or external support roles. It locates external people or sources for additional value/support and participate in internal value creation opportunities through weaving, bonding, coaching and mentoring activities. Requires minimal to no guidance from parent circle or facilitator roles.
This role leads the accumulated impact of multiple circles. It weaves internal and external value streams together which sums are larger than the individual streams. It leverages domain expertise in multiple areas to create coherent value across multiple cirlces and roles. Strong conflict resolution & solution orchestration, actively co-creating and bringing new and undirected resources to the organization.
This role constructs and pursues global strategic plans. Facilitate the strategic evolution of the whole organism. Critical domain expert. Invents new value streams in collaboration across multiple organizations and people. Meta-leader, holds contradictions, interdependent. Typically an inspirational leader or ecosystem facilitator, giving guidance to other circle leads and members of the organization.

mgravitt commented 3 years ago

A badge proposal can be made using the propose action:

eosc -u https://test.telos.kitchen --vault-file ../eosc-testnet-vault.json tx create dao.hypha propose '{
    "proposer": "johnnyhypha1",
    "proposal_type": "badge",
    "content_groups": [
        [
            {
                "label": "content_group_label",
                "value": [
                    "string",
                    "details"
                ]
            },
            {
                "label": "title",
                "value": [
                    "string",
                    "Badge Librarian"
                ]
            },
            {
                "label": "description",
                "value": [
                    "string",
                    "Ensure that badges represent clear, clean, and useful distinctions for the organization"
                ]
            },
            {
                "label": "icon",
                "value": [
                    "string",
                    "https://images.app.goo.gl/yhZci6h65rUFp1gy5"
                ]
            },
            {
                "label": "seeds_coefficient_x10000",
                "value": [
                    "int64",
                    10010
                ]
            },
            {
                "label": "hypha_coefficient_x10000",
                "value": [
                    "int64",
                    10015
                ]
            },
            {
                "label": "hvoice_coefficient_x10000",
                "value": [
                    "int64",
                    10000
                ]
            }, {
                "label": "husd_coefficient_x10000",
                "value": [
                    "int64",
                    10100
                ]
            }
        ]
    ]
}' -p johnnyhypha1

The list of proposals can be retrieved from the edges table:

cleos -u https://test.telos.kitchen get table -r -l 2 dao.hypha dao.hypha edges                                                                                                                              
{
  "rows": [{
      "id": 3113338309,
      "from_node": "61aaf984e245d887db702d96edbca69a2cf536f6b2375af959abcfbeb19e8fe0",
      "to_node": "41e04c97bfd074751f356f7927cfe9a7db35ae783455f78841ea1be9cb94fc3c",
      "edge_name": "proposedby",
      "created_date": "2020-10-15T14:33:40.500"
    },{
      "id": 1946137705,
      "from_node": "71836b83d367ab992b58d3704efd7e9d4d36b28e90bd89ecee82415f7ca34528",
      "to_node": "f7976167a3002de4a56ec1b30696189b79b6f389621c910ae70934adcce01a8e",
      "edge_name": "owns",
      "created_date": "2020-10-14T16:04:11.500"
    }
  ],
  "more": true,
  "next_key": "480441643"
}

Then, the details of this document can be retrieved:

cleos -u https://test.telos.kitchen get table -l 1 --index 2 --key-type sha256 -L f7976167a3002de4a56ec1b30696189b79b6f389621c910ae70934adcce01a8e dao.hypha dao.hypha documents
{
  "rows": [{
      "id": 20,
      "hash": "19d212d1cfec20561334884c556757914b1a31e9af93e8e4029f5209981784aa",
      "creator": "dao.hypha",
      "content_groups": [[{
            "label": "content_group_label",
            "value": [
              "string",
              "proposal_details"
            ]
          },{
            "label": "title",
            "value": [
              "string",
              "Badge Librarian"
            ]
          },{
...<snip>...

Once voted on and approved, the list of approved badges can be retrieved with the following queries:

scope=badge, table=docindex

cleos -u https://test.telos.kitchen get table dao.hypha badge docindex                                                                            
{
  "rows": [{
      "id": 0,
      "document_hash": "19d212d1cfec20561334884c556757914b1a31e9af93e8e4029f5209981784aa",
      "created_date": "2020-10-07T15:14:41.500"
    }
  ],
  "more": false,
  "next_key": ""
}

(and at this point, the docindex record will be removed from the proposal scope.

sceenius commented 3 years ago

Badge images as follows (see filename):