DRAFT - Gamification connectors (writing in progress)

[srenault-meeds]

Rationale

Meeds aims to provide to end-users connection to other tools so path can be done to access apps, or to collect actions done in order to gamify it in Meeds software

Currently, it is not fully provided. Only a github connector is proposed but it needs to be studied again for consistency sake

1. Functional Requirements

1. Admin can manage connectors

• From the gamification menu in administration, admin (admin or reward admin) can access connectors page

• From that page, default connectors are proposed: Meeds, Github, Discord, Twitter, Zapier

• For each default connector, it is possible to: a. disable it, even default ones b. set permissions for it (default = users) c. Edit settings upon what it is needed to set, for example: _organization-name. For Github, the name of the organization is meeds-io, for twitter, the name is IoMeeds _organization-domain. For Github, a repository is a domain, for discord, the category is a domain _organization-subdomain. For discord, a channel is a subdomain _triggers. For github, for example, PR request is a trigger (AKA event)

For each setting, the admin don't see organization_name or organization_domain but a clear and concise label like these ones, for Github: Organization / Repository Or for Discord: Server Name / Category / Channel

• From that page, new connectors can be added by the admin. Two options for that: a. From a marketplace so the user can access other connectors provided by the Meeds DAO or its members b. By creating a new one with a configuration to be set up

• When creating a new connector, the admin has to precise configuration for the connector: a. add clientsecret, clientID and any other parameters requested to enable such connection b. set permissions for it (default = users) c. add settings upon what it is needed to set, for example: -> Slack connector: name, channel, triggers -> Jira connector: organization, project name, triggers

• For each connector, the admin can access analytics to see which trigger are used and which one are not used, by who, etc. This aims to let him a way to manage and provide help if needed

2. Program owners can add action related to connectors

• When adding an action in a program, the program owner can decide to choose from event proposed by default: -> Meeds example: a. If I choose like activity in a space b. Then I can precise another characteristic like any, space or activity ID -> Github example: a. If I choose PR validated b. Then I can precise another characteristic like any repo, or Meeds-Social repository -> Twitter example: a. If I choose RT event b. Then I can precise another characteristic like account (if multiple), or Tweet link to get the ID

3. End-users can set their connector from multiple places

• From its personal settings, a user will be able to access accounts he can activate for gamification purpose or any other use case we'd like to implement in the future.

• From an action, when someone sees an event that can be gamified but authentication needs to be added to confirm identity and ownership of that account. Once done, the action can be done by the user

  Proposition: when an action requesting a connection by the user, then notification can be displayed to the user so it can be enabled from there.

• For each connection, the user will need to confirm its identity and the owning of the account he wants to activate. a. mail sent to the current user email to confirm the action b. oAuth window to confirm the will of connecting apps: credentials of the connected app to enter and to be validated -> token stored during a period. Once the period has passed, the user will be informed of such expiration so he can confirm he wants to continue use this connection

Decision to confirm: token to be stored locally with ability for the admin to revocate it or to the browser

2. Technical Requirements

Expected Volume & Performance

Security

Extensibility

Configurability

Upgradability

Existing Features

Feature Flags

Property Name	Default Value	Target Audience	Functional Behaviour

Other Non Functional Requirements

3. Impacts

Documentation

Training

4. Software Architecture

Security

Access

• GUI
• API

Services & processing

• Ex: Scheduled Jobs

Data and persistence

• Macro data model
• Persistence layer
• Use of caches

  Clustering

Multitenancy

Integrations

Migration strategy

5. Annexes

• Reasoning that explain the technical choices
• Impacts
• References

[srenault-meeds]

@plamarque I let you review it as you are the main client of it Thanks

[plamarque]

Review done.