Há uns dias na lista de mail mubi-core (“MUBi-core:19177”), lancei algumas questões sobre a operacionalização das categorias/grupos do fórum.
Alguns desses pontos esclareceram-se, mas outros ficaram ainda em aberto por afinar.
Transponho para aqui os 3 pontos que acho estarem ainda em aberto.
Hesito entre lançar 3 tópicos diferentes ou juntar os 3 pontos num tópico apenas. Como estão muito relacionados, junto-os todos neste tópico.
Importante: o objectivo deste tópico não é discutir qual a estrutura de categorias/grupos concreta que o fórum terá (isso já foi amplamente discutido noutros tópicos). O foco é, dada uma determinada estrutura de categorias/grupos, como assegurar que ela é fácil de compreender e usar.
- Como é que um utilizador do fórum sabe qual a visibilidade (quem pode ler o que eu escrevo?) de determinada categoria que está a usar?
Há aqui 2 sub-questões:
a) a categoria é visível publicamente ou só a um grupo restrito?
b) no caso de visível a grupo restrito, que grupo(s) é esse?
Aparentemente, o discourse já distingue categorias de visibilidade pública de categorias de visibilidade restrica a grupo(s) com um símbolo, como é evidente neste exemplo:
Mesmo assim, este símbolo não chega pois, no caso de categorias com este símbolo, eu não consigo directamente inferir qual o grupo que pode ler.
Isso faz grande diferença, pois há grupos privilegiados (e.g. grupo de trabalho) e grupos de massas (e.g. grupo dos sócios). Quando eu estou prestes a publicar nova mensagem com conteúdo mais privado, na dúvida quererei ter forma de facilmente confirmar qual grupo de utilizadores vai poder ler a mensagem.
Por isso, em complemento ao ícone que o discourse já apresenta (para distinguir entre cat. pública vs vísivel a grupo), acho que devemos assegurar que, na descrição de todas as categorias, temos uma linha simples a indicar quem pode ler dessa categoria. Algo como “Visível a: público/grupo X”
Atenção que neste momento isso ainda não acontece.
- No caso de categorias de acesso restrito a grupo, um membro do grupo consegue consultar a lista de outros membros do mesmo grupo?
Notem que no modelo anterior de trabalho sobre os google groups, isto era impossível para os membros que não fossem administradores da lista de email.
Pessoalmente, acho que:
- no caso do grupo Sócios, não faz sentido permitir-se consultar a lista de sócios
- no caso de grupos de trabalho, é muito desejável que qualquer membro do grupo (e não apenas o administrador/moderador) possa, a qualquer momento, saber quais são os outros membros - por transparência
O discourse suporta isto de alguma forma (para os grupos de trabalho)?
Caso não suporte, uma solução possível é ter essa informação mantida num post da categoria em causa, que algum coordenador tentaria manter actualizada.
O que acham?
- Pretendo juntar-me a determinado grupo. Que procedimentos devo seguir/quem devo contactar?
O @joaopferreira já respondeu parcialmente a isto:
Se fores
sócio, recebeste um convite que te adicionou automaticamente ao grupo
de sócios. Se fores sócio e quiseres fazer parte da core, basta
contactar o utilizador @MUBi, através de mensagem privada por exemplo. Mas o mail [email protected] estará sempre funcional.
Vejo aqui 2 aspectos por limar:
a. Do que percebi, o procedimento sobre como pedir acesso a um grupo de trabalho ainda não está explicado em nenhum lado na documentação (FAQ, ou outro). Devia estar, certo? Onde?
b. Parece-me desejável que a entrada/saída de elementos a cada grupo de trabalho seja gerida pelo coordenador desse grupo, não por algum elemento central que gere os membros de todos os grupos.
Exemplo: se alguém quer juntar-se ao projecto X, convém que o coordenador (ou mesmo o grupo de trabalho todo) i) possam discutir/decidir se há algum impedimento à entrada desse membro naquele grupo; ii) possam saber que há novo membro no grupo de trabalho (ou seja, a entrada no grupo de trabalho não ser silenciosa - nem que seja para haver uma boa-vinda por parte dos outros elementos).
Tentando concretizar, o modelo que me parece mais desejável:
Cada grupo de trabalho ter um utilizador especial que gere o grupo (tal como no modelo dos googlegroups, havia uma conta geral do grupo, que geria a lista de mail). Essa conta seria gerida por alguém do grupo de trabalho (e.g. o coordenador), que teria as credenciais para tal.
Para pedir entrada em determinado grupo, o sócio enviaria mensagem privada para esse utilizador especial (ou email para o endereço de email do projecto).
O adicionar do novo membro seria feito pelo gestor do grupo.
Já agora, este ponto começou a ser discutido entre o JPF e eu na mubi-core. Transcrevo para abaixo a discussão, para a continuarmos por cá.
Como vêem do meu texto acima, eu discordo da opinião do JPF: apesar da base de confiança subjacente ao funcionamento dos grupos de trabalho, é importante que haja controlo sobre a entrada de membros no grupo de trabalho.
Para que i) haja oportunidade do grupo confirmar que aceita a entrada do novo membro (não há incompatibilidades); ii) o grupo possa saber que há novo membro.
- No caso das categorias relativas a grupos de trabalho, é possível passar a gestão dos membros desse grupo para as mãos de alguém do grupo de trabalho (e.g. o coordenador do projecto)?
JPF: Não diretamente, mas a solução é simples. Um coordenador do grupo fica como moderador do fórum.
Penso que faria mais sentido que a entrada de elementos fosse gerida por alguém do grupo de trabalho, em vez de gerida por alguém da Core que pode não pertencer ao grupo de trabalho.
Por exemplo: as boas vindas após a inclusão da nova pessoa fazem-se no grupo de trabalho; se quem adiciona a pessoa ao grupo não pertencer ao grupo, as boas vindas tornam-se difíceis.
JPF: Na core funcionamos à base da confiança. Eu por exemplo sou admin. mas nem
sequer toquei em nada referente aos grupos de trabalho. Não sei quem pertence a quê. Limitei-me, a pedido do Bernardo, a adicionar a lista de membros à BtS. Como sei Barreto que criaste a SdB vou-te adicionar como moderador do fórum, ficas logo com acesso total sobre quem deve ou não
pertencer ao grupo SdB.
O que acham?
