J’ai été très occupé ces derniers jours. Mais je suis presque fini avec la mise à jour de la logique pour obtenir la statistique suivante la plus proche : au lieu de regarder le pourcentage, elle regarde la valeur réelle la plus basse qui peut ensuite être atteinte.
En ce qui concerne les TL3 sur le point de perdre des progrès, j’ai également commencé à travailler dessus. Le dépôt ne devrait probablement pas être utilisé pour le moment, car il est entre le produit fini.
Hmm. Je dirais qu’elles existaient en quelque sorte depuis toujours. J’ai trouvé un commit les renommant datant de 2014
Je ne pense pas qu’il y ait eu « longtemps » de Discourse avant cela.
Je pense que vous pourriez avoir besoin de paramètres séparés pour les palettes de couleurs claires et sombres. Le gris clair sur fond noir a un contraste différent de celui sur fond blanc.
Au lieu de time_period: "Based on last %{num_days} days." vous pouvez utiliser
time_period:
one: "Based on last %{count} day."
other: "Based on last %{count} days."
Ainsi, vous obtenez jour/jours selon le nombre. Les choses deviennent un peu compliquées lorsqu’il y a plus d’un nombre dont d’autres mots dépendent dans le texte. Je tenterais d’éviter Message Format.
Intéressant, maintenant je me demande pourquoi je pensais ce que j’avais noté.
Autre remarque intéressante concernant ce commit : il a été effectué par Jeff ( coding-horror), ce qu’on voit rarement de nos jours.
Après avoir lu :
Je me suis rappelé d’un problème auquel certains utilisateurs sont confrontés lorsqu’ils tentent d’atteindre le niveau TL3.
Lorsque les utilisateurs sont tenus de lire un certain nombre ou pourcentage de messages, ils supposent naturellement que tous les messages pris en compte dans ce calcul leur sont visibles. Cependant, ce n’est pas toujours le cas.
Par exemple, si les messages d’une catégorie muette sont toujours comptabilisés pour l’exigence, il pourrait y avoir suffisamment de messages éligibles dans les catégories muettes pour rendre l’objectif difficile — voire impossible — à atteindre sans d’abord désactiver le mode muet de ces catégories et lire les messages.
Le plugin devrait donc fournir un décompte catégorie par catégorie indiquant :
Cela permettrait de révéler si les catégories muettes affectent la progression de l’utilisateur et de montrer ce qu’il doit faire pour répondre à l’exigence — ou, comme certains utilisateurs pourraient le décrire, comment « tricher » avec le système.
Palettes de couleurs pour le mode clair/sombre
Presque terminé pour l’affichage des statistiques si un utilisateur TL3 risque de perdre son statut TL3 (avec un paramètre de seuil minimum pour afficher un avertissement si une statistique est inférieure à cette valeur).
Le problème, c’est que même le cœur du système n’a pas ce type d’indication. L’idée originale est de rendre accessibles aux utilisateurs les informations que les membres du staff peuvent voir. Je pense que cela pourrait être hors du périmètre du plugin. Mais j’aimerais en savoir plus à ce sujet. Est-ce que vous dites que les catégories non muettes ne contiennent pas assez de messages pour atteindre l’exigence, et que le nombre restant pourrait provenir des catégories muettes ?
De plus, comment cela fonctionnerait-il ? Récupérer chaque message créé dans l’intervalle de temps, vérifier le sujet auquel il appartient, vérifier l’ID de la catégorie, le comparer avec les catégories muettes de l’utilisateur, puis l’ajouter à un compteur ? Ou peut-être une requête SQL optimisée…
Pas nécessairement, bien que cela puisse être vrai dans un cas extrême.
De temps à autre, en aidant les utilisateurs, on a remarqué que le nombre de messages lus par un utilisateur augmentait plus rapidement que celui d’un autre. La différence tenait souvent au fait que le lecteur le plus actif n’avait masqué aucune catégorie. Les sujets de ces catégories apparaissaient donc dans ses listes de sujets et avaient plus de chances d’être lus.
Lorsque l’autre utilisateur a désactivé le masquage de la catégorie, plus de sujets sont devenus visibles dans ses vues de navigation habituelles, et son nombre quotidien de messages lus a augmenté pour se rapprocher de celui de l’autre utilisateur.
Oui. Les messages de ces catégories peuvent être comptabilisés lorsqu’ils sont effectivement lus. Cependant, masquer une catégorie peut indirectement ralentir la progression d’un utilisateur, car ses sujets sont masqués dans des vues comme Derniers et sont donc plus faciles à passer à côté.
Il y a plusieurs années, le quota de lecture de messages sur le forum OpenAI était basé principalement sur un pourcentage de l’activité du forum, sans le plafond inférieur qui existe dans de nombreuses configurations actuelles. Sur un forum très actif, cela pouvait exiger la lecture de 10 000 messages ou plus.
Certains utilisateurs ont remarqué que les totaux de messages lus d’autres membres, tels qu’affichés dans le répertoire des utilisateurs, augmentaient beaucoup plus rapidement, alors même qu’ils lisaient chaque message visible qu’ils pouvaient trouver. Après quelques investigations, les catégories masquées ont été identifiées comme la cause : un nombre important de messages disponibles n’apparaissaient pas dans leurs listes de sujets habituelles.
C’est ainsi que je tenterais de procéder en premier lieu.
Bon, j’ai ajouté la fonctionnalité pour afficher la plus faible statistique si l’utilisateur est au-delà du niveau 3. J’ai préparé les requêtes pour trouver le nombre de sujets et de messages dans les catégories muettes, et je travaille à les intégrer dans l’interface utilisateur.
Bingo bongo : @EricGT J’ai ajouté l’affichage indiquant si l’utilisateur est bloqué, combien de sujets et de messages il y a dans les catégories en sourdine, et si l’utilisateur va bientôt perdre son TL3. J’attends une réponse sur How do I access topics in muted categories? pour obtenir le lien correct permettant de consulter ces sujets en sourdine.
J’ai mis à jour le lien pour qu’il pointe uniquement vers /u/<username>/preferences/tracking. S’il n’y a rien d’autre, je vais de l’avant et créer le sujet Customization > Plugin !
C’est génial, merci de l’avoir développé et partagé !
Je me demande si cette base peut être utilisée pour un indicateur de progression similaire lié aux badges. Notre système de karma/défis (anciennement appelé félicitations/badges) et de niveaux de confiance est personnalisé, et pour notre communauté, un indicateur de progression lié aux défis/badges serait celui qui nous convient le mieux.
Cela a été publié sur See TL3 Progress 
!