Moteur de règles

[ghost]

• Le but d'un système de récompense est d'être attractif, engageant et motivant pour les contributeurs
• L'organisation doit décider des types de comportements ou d'accomplissements (relation durable, assiduité, dévouement, contribution essentielle, responsabilité et conformité) qu'elle souhaite encourager avec ce système de récompenses: tout ce qui est récompensé tend à se répéter.

⚠️ récompenses intrinsèques et extrinsèques

• elles possèdent une surface et un symbolisme: elles signifient combien sont précieux ses contributeurs à l'organisation mais aussi leur importance vis-à-vis des uns et des autres.

Le débat est l'architecture et l'implémentation de ce système: pourquoi vouloir l'implémenter en SQL ?

portabilité: 0 expressivité: 0 maintenabilité: 0

S'il est question, effectivement, de raisonner sur des résultats d'observations, alors développons un autre système dédié et découplé du système de récompense.

Les contributeurs, l'environnement, les taxa observés vont toujours arriver à surprendre: le système de récompense demandera des réglages réguliers des pondérations en particulier au démarrage de l'expérience, sans socle de connaissance.

Une implémentation en python pourrait potentiellement être plus expressive, descriptive et beaucoup plus maintenable.

Ici, par exemple, un prototype sous forme d'automate ... ... avec une suggestion de config descriptive mais concise:

states = {
    'initial': 'Start',
    'Start': (None, None, [start_transitions]),
    'amateur_state': (User.attendance >= 3, 'bronze_state', [amateur_bronze,]),
    'bronze_state': (User.attendance >= 5, 'argent_state', [some_reducer,]),
    'bronze_state': (User.observations[-1].taxon.rarity >= 0.7, 'argent_state',[r1, r2,]),
    'bronze_state': (User.seniority >= 4 and User.attendance >= 5, 'argent_state', []),
    'argent_state': (User.attendance >= 10, 'or_state', [r3,]),
    'argent_state': (User.observations[-1].taxon.rarity >= 0.7, 'or_state', [r4,]),
    'argent_state': (User.attendance * User.observations[-1].taxon.rarity >= 7, 'or_state', [r5,]),
    'or_state': (None, None, None)
}
for old_state, (trigger, next_state, reducers) in states.items()
    ...

[ghost]

Spécifié au deuxième point: https://github.com/PnX-SI/GeoNature-citizen/issues/6#issuecomment-444835847

[orovellotti]

Règle Groupe

Pour faire simple on est ok sur le fait qu'il faut se baser sur le groupes operationel inpn 1? On peut utiliser les badges actuel pour les groupe avec (*) @patkap ?

• Algues
• Arthropodes *
• Ascomycètes
• Bryophytes
• Bryozoaires
• Chordés *
• Cnidaires
• Echinodermes
• Mollusques
• Plantes vasculaires *
• Porifères
• Vers

Règle Milieux/altitude

Pour la règle altitude on se base sur des gradients classiques ?

• Vallée <1000
• Moyenne montagne 1000 < < 2000
• Haute montagne > 2000

Il existe des services Google qui retournent une altitude pour un point GPS.

[orovellotti]

Au vue de votre appétence pour le Sql est ce que le système de gestion avec un paramètrage en Json vous conviens ?

Attention: il n’offre pas la flexibilité d’une trigger mais présente l’avantage d’être beaucoup plus facile à éditer ?

[camillemonchicourt]

A vrai dire, avec tout ça je n'ai pas compris ce qui était souhaité comme badges et ce qui serait fait. Il faut surtout faire simple, paramétrable et se replacer dans les contextes d'utilisation de cet outil. Soit des ABC dans des petits territoires avec beaucoup de taxons, soit des programmes sur un territoire comme un parc national avec seulement quelques espèces.

[ghost]

la config actuelle en toml se transformerait en json:

"seniority": { 
    "Seniority.oeuf": "7days", 
    "Seniority.chenille": "6months", 
    "Seniority.papillon": "1an" 
},
"attendance": { 
    "Attendance.Au": 5000, 
    "Attendance.Ar": 1000, 
    "Attendance.CuSn": 100 
},
"program_attendance": { 
    "Program_Attendance.Au": 7, 
    "Program_Attendance.Ar": 5, 
    "Program_Attendance.CuSn": 3 
},
"program_date_bounds": { 
    "start": "2019-03-20", 
    "end": "" 
},
"taxo_error_binary_weights": { 
    "regne": 64, 
    "phylum": 32, 
    "classe": 16, 
    "ordre": 8, 
    "famille": 4, 
    "genre": 2, 
    "cd_sup": 1,
    "cd_nom": 0
},
"taxo_distance": {
    "Observateur.None": 4, 
    "Observateur.Eclairé": 2, 
    "Observateur.Chevronné": 1, 
    "Observateur.VraimentFort": 0 
}

Le but étant de pouvoir ajouter et pondérer le nombre d'intervalles que l'on souhaite ... ?

[DonovanMaillard]

à noter aussi que l'outil peut ne pas servir sur des zones de montagne, mais aussi sur le littoral ou en mer par exemple (pour la question sur les altitudes).

Le mieux serait peut être de pouvoir définir un critère sur lequel porte le badge, et définir une valeur ou une fenêtre de valeurs ? De facon générique ca ouvre la porte à davantage de possibilités ?

[ghost]

Règle Groupe

Pour faire simple on est ok sur le fait qu'il faut se baser sur le groupes operationel inpn 1? On peut utiliser les badges actuel pour les groupe avec (*) @patkap ?

• Algues

✓ Arthropodes *

• Ascomycètes
• Bryophytes
• Bryozoaires

✓ Chordés *

• Cnidaires
• Echinodermes
• Mollusques

✓ Plantes vasculaires *

• Porifères
• Vers

tous nos badges sont là: https://github.com/PnX-SI/GeoNature-citizen/issues/6#issuecomment-444806109

Règle Milieux/altitude

Pour la règle altitude on se base sur des gradients classiques ?

• Vallée <1000
• Moyenne montagne 1000 < < 2000
• Haute montagne > 2000

Il existe des services Google qui retournent une altitude pour un point GPS.

Je ne serai pas étonné si l' IGNF proposait aussi ce genre de service ... On pourrait encore s'en servir comme éléments de catégorie attribués "manuellement".

[orovellotti]

La question est :

1/ Est ce que vous voulez gérer ça en trigger au risque de perdre des utilisateurs mais avec beaucoup de souplesse ?

2/ Est ce que vous voulez gèrer avec un Json/TOML plus simple a éditer mais forcément moins souple (Le Json n’offre pas la même expressivité qu’une trigger Sql)?

Merci

[camillemonchicourt]

La question est surtout : quelles sont les règles simples et pertinentes à mettre en place. Et assez souples pour pouvoir être ajustées aux différents contextes.

[orovellotti]

Le plus simple c’est de définir trois règles et de les rendre parametrables en Json (même si je doute que ce soit très utile)

1/ une règle d’altitude (impossible d’avoir un milieu facilement)

2/une règle de groupe opérationnel inpn (impossible d’avoir une autre info sur l’espèce simplement)

3/une règle sur le nombre d’observations, nombre et classe en Json?

Mais le cahier des charges est beaucoup plus fournit (trigger?)

[orovellotti]

Selon le cctp il doit y avoir deux systèmes :

Un système automatique (paramétrable par les animateurs) qui attribue des badges aux utilisateurs en fonction de leurs statistiques: • nombre de données (par exemple: or>5k données, argent>1k données, bronze>100 données), • ancienneté du compte (par exemple: œuf=7j, chenille=6mois, papillon=1an), • mission réussie (pour des journées spécifiques voir plus bas).

Un système manuel (paramétrable également par les animateurs) qui permet de regrouper les utilisateurs dans plusieurs catégories, par exemple: observateur fiable, observateur non fiable, scolaire, accompagnateurs en montagne (AEM), partenaires ...

Les animateurs doivent pouvoir créer de nouveaux badges automatiques en définissant les seuils de déclenchements de ces badges selon les éléments suivants : • type de taxons (par exemple: les oiseaux, la faune, la flore, ou plus précisément : ex la vanesse des pariétaires), • nombre d'observations à partir duquel ils se déclenchent (de une à n observations), • définir des bornes de dates pendant laquelle l'obtention est possible pour créer des évènements (muguet le 01/05, marathon des oiseaux en période de migration etc...), Ils doivent pouvoir créer des badges manuels également qui sont gérés sous la forme de liste.

[samuelpriou]

Nous préférons la solution du code SQL afin de pouvoir faire une gestion des badges adaptable à tous les contextes et moins restrictive que la proposition du JSON. En effet nous pourrions déclencher des badges selon plusieurs critères :

• géographiques (communes, etc),
• nombre de d'obs,
• classe d'altitude,
• groupes INPN,
• espèces,
• dates, évènements spéciaux ...

En ce qui concerne les badges, nous n'avons pas vu ceux concernant l'ancienneté (œuf, chenille, papillon).

[camillemonchicourt]

Un système manuel (paramétrable également par les animateurs) qui permet de regrouper les utilisateurs dans plusieurs catégories, par exemple: observateur fiable, observateur non fiable, scolaire, accompagnateurs en montagne (AEM), partenaires ...

Ce sujet a déjà été évoqué et réglé avec l'ajout d'un champs dans la BDD.

Pour le reste, les badges, leur objectif et leur gestion, selon moi, le sujet est vraiment pas clair et n'a pas été défini et ne peut pas se discuter comme ça.

[DonovanMaillard]

Avoir des groupes utilisateurs fiables ou non fiables dans une base, ça ne me semble pas souhaitable (même pas sur que ça soit très légal d'inscrire ce type de jugement dans des données personnelles)

[camillemonchicourt]

Avoir des groupes utilisateurs fiables ou non fiables dans une base, ça ne me semble pas souhaitable (même pas sur que ça soit très légal d'inscrire ce type de jugement dans des données personnelles)

Hors sujet et déjà réglé : https://github.com/PnX-SI/GeoNature-citizen/issues/9

Chacun en fera bien ce qu'il veut, c'est une table de groupe et la possibilité d'associer un utilisateur à un groupe, directement dans la BDD.

[DonovanMaillard]

Ça marche

[orovellotti]

On ajoute deux règles qui définissent le nombre d'observation par programme et par groupe d'espèces.

On supprime la regle sur l'exactitute du taxon et on conserve le fonctionnement avec le fichier Json.