Présentation de "Changements à venir", un système pour gérer les nouvelles fonctionnalités et les modifications des fonctionnalités existantes dans votre communauté

[lindsey (Lindsey Fogle)]

Alors que nous continuons à améliorer Discourse, nous avons créé une nouvelle page de configuration « Changements à venir » pour aider les administrateurs à comprendre les modifications qui arrivent sur Discourse et à gérer la manière dont ces changements sont mis en œuvre dans leur communauté. Nous croyons que ce système nous aidera à continuer d’améliorer Discourse de manière sûre et transparente.

Dans ce sujet, nous expliquerons comment fonctionne ce nouveau système et comment l’utiliser pour introduire en toute sécurité de nouvelles fonctionnalités et d’autres modifications dans votre communauté.

Aperçu du fonctionnement des Changements à venir

Alors que nous travaillons sur de nouvelles fonctionnalités ou d’autres modifications, nous les ajouterons à la page de configuration des Changements à venir à /admin/config/upcoming-changes. Chaque changement inclura une description, un statut, un indicateur des utilisateurs concernés, et les utilisateurs (le cas échéant) pour lesquels il est activé dans votre communauté.

Selon le statut du changement, vous pouvez décider de l’activer ou de le désactiver pour votre communauté — du moins temporairement, car certains changements seront éventuellement activés de manière permanente.

Désactiver temporairement un changement vous donne le temps de résoudre les personnalisations de site impactées, les processus, etc., d’informer votre base de membres du changement, ou de déléguer à certains groupes de membres pour les tests.

Analyse d’un Changement à venir

Analysons un Changement à venir et définissons les informations que vous verrez dans chaque section.

1 - Nom et description

Le nom et la description vous donnent une brève explication du changement et lient vers le sujet Meta correspondant pour plus d’informations et un lieu pour recueillir les retours.

2 - Statut

Le statut communique sa position dans le cycle de développement. Le statut influence directement si le changement est opt-in (c’est-à-dire désactivé par défaut, mais vous pouvez l’activer), opt-out (c’est-à-dire activé par défaut, mais vous pouvez le désactiver), ou forcé (c’est-à-dire activé, et vous ne pouvez pas le désactiver).

Nous utilisons les statuts suivants dans les Changements à venir :

• Experimental : Un changement potentiel en développement/test précoce qui est susceptible d’évoluer rapidement, ou peut être supprimé si nous mettons fin à l’expérience (auquel cas il passera au statut Inactive ; voir ci-dessous). Vous pouvez opter pour les changements Experimental pour les tester.
• Alpha : Un changement testé qui est sûr à utiliser, bien qu’il puisse y avoir quelques mises à jour mineures de son design ou de sa fonctionnalité. Vous pouvez opter pour les changements Alpha pour les utiliser en avance.
• Beta : Un changement testé qui est sûr à utiliser, et qui ne devrait pas changer beaucoup avant de passer au statut Stable ou éventuellement Permanent.
  • Pour la plupart des sites sur notre hébergement, et pour les sites auto-hébergés, les changements Beta sont automatiquement activés pour tout le monde (si vous ne l’avez pas activé précédemment), mais vous pouvez toujours opter pour la désactivation.
• Stable : Un changement terminé^[1], mais qui reste opt-out (c’est-à-dire que les administrateurs peuvent le désactiver). Les administrateurs seront avertis sur leur tableau de bord lorsqu’ils ont désactivé un changement Stable.
• Permanent : Un changement qui a terminé ses tests, et qui est forcé (c’est-à-dire que les administrateurs ne peuvent pas le désactiver). Les changements permanents n’apparaîtront plus dans la liste des changements à venir, ils seront affichés sur la page /admin/whats-new.
• Inactive : Une expérience abandonnée. Vous ne pouvez pas opter pour.

Parfois, les changements passeront linéairement par ces statuts (c’est-à-dire commencer en Experimental et finir en Permanent), mais pas toujours. Certains changements peuvent être introduits avec le statut Alpha ou Beta, et certains se termineront avec le statut Stable. Les changements de type « valeur par défaut du paramètre du site » ne seront pas déplacés vers Permanent, car ils ne modifient que la valeur par défaut d’un paramètre existant.

Il n’y a pas de délai fixe pour qu’un changement particulier passe d’un statut à un autre, mais les administrateurs seront notifiés lorsque :

• Un nouveau changement est disponible pour être testé
  • Ces notifications sont envoyées au maximum une fois par semaine pour éviter la fatigue des notifications. Si vous préférez ne pas recevoir ces notifications, vous pouvez les désactiver dans /my/preferences/notifications
• Un changement a été activé automatiquement
• Lorsque vous avez désactivé un changement qui sera bientôt forcé
  • Cela sera affiché comme un avertissement sur le tableau de bord de l’administrateur

3 - Utilisateurs concernés

Le tag des utilisateurs concernés décrit quels utilisateurs de votre communauté peuvent voir ou interagir avec le changement d’une manière ou d’une autre. Pour simplifier — qui pourrait remarquer ce changement ? Il existe plusieurs types d’utilisateurs concernés :

• Admins : Le changement n’est visible que par les administrateurs.
• Staff : Le changement n’est visible que par les administrateurs et les modérateurs.
• All members : Le changement est visible par tous les membres de votre site.
• Developers : Dans de rares cas, un changement ne sera perceptible que pour ceux qui interagissent avec le code dans le noyau, les thèmes ou les plugins.

Type d’impact

Un sous-ensemble des utilisateurs concernés, et non affiché dans la liste, est le type d’impact. Le type d’impact décrit comment le changement affectera votre communauté dans un sens large :

• Feature : Le changement introduit une nouvelle fonctionnalité ou une nouvelle fonctionnalité à votre communauté, ou modifie une fonctionnalité existante.
• Site setting default : Le changement modifie la valeur par défaut d’un paramètre de site existant. Les administrateurs qui ont déjà modifié le paramètre hors de son ancienne valeur par défaut ne seront pas affectés. Aucun avertissement sur le tableau de bord de l’administrateur ne sera affiché pour ce changement une fois qu’il atteindra le statut Stable.
• Other : Tout autre changement qui ne rentre pas dans les catégories ci-dessus.

4 - Activé pour…

Ce menu déroulant est là où vous, en tant qu’administrateur du site, pouvez contrôler si et comment introduire ce changement dans votre communauté en l’activant pour :

• No one : Désactive le changement pour tout le monde sur le site.
• Everyone : Active le changement pour tout le monde sur le site, y compris les utilisateurs anonymes. Lorsque le changement est automatiquement activé (généralement au statut Beta), ce sera pour Everyone.
• Staff only : Active le changement pour le personnel du site (c’est-à-dire les administrateurs et les modérateurs).
• Specific groups : Active le changement pour le(s) groupe(s) sélectionné(s).

Certains changements à venir peuvent avoir des options « Activer pour » restreintes. Les options disponibles dans le menu déroulant « Activé pour » sont déterminées par la configuration du changement. Par exemple, certains changements ne permettent peut-être que les options Everyone et No one, car des tests limités par groupe seraient irréalisables pour le changement.

---

Pour l’instant, nous avons déplacé la plupart des changements Experimental de /admin/config/experimental vers les Changements à venir, et vous commencerez bientôt à voir de nouvelles mises à jour arriver ici. Nous avons hâte d’entendre parler de l’impact que cela aura dans votre communauté, et nous accueillons toute question ou retour !

---

1. Dans la mesure où un logiciel peut être considéré comme terminé ! ↩︎

[NateDhaliwal]

Je suis curieux - comment contrôle-t-il la manière dont le changement est déployé ? Peut-il être modifié après l’introduction de la fonctionnalité ? Merci.

[merefield (Robert)]

Fonctionnalités natives de feature flags ! Très bien

Ce serait formidable d’avoir une API pour les plugins.

[Canapin (Coin-coin le Canapin)]

C’est une fonctionnalité attendue depuis longtemps ! Merci !

[darkpixlz (Pyx)]

C’est super, avoir la possibilité de changer les drapeaux comme ça est incroyable pour les personnes à la pointe comme moi, surtout lors du développement d’un thème.

Cependant, « changements à venir » est-il vraiment le meilleur nom pour cela ? Par exemple, HomeAssistant utilise « labs » et beaucoup d’autres personnes utilisent des choses comme « expériences » qui semblent mieux que changements à venir.

[lindsey (Lindsey Fogle)]

@NateDhaliwal

Je suis curieux : comment le déploiement du changement est-il contrôlé ?

Vous serez informé des nouvelles fonctionnalités tant qu’elles seront dans un état où vous pourrez l’essayer en avant-première (opt-in) et la désactiver temporairement pour corriger tout problème causé par le changement (opt-out). Si un changement doit devenir permanent (ce qui signifie que vous ne pouvez pas vous désinscrire) et que vous l’avez actuellement désactivé, nous vous en informerons.

Cette section le décrit un peu plus en détail :

@lindsey

Parfois, les changements évolueront linéairement à travers ces statuts (c’est-à-dire qu’ils commenceront en Expérimental et se termineront en Permanent), mais pas toujours. Certains changements peuvent être introduits avec le statut Alpha ou Beta, et certains se termineront avec le statut Stable (s’ils ne sont pas forcés).

Il n’y a pas de délai fixe pour le temps qu’il faudra à un changement particulier pour passer d’un statut à un autre, mais les administrateurs seront informés lorsque :

• Un nouveau changement est disponible à l’essai
• Un changement a été activé automatiquement
• Lorsque vous avez désactivé un changement qui sera bientôt forcé

@darkpixlz

Est-ce que « changements à venir » est vraiment le meilleur nom pour cela, cependant ?

Pour l’instant, vous ne voyez que les changements expérimentaux car nous les avons migrés de la zone des paramètres vers Changements à venir, mais à l’avenir, il y aura également des mises à jour non expérimentales ici. Donc, « laboratoires » ne semble pas exact pour la façon dont nous utilisons ce système.

[martin (Martin Brennan)]

@merefield

Ce serait formidable d’avoir une API pour les plugins.

Les plugins peuvent déjà utiliser ce système. L’OP n’entre pas dans les détails techniques, mais il n’y a pas grand-chose à faire pour ajouter un changement à venir.

Le résumé rapide est le suivant :

• Ajouter un paramètre de site avec hidden: true et client: true

• Ajouter une description pour le paramètre dans server.en.yml

• Ajouter éventuellement une capture d’écran dans public/images/upcoming_changes/SETTING_NAME.png

• Ajouter les métadonnées upcoming_change au paramètre, qui ressemble à ceci :

# upcoming_change       - Métadonnées supplémentaires avec les options suivantes à afficher sur la page /admin/config/upcoming-changes :
#                          - status: experimental | alpha | beta | stable
#                          - impact: deux parties séparées par une virgule - feature|other , staff|admins|moderators|all_members|developers
#                          - learn_more_url: une URL pour plus d'informations

Cependant, la mise en garde est que nous n’avions pas vraiment l’intention que les développeurs de plugins tiers utilisent ce système, c’était surtout pour nos propres besoins. Peut-être qu’avec le temps, nous pourrons réfléchir davantage à ce cas d’utilisation.

[noahl (Noah Lovell)]

J’adore ça ! Merci

Serait-il possible d’avoir un lien/raccourci vers le paramètre applicable si nécessaire ? Par exemple, l’écran de démarrage personnalisé comporte des paramètres supplémentaires qui doivent être configurés pour qu’il fonctionne (téléchargement du SVG) - mais vous devez activement aller les chercher. Il serait utile de les avoir à côté de l’endroit où il est activé.

[martin (Martin Brennan)]

Oui, en effet ! Je travaille sur ce changement maintenant, il devrait être disponible d’ici un jour ou deux, je prendrai note de déployer votre site hébergé afin que vous receviez la mise à jour

Édit : Fait !

[sniper756]

J’aimerais savoir comment afficher les « changements à venir » dans le panneau d’administration pour une installation Discourse auto-hébergée ?

@lindsey

[martin (Martin Brennan)]

Nous avons toujours ceci masqué derrière un paramètre de site global enable_upcoming_changes qui est caché, vous pouvez donc l’activer dans la console rails de votre site avec rails c. Finalement, nous allons supprimer ceci et vous n’aurez plus à le faire.

[sniper756]

D’accord, merci, alors je vais attendre ~~~~~~~~~~

[ToddZ]

Je ne suis pas sûr que ce soit clair : l’élément de menu pour les Changements à Venir n’est pas encore actif, mais …

reformulation :
Si vous n’avez pas encore l’élément de menu, vous pouvez toujours voir la section Changements à Venir en allant sur [votre_forum]/admin/config/upcoming-changes

[martin (Martin Brennan)]

Il devrait l’être, vous ne le voyez pas ici ?

Hébergez-vous vous-même ? Si oui, vous devrez également définir enable_upcoming_changes (qui est un paramètre caché) sur true. Nous prévoyons de supprimer ceci dans un avenir pas si lointain une fois que nous serons absolument certains que le système est stable.

[Moin]

Y a-t-il une raison pour laquelle la plupart des paramètres du site pour les changements à venir sont masqués, mais que enable_auto_grid_images ne l’est pas ?

[martin (Martin Brennan)]

@Moin

enable_auto_grid_images

Non, juste un oubli, corrigé ici :

FIX: Hide enable_auto_grid_images site setting (#38046)

[ToddZ]

Oui, j’héberge moi-même, comme sniper756.
« n’est pas encore en ligne » n’était peut-être pas la meilleure formulation ; je vais modifier.

[Moin]

Aujourd’hui, je pensais qu’il serait pratique de pouvoir trier les modifications par statut : d’abord les bêta, puis les alpha, et enfin les expérimentales. Je sais que je peux filtrer par ce critère, mais j’aime voir la liste complète ; je trouve simplement les modifications plus ou moins intéressantes selon leur statut.

[martin (Martin Brennan)]

Oui, c’est logique. J’ai aussi pensé à ajouter une option de tri basée sur la date d’apparition du changement sur votre site… j’ajouterai les deux

[khenmu (John Sweeney)]

Ajout fantastique !

Merci pour cela.