ZEP-44 : Validateur à la demande

L'objectif de cette ZEP est de permettre à tout membre de requérir les droits de validation pour pouvoir s'occuper d'un (ou plusieurs) tutoriel(s) d'intérêt particulier.

État de la situation

Généralités

Ce n'est pas un secret, la validation prend du temps (un peu normal, aussi), trop de temps sur ZdS. Il y a un certain consensus au sein du staff sur ce point. Le modèle hérité du Site du Zéro est très difficile à maintenir. Depuis l'ouverture du site, il y a déjà eu deux périodes de recrutement successives. Si les nouveaux venus ont apporté un nouveau souffle coté validation en aidant à la répartition des charges et une accélération notable des publications (j'en profite pour féliciter les nouveaux qui font un très bon boulot, on le dit trop rarement), la roue tourne et l'on finit irrémédiablement par avoir un essoufflement et retomber dans la situation initiale.

Fondamentalement, le souci au niveau du staff se situe dans le fait

• Qu'une partie des staffeux s'occupe aussi du dev. Ils ne peuvent donc par exemple valider à un rythme régulier parce qu'ils ont d'autres obligations qui fait que leur participation à la validation est potentiellement moindre ou en tous cas, variable.
• Une autre partie du staff s'occupe de la communication, idem.
• La partie restante se dédie complètement à la validation (c'est mon cas par exemple). Dans cette partie, certains membres sont absents et/ou inactifs.

Précisons que le passage de membre à staff implique une action des admins.

À cela, s'ajoute le constat que le système de la bêta ne fonctionne pas correctement (bien qu'il est très efficace quand c'est le cas) d'une manière générale.

Processus de validation actuel, pour information

Nota bene : certains éléments ici font l'objet d'autres ZEPs.

Dans l’état actuel des choses, voici comment le processus se déroule.

• Les auteurs et illustrateurs sont seuls intervenants de la partie rédaction. Il arrive qu'il y ait une interaction avec un validateur par MP à ce stade. Mais ce n'est pas généralisé.
• Une fois que le contenu a atteint un certain stade aux yeux des auteurs, il est mis, par le biais de la bêta, à disposition de la communauté pour que celle-ci émette des avis sur le contenu.
• La phase suivante est l'envoi en validation. NB : il arrive que le contenu soit à la fois envoyé en bêta et en validation.
• En validation, le contenu est en attente. Il peut s'écouler un certain temps avant qu'un validateur réserve le contenu. La réservation marquant le début du processus de validation.
• La date de publication des contenus est prise en charge par les validateurs (sujet : "calendrier de publication").
• La publicité des contenus récents est gérée automatiquement sur la page d’accueil, et manuellement par l’équipe de com, par le biais de messages sur les réseaux sociaux. Cette publicité peut être réitérée par la suite par de nouveaux messages sur les réseaux sociaux ou par le système des unes. Les lecteurs peuvent également contribuer à cet effort, au moyen des boutons de partage.
• Les retours après publication sont le fait des lecteurs, qui peuvent commenter les contenus, faire des remarques par le biais du bouton « Signaler une faute » ou encore contacter directement les auteurs par MP.

Proposition : validateur à la demande

Processus (changements marqués en gras)

1. Les auteurs et illustrateurs sont seuls intervenants de la partie rédaction.
2. Une fois que le contenu a atteint un certain stade aux yeux des auteurs, il est mis, par le biais de la bêta, à disposition de la communauté pour que celle-ci émette des avis sur le contenu.
3. CAS n°1 : à cette étape, un membre (autre que l'auteur) peut, par le biais d'un lien "Demander à valider ce contenu" présent dans le menu de gauche du tutoriel en bêta, requérir à devenir le validateur dudit contenu. Ce lien ouvrant une boite de dialogue indiquant s'il y a déjà eu des demandes de réservation et permettant de valider sa demande.
4. Le contenu est envoyé en validation. Dans la page de validation des contenus (coté staff, donc), une colonne du tableau indique, selon les contenus liés, les différents membres ayant requis la validation.
5. À coté du bouton submit de réservation, un autre bouton "Accorder la réservation" ouvrant une boite de dialogue permettant d'accorder la réservation à un membre. Le membre ayant réservé apparait normalement dans la cellule "Statut" du contenu concerné, avec date et heure de réservation. Comme présentement, un lien existe pour permettre au staff d'annuler la réservation (en cas de problème, manque de temps soudain,…).

Une fois accordé, le membre se voit octroyé - de manière automatique - des permissions et a accès, sur les forums, au forum dédié aux questions de validation (pas le forum staff, compte tenu de certaines discussions qui y figurent). En effet, il dispose dès lors de droits d'édition sur le tutoriel et est marqué comme étant le validateur de celui-ci. Il reçoit les MPs autos de mise à jour.

Il a, de même, accès à un lien "Mes validations" dans son menu utilisateur. Ce lien permet d'accéder à une page personnelle de validation où figurent les contenus (articles/tutoriels) dont il a la charge. Il s'agit ici essentiellement d'une version édulcorée de notre page de validation.

Permissions :

• Edition
• Accès à l'historique des versions
• Accès à l'historique de validation
• Activation de JSFiddle
• Envoi de MP
• Mettre le sujet en bêta, et le retirer
• Gestion des auteurs
• Refuser le contenu

Fin du statut temporaire de validation

En cas de publication, de révocation du droit par un staff ou de rejet du tutoriel ou de l'article, le membre-validateur perd ses permissions sur le contenu et revient de fait à son statut antérieur.

Contrairement à un staff, dont les droits et permissions ne sont pas liés aux contenus (ce sont des droits généraux, on peut valider/refuser des contenus, posts,…), les permissions accordés aux validateurs "à la demande" ne valent que pour le(s) contenu(s) concerné(s).

Conclusions :

L'idée de base serait donc de permettre au membre de valider un contenu propre, unique. Une validation par contenu, lui permettant de valider un tuto/article sans devoir forcément se coltiner d'autres contenus à valider sur le long terme.

Contrairement au recrutement d'un staff qui implique l'action des administrateurs et qui octroie des droits généraux, dans notre cas, ce système est toujours géré par le staff directement. Principe de sécurité : seul un staff peut octroyer ou révoquer un droit de validation. Le statut des membres qui interviennent sur un contenu en tant que validateur serait intermédiaire entre celui de membre et celui de staff (pouvoir de validation du contenu réservé, pas de droits de modération sur les forums, pas d'accès aux IPs, etc.).

Cela permettrait dans une certaine mesure (ce n'est pas une solution magique, elle doit être combinée) d'aider à répondre à un flux de contenus variable alors que le staff est lui fixe ou peu évolutif (même s'il a plutôt beaucoup évolué depuis la sortie du site, ça prend du temps) par essence.

Il s'agirait ainsi véritablement de permettre la validation par tuto/article plutôt que de favoriser la validation de tout contenu. L'élément clé réside ici dans la flexibilité et le statut temporaire (le membre ne veut pas devenir staff ou pas tout de suite pour X raison mais est prêt et a la possibilité d'aider pour un contenu donné, il peut aussi avoir un aperçu du partie du travail du staff, etc.).

Il y a clairement plusieurs incitants potentiels pour rejoindre le staff pour ceux qui en ont le temps et une motivation naissante, ceux qui n'ont pas forcément le temps sur le long terme peuvent aider sans être "limité" par le passage en validation, et ça rend la communauté plus dynamique aussi. C'est peut-être la pierre angulaire qui nous manquait sur le SdZ. Et si ce n'est pas une solution magique, bien utilisée, ça peut apporter un plus indéniable.

Avantages et inconvénients potentiels à long terme

Plusieurs avantages à long terme :

• La validation serait plus dynamique, la communauté plus intégrée au processus (et donc potentiellement plus de membres pour aussi guider de nouveaux auteurs)
• Cela permet d'éviter à un membre de devenir staff et valider du contenu qui ne l'intéresserait pas à la longue ou de se démotiver
• Cela permet au staff de constituer une liste de validateurs permanents
• Cela permet aux membres de s'intéresser à la validation et à les inciter à devenir staff pour aider
• Ce serait parfaitement intégré aux ZEP suggérées ci-dessous.
• Cela ouvre d'autres possibilités d'utilisation de la bêta, sous-exploitée actuellement, en la rendant plus dynamique, les membres faisant des retours pouvant jouer tour à tour le rôle de relecteur/correcteur puis de valider le contenu si ça traine trop.
• Cela évite des recrutements successifs. On en a déjà eu deux depuis la sortie du site et en l'état actuel, il faudrait de nouveau des renforts, plusieurs membres dans le staff étant inactifs/manquent de temps. Recrutements qui sont assez lourd à la longue.

Niveau inconvénient : un tel fonctionnement pourrait être lourd à terme, mais l'on aura le temps de voir venir et d'adapter le système (ou de revenir à quelque chose de plus classique, abandonner l'idée).

ZEPs liées

• ZEP-08 : Utilisation de git pour gérer les tutos et articles
• ZEP-16 : Page de proposition de corrections
• ZEP-18 : Amélioration de l'ergonomie de validation
• ZEP-20 : Relecture par les pairs
• ZEP-41 : Workflow éditorial
• ZEP-42 : Relever des passages dans un contenu

Révisions du document

Quelques remarques en vrac:

• Cet zep est un peu en conflit avec la zep-20, sur le passage concernant les choix des relecteurs:

  Le choix des relecteurs est discrétionnaire : le Staff se débrouille tout seul pour trouver des membres, il n'est pas possible de « candidater » pour devenir relecteur. Source: zep-20

Et dans cette zep la, il est écrit qu'on peut accorder la réservation à un membre.

• Si ils sont plusieurs membres-validateurs à valider le contenu, peuvent t-il voir les commentaires des autres membres validateurs ? ne vont t-il pas être influencé ? La zep-20 interdisait cet état de fait.

• Ont t-il un joli badge sur le site ?

Une question me taraude : si le validateur temporaire n’a pas les droits de publication, et si l’on se place dans l’hypothèse (fort probable au vu des pratiques actuelles) où un membre s’investit beaucoup dans la bêta, fait des retours sur tout et commente les mises à jour jusqu’à ce qu’il n’ait plus rien à ajouter (genre, n’importe quelle bêta prise en charge par Vayel), lorsque ce membre demande à avoir les droits de validation, que peut-il faire de plus que ce qu’il a déjà fait ?

Cette ZEP-ci pourrait rendre obsolète la ZEP-20 en ce que le membre souhaitant valider le contenu pourra à sa guise s'occuper de la relecture. Mais il s'agirait plutôt d'adapter la ZEP-20 en conséquence.

Dans l'hypothèse de la ZEP-20, le membre-validateur tiendrait là le rôle du validateur (staff) : il agira en tant que coordinateur des relecteurs s'il estime par exemple que, pour accélérer la validation, il faudrait se répartir les tâches. En ce sens, cette ZEP peut être combinée à la ZEP-20. Pendant la phase de relecture, l'auteur ignore dans ce cas aussi qui sont les relecteurs. Il sait simplement que tel membre est le validateur de son contenu, de la même façon (actuellement) qu'il sait que tel staff valide son contenu.

Bien que cette ZEP a été rédigée sur base de la situation actuelle, elle ne bloque pas systématiquement la ZEP-20. Mais effectivement, il faut revoir si l'approche de la ZEP-20 n'est pas opposée à celle-ci.

Si ils sont plusieurs membres-validateurs à valider le contenu, peuvent t-il voir les commentaires des autres membres validateurs ? ne vont t-il pas être influencé ? La zep-20 interdisait cet état de fait.

Cette ZEP ne permet d'accorder la validation qu'à un membre. Plusieurs membres peuvent se proposer mais la validation n'est accordée qu'à un seul membre. Je fais bien référence au membre-validateur/validateur "à la demande"/peu importe le nom sans utiliser le pluriel.

Ont t-il un joli badge sur le site ?

Pas d'objection sur ce point mais pas un badge qui laisserait penser qu'il a plus de droits que les membres (pas de "Validateur" par ex.), à la limite une "récompense" temporaire comme une mise à l'honneur. À discuter.

Une question me taraude : si le validateur temporaire n’a pas les droits de publication, et si l’on se place dans l’hypothèse (fort probable au vu des pratiques actuelles) où un membre s’investit beaucoup dans la bêta, fait des retours sur tout et commente les mises à jour jusqu’à ce qu’il n’ait plus rien à ajouter (genre, n’importe quelle bêta prise en charge par Vayel), lorsque ce membre demande à avoir les droits de validation, que peut-il faire de plus que ce qu’il a déjà fait ?

Je suis personnellement pour accorder le droit de publication (je ne vois pas de raison d'accorder le droit de refuser le contenu (action négative) et pas celui de publier (action positive)). Mais, comme cela a fait l'objet d'une remarque dans le sujet de suggestion, j'indique "à discuter".

Mais du coup, on est d’accord que la procédure de validation se résumerait alors à publier le contenu ?

Ont t-il un joli badge sur le site ?

Je dirais non : leur statut est temporaire et spécifique à un contenu, je ne vois pas trop l’utilité de les identifier partout sur le site.

Bah non, il devra

• Relire le contenu
• Le corriger (il faut les droits d'édition pour cela) sans avoir besoin de demander à être ajouté comme auteur
• Activer JSFiddle pour certains contenus (c'est une chose que seul un validateur peut faire)
• Refuser le contenu
• Mettre le sujet en bêta/la fermer, histoire de relancer la communauté
• Accéder à l'historique de validation si le contenu a déjà été antérieurement envoyé et refusé/validé.

Bref, au niveau de la validation, tous les pouvoirs d'un staff. Typiquement, le processus colle à celui d'un staff quand il publie un tuto. Bien entendu, 90% du travail sur le contenu est le même mais le but est justement de combler un manque de moyens/compétence dans le staff en prenant en charge l'ensemble du processus de validation (planification de la publication sur le forum privé, refus si estimé nécessaire, etc.) sans devoir devenir staff et valider du contenu qui n'intéresse pas le membre. Le gros du travail de validation se passe dans un échange, que ce soit dans un MP ou sur un sujet du forum bêta. T'as pas vraiment de bouton mystérieux ou autre.

Pour la question du badge, je suis aussi contre, notamment car ce statut n'est que temporaire. Aussi, ce badge est actuellement utile lorsqu'une modération sur le forum doit avoir lieue. Ici, l'utilisateur aura uniquement en charge la validation d'un seul contenu, ce qui ne nécessite pas de badge.

Une question me taraude : si le validateur temporaire n’a pas les droits de publication, et si l’on se place dans l’hypothèse (fort probable au vu des pratiques actuelles) où un membre s’investit beaucoup dans la bêta, fait des retours sur tout et commente les mises à jour jusqu’à ce qu’il n’ait plus rien à ajouter (genre, n’importe quelle bêta prise en charge par Vayel), lorsque ce membre demande à avoir les droits de validation, que peut-il faire de plus que ce qu’il a déjà fait ?

Aujourd'hui, très peu de membres réalisent ce travail. Je pense (et j'espère), que cette ZEP permettra de relancer la bêta, en pouvant potentiellement impliquer les membres dans le processus de publication, ce qui devrait être source de motivation.

Le badge, c'est franchement pas l'important. Que ce soit une petite récompense avec un badge amusant ou des remerciements dans les récap' (ma préférence), c'est le geste de remercier le membre (tant l'auteur que le validateur) qui compte et cela aura la même valeur de fidélisation.

Je suis pour qu'on accepte cette ZEP, qu'on regarde ce que ça donne et qu'on corrige les défauts au fur et à mesure (ce qui veut dire « abandonner l'idée si elle se révèle être pourrie »).

Pour moi la seule contrainte avant de partir là-dedans est d'ordre technico-organisationnel :

On peut le mettre auteur, ce qui permet, si je reprends la liste d'Arius,

• Relire le contenu
• Le corriger (il faut les droits d'édition pour cela) sans avoir besoin de demander à être ajouté comme auteur
• Activer JSFiddle pour certains contenus (c'est une chose que seul un validateur peut faire)
• ¿¿ Refuser le contenu ??
• Mettre le sujet en bêta/la fermer, histoire de relancer la communauté
• ¿¿ Accéder à l'historique de validation si le contenu a déjà été antérieurement envoyé et refusé/validé. ??

Est-ce assez pour tester la ZEP ?

(ce qui veut dire « abandonner l'idée si elle se révèle être pourrie »).

Ouaip.

Reste à déterminer effectivement si l'on peut donner les droits de validation sans passer la personne staff et ce, sans développement.

Si cette ZEP se révèle à terme trop compliquée à maintenir, il faudra agir en conséquence et abandonner l'idée. Le principe étant de faire le plus simple et efficace possible. Si cela n'est plus possible…

Perso je suis pour tester dès maintenant : on identifie des contenus et des validateurs non staff qui pourraient faire l'affaire. On prévient l'auteur de la démarche, on ajoute le valido temporaire en tant qu'auteur et on les laisse discuter (avec un validateur référant dans le MP). Et on voit comment ça se passe. À la fin il suffit de virer le validateur des auteurs. Si on fait ça pour 4-5 contenu on pourra avoir une bonne idée de l'intérêt a moindre coup.

Arius si ça te dis, go.

Yep, ThS a déjà prévu ça pour un tuto, reste 4.

Ha j'aime quand ça bouge ! Si ça marche je suis que nos dev préféré nous ferons des adaptations pour le généraliser.

C'est une idée tellement géniale que je ne comprends même pas qu'elle n'ait pas été mise en place à l'époque du SdZ (peut-être avait-elle été proposée cela dit, je n'en sais rien). Ça accélère, voir débloque, des publications, tout en désacralisant le rôle de staff/valido. Ça renforce encore un peu plus le credo "c'est la communauté qui produit le contenu". Bref, gros +1 pour l'expérimentation et les ajustements après coup.

Je pense pas, les permission sont testé avec if context['is_staff'] (par exemple: https://github.com/zestedesavoir/zds-site/blob/dev/zds/tutorialv2/views/views_published.py#L62)

Si l'expérience est concluante en ajoutant les personnes en auteur, je suis sûrs que vous nous trouverez un solution

C'est pas compliqué à faire, c'est juste qu'on ne peut pas du coup, le faire depuis la console d'admin directement.

Mode d'op' :

Ce sera fait "en deux temps". Dans un premier temps, des articles et "mini-tutos". Cela permettra d'avoir des premiers retours des cobayes ( ) dans les jours/semaines à venir (AMHA, c'est le cas le moins problématique). Dans un second temps, des tutos plus conséquents - point plus critique - par des cobayes disponibles (cas du tuto sur la trigono par ThS). Voir si la motivation diminue sur la durée, etc.

@Hugo si les permissions sont testés comme ça c'est que c'est mal codé. is_staff est juste un booléen qui permet de se connecter à l'interface d'administration (cd la doc).

The good way pour faire ça techniquement sans coder ça comme des sauvages c'est ça. Du coup ça évite de changer notre code, on a juste à rajouter quelques conditions.

Je suis entièrement d'accord avec toi, on fait comme ça dans pas mal d'endroit mais il en reste encore des is-staff (un peu prés 20 selon mon grep).