J’ai un site, lists.tssi.com. Il prend actuellement en charge deux communautés Discourse essentiellement indépendantes (migrées de Mailman), gérées à l’aide de groupes et de catégories. Appelons-les x et y.
Je veux les séparer afin que les deux groupes soient entièrement indépendants. (Oui, cela signifie plus de travail pour moi, mais cela me convient.) La raison principale est que je veux ouvrir les deux communautés à la lecture par des non-membres, mais je pense que ce serait plus facile si elles étaient entièrement indépendantes. Je ne pense pas que les membres de la communauté X veuillent lire beaucoup de choses sur ce qui se passe dans la communauté Y, même si elles sont similaires. (Ce sont deux sites axés sur les sports universitaires.)
Dans tous les cas, lists.tssi.com servirait de passerelle vers les deux communautés, avec une porte d’entrée commune dans Nginx.
D’après ce que je peux voir, l’une ou l’autre méthode devrait fonctionner dans un seul conteneur, en clonage la base de données afin qu’elles soient entièrement indépendantes. (J’ai configuré mon serveur de test en utilisant la méthode x.tssi.com et y.tssi.com, donc je suis sûr que cela fonctionne, je suis un peu moins sûr de l’approche x.lists.tssi.com et y.lists.tssi.com, bien que je pense que cela pourrait être plus facile à comprendre pour mes utilisateurs et prendrait mieux en charge les communautés supplémentaires qui pourraient être ajoutées.)
Une fois que je les aurai séparées, les utilisateurs qui font partie d’une communauté seront soit supprimés de la base de données de l’autre communauté, soit simplement marqués comme inactifs. Je pourrais également supprimer tous les messages et catégories de l’autre site.
Des recommandations sur la façon de procéder ? Des pièges à connaître ?
Pourquoi ne pas conserver un site central avec les utilisateurs mais sans contenu servant de connexion Discourse (SSO) aux deux sites subordonnés ?
Je conserverais probablement le site central avec tous vos utilisateurs, j’en ferais deux autres copies complètes, x et y, supprimerais le contenu que je ne voulais pas des deux pour créer la séparation, et les ferais référencer le site « principal » pour la connexion.
Cela éliminera également la confusion de connexion pour les utilisateurs qui pourraient être sur les deux listes.
Quels sont les avantages d’un environnement SSO comme celui-ci ? Quels sont les inconvénients ?
Je ne pense pas qu’il y ait d’utilisateurs sur les deux listes à part moi. C’étaient des sites Mailman séparés pendant de nombreuses années, et la plupart des utilisateurs sont encore principalement basés sur l’e-mail.
Même la nécessité d’avoir des adresses e-mail distinctes pour publier par e-mail dans chaque catégorie au sein de cette communauté est déroutante pour certains d’entre eux, mais je ne vois pas d’autre solution. Je les encourage à utiliser l’interface web, mais peut-être que 5 % le font, 3 mois après le changement.
Mon objectif est d’élargir la participation en rendant les deux communautés consultables et lisibles sur le web. Il me semble que les maintenir séparées pourrait mieux fonctionner pour attirer ceux qui veulent discuter de l’équipe X mais pas de l’équipe Y.
Je ne suis pas pressé, l’été est la période creuse pour une liste axée sur le sport universitaire, les choses vont commencer à s’accélérer en août lorsque les entraînements de football d’automne commenceront. J’ai donc le temps de réfléchir à la meilleure approche pour les communautés.
