Dividir un sitio en dos partes

Tengo un sitio, lists.tssi.com. Actualmente admite dos comunidades de Discourse esencialmente independientes (migradas de Mailman), gestionadas mediante grupos y categorías. Llamémoslas x e y.

Quiero dividirlo para que los dos grupos sean completamente independientes. (Sí, eso significa más trabajo para mí, pero no me importa). La razón principal para hacer esto es que quiero abrir ambas comunidades a lectores que no sean miembros, pero creo que sería más fácil si fueran completamente independientes. No creo que las personas de la comunidad X quieran leer mucho sobre lo que sucede en la comunidad Y, aunque son similares. (Ambos son sitios orientados a deportes universitarios).

Una forma de hacerlo sería definir los sitios como x.tssi.com e y.tssi.com y otra forma sería definir los sitios como x.lists.tssi.com e y.lists.tssi.com.

De cualquier manera, lists.tssi.com actuaría como una puerta de enlace a las dos comunidades, con una puerta de entrada común en Nginx.

Por lo que puedo decir, cualquiera de los dos métodos debería funcionar en un solo contenedor, clonando la base de datos para que sean completamente independientes. (Configuré mi servidor de prueba utilizando el método x.tssi.com e y.tssi.com, así que estoy seguro de que funciona, tengo un poco menos de seguridad sobre el enfoque x.lists.tssi.com e y.lists.tssi.com, aunque creo que podría ser más fácil de entender para mis usuarios y admitiría más fácilmente comunidades adicionales que puedan agregarse).

Una vez que las divida, los usuarios que forman parte de una comunidad serán eliminados de la base de datos de la otra comunidad o simplemente se marcarán como inactivos. También puedo eliminar todas las publicaciones y categorías del otro sitio.

¿Alguna recomendación sobre qué camino seguir? ¿Algún problema a tener en cuenta?

1 me gusta

¿Por qué no conservar un sitio central con usuarios pero sin contenido que sirva discourse connect (SSO) a los dos sitios subordinados?

Probablemente conservaría el sitio central con todos sus usuarios, haría dos copias completas más como x e y, eliminaría el contenido que no quisiera de ambas para crear la división, y haría que se refirieran al sitio ‘principal’ para iniciar sesión.

También eliminará la confusión de inicio de sesión para los usuarios que puedan estar en ambas listas.

1 me gusta

¿Cuáles son los beneficios de un entorno SSO como ese? ¿Cuáles son los inconvenientes?

No creo que haya ningún usuario en ambas listas aparte de mí. Fueron sitios separados de Mailman durante muchos años, y la mayoría de los usuarios todavía se basan principalmente en el correo electrónico.

Incluso la necesidad de tener direcciones de correo electrónico separadas para publicar por correo electrónico en cada categoría dentro de esa comunidad es confusa para algunos de ellos, pero no veo una manera de evitarlo. Los animo a usar la interfaz web, pero tal vez el 5% lo hace, 3 meses después del cambio.

Mi objetivo es ampliar la participación haciendo que ambas comunidades sean buscables y legibles en la web. Me parece que mantenerlas separadas podría funcionar mejor para atraer a aquellos que quieren discutir sobre el equipo X pero no sobre el equipo Y.

No tengo prisa, el verano es la época de menor actividad para una lista orientada a deportes universitarios, las cosas comenzarán a mejorar en agosto cuando comiencen los entrenamientos de fútbol americano de otoño. Así que tengo tiempo para pensar qué enfoque es mejor para las comunidades.

Decidí usar lists.tssi.com para el sitio de acceso y x.tssi.com e y.tssi.com para las comunidades separadas en lugar de x.lists.tssi.com e y.lists.tssi.com. No pude hacer que estos últimos funcionaran, posiblemente un problema de configuración de nginx, seguía redirigiendo las solicitudes de x.lists.tssi.com o y.lists.tssi.com a lists.tssi.com en lugar del servidor Discourse.

Pero puedo hacer que el otro funcione, y una solución que funciona es mejor que una que no. :slight_smile: