En réalisant l’exercice de création de mes fiches de services, je suis tombé sur un petit casse tête.
J’ai un service « peertube » public qui permet, sans compte, de consulter des videos, mais dont l’enregistrement de compte est fermé. Comme un Youtube utilisé sans compte.
=> service.registration =None/Free/Closed?
Je m’interroge sur la nécessité de séparer : registration status : open/close
Et la nécessité d’un compte / ou pas
Peertube et Mastodon et Mobilizon ne nécessite pas de compte pour qui veut juste lire. Mais il est nécessaire pour qui veut interagir sur le service.
Le principe de la propriété service.registration est d’informer de l’existence d’une gestion de comptes et de qui peut en créer un. Du coup, ça ne dit pas à quoi sert le compte. Heureusement, on peut espérer logique qu’un compte permet l’accès aux fonctionnalités complètes du service.
La valeur Member indique que la création de compte est réservée à un groupe restreint de personnes. Les conditions d’accès à ce groupe sont librement fixées par le chaton. Ainsi, une association peut en restreindre l’accès à ses adhérents. Un chaton familiale peut en restreindre l’accès aux membres de la famille et/ou aux amis. Et en capillotractant encore un peu plus, on peut considérer que ton chaton restreint ton service à toi tout seul.
service.registration = Member
Dans ton cas, c’est clairement limite car alors quel est le service ? Pas de permettre aux gens de partager des vidéos. Seulement d’accéder à ta sélection de vidéos. Ce cas est très différent et alors le remplissage pertinent serait :
service.registration = None
Pour l’instant, je ne vois pas mieux. Je propose d’aborder la question lors de la prochaine réunion du groupe de travail. À suivre
Après avoir échangé ce matin lors du GT stats.chatons.org, on est arrivé à la conclusion suivante : ton peertube « public » n’est pas un service logiciel (au sens où tu ne fournis pas l’accès à un logiciel à des utilisateur⋅ices) et donc dans ce cas, il n’est pas pris en compte pour stats.chatons.org
S’est posée la même question pour https://framatube.org/ et https://framablog.org/ : ce sont bien des espaces en ligne de diffusion de contenus, mais ce ne sont pas des services logiciels.
On en est arrivé à la conclusion qu’un site web diffusant des contenus ne peut être considéré comme un service dans le cadre du collectif CHATONS car on ne fournit pas l’accès à un logiciel, seulement à une interface permettant la consultation de contenus.
Du coup, pas de fiche service.properties à réaliser dans ce cas-là.
En revanche le service https://framadrive.org/ est certes fermé aux inscriptions mais il y a de nombreu⋅ses utilisateur⋅ices qui y ont une activité et dans ce cas, ça me semble pertinent de le faire apparaître sur stats.chatons.org pour avoir les métriques associées.
C’est exactement le même problème avec mon service de cloud. Lors de la migration, j’avais plus assez de place pour garantir les inscriptions (j’inscris les gens quand je suis sûr de pouvoir fournir les 20 Go), donc je les ai fermées en attendant.
Mais c’est prévu d’être rouvert prochainement, juste le temps de supprimer les comptes fantômes (j’envoie un mail avant pour savoir si c’est OK pour la suppression).
Autre exemple bizarre : ma forge Gitea n’est techniquement pas ouverte au public, mais si quelqu’un me demande, je lui ouvrirais un compte dessus
Je l’ai pourtant recensé sur stats.chatons.org pour indiquer qu’elle existe.
Les services proposés et auxquels on peut souscrire (vitrine = chatons.org)
Les services qui fonctionnent, même si ont ne peut plus y souscrire (salle machine = https://stats.chatons.org)
En l’occurrence, framadrive disposerait bien d’une fiche, mais indiquant que les inscriptions sont closes (ce critère étant le discriminant faisant disparaitre un service de la vitrine - je cogite au workflow pour construire la vitrine à partir de stats.chatons.org)
Bonjour!
En tant que participant au GT Stats Chatons, je me fais l’émissaire de notre proposition, un grand merci à @Cpm pour avoir intégré les modifs dans le code et les exemples.
Pour les fiches services, il existe dorénavant un nouveau champ obligatoire : service.registration.load
pouvant prendre la valeur open ou full.
la valeur open indique que le service est ouvert et qu’on peut s’y inscrire et/ou l’utiliser, la valeur full permet d’indiquer que le service existe et fonctionne mais n’est pas en capacité d’accueillir des nouveaux.
# Capacité à accueillir de nouveaux utilisateurs (un parmi {open,full}, obligatoire).
service.registration.load =
Tous les modèles de services contiennent désormais cette information , et le linter de stats.chatons.org vous indiquera qu’il faut remplir cette information.
Merci d’avance pour le remplissage de cette nouvelle entrée et n’oubliez pas de jeter un oeil sur le changelog pour voir tous les changements faits ou a venir!
Je suis en train de mettre à jour les .properties d’ARN, sur la partie registration je suis embêté…
La plupart de nos services nécessitent d’abord d’adhérer, donc a priori Member, mais pour nous il ne s’agit pas de restreindre à un groupe de personne. Je veux dire c’est assez différents des EEDF qui ont un chaton pour leurs adhérents et adhérentes, ces personnes n’adhèrent pas aux EEDF pour accéder aux services.
A contrario, chez ARN la plus grande partie de nos membres adhérent pour accéder à un ou plusieurs services. La politique d’ARN c’est de dire qu’on ne fait pas du cloud (au sens le cloud c’est l’ordinateur d’un autre), parce que chaque membre détient un pouvoir décisionnaire sur l’asso qui possède la machine sans-nuage.fr.
Par ailleurs, nous proposons du drive pour asso, des VPN, des VPS qui en plus de l’adhésion nécessitent de payer un abonnement mensuel car ces services ont un vrai coût matériel (on a environ 600€/mois de dépenses sans parler d’amortissement). Personnellement, j’ai beaucoup de mal à noter « Client » dans le sens où:
chaque personne est membre de l’asso. Si les services tombent ce sera une faute collective. Chacun et chacune est invitée à prêter un coup de main si elle le peut, par exemple en donnant son avis à l’AG, en venant dire coucou lors d’une réu ou d’un atelier, en parlant de nous, en proposant son aide.
chez nous on ne parle jamais de client on parle de membre et les raisons sont nombreuses, notamment on ne souhaite pas renforcer l’idée d’un modèle client/fournisseur et le lot d’exigences à sens uniques qui peuvent accompagner cette posture.
on n’est tout juste à l’équilibre et on est à but non lucratif
ARN ne tourne qu’avec du bénévolat
Bref du coup, je ne nous reconnaît pas dans ces termes et dans ces définitions: None, Free, Member, Client.
Ce n’est pas clair pour moi ce que veulent dire les éventuelles associations suggérés dans les fichiers « Free,Member » est-ce que ça veut dire que c’est gratuit mais restreint, ou alors qu’une part est gratuite et l’autre réservé à un public restreint ?
Personnellement, je serais plus à l’aise que le terme « client » soit remplacé par « Subscription ». ET peut être envisager d’avoir « Restricted » et « Member » OU si on veut de la retro compatibilité « Member » et « MembershipOpen »
L’idée du champ service.registration est de pouvoir énoncer la liste des profils pouvant s’inscrire (créer un compte) :
None : pas d’inscription (inutile pour utiliser le service) ;
Free : inscription ouverte à tout le monde (ici, Free as in freedom) ;
Member : inscription restreinte aux membres (la notion de membre pouvant être très relative, par exemple, une famille, un cercle d’amis…) ;
Client : inscription payante et soumise à facturation.
Peut-être serait-il nécessaire d’ajouter ces définitions dans les fichiers de référence.
Reconnaissons que « Free, Member » est un peu tautologique. En effet, si l’inscription est ouverte à tout le monde, alors elle l’est également aux membres de l’organisation. Mais en laissant la possibilité de l’exprimer explicitement, ça le fait mieux.
Et pourtant, vous produisez des factures (https://arn-fai.net/cgu). Hmmm … en fait, votre spécificité est que vos clients sont leurs propres fournisseurs. C’est particulier (et chouette) mais compatible avec la notion de client et indépendant de toute lucrativité. Je comprends l’envie de valoriser l’aspect auto-fournisseur
La notion de « client » n’est pas censée être « sale ». Pour les chatons voulant des clients et pas des membres, c’est parfaitement approprié.
Je crains que le terme Subscriber soit moins explicite mais ça pourrait se tenter. On pourrait dire que ce sont des services payants réservés aux membres. Et là, on ferait bien la distinction entre un simple client et un membre. Cela pourrait-il apporter une réponse à ta situation ?
Que représenterait MembershipOpen ? Adhésion ouverte ?
Un grand merci pour ces questions et ces propositions. Le groupe de travail tentera de les approfondir lors de la prochaine réunion (jeudi prochain)
Chez nous (Cliss XXI) on parle d’usager. Mais c’est vrai que les usagers sont parfois client d’un service.
S’il faut ergoter, Restricted me semble plus adéquate que Member (par exemple j’ai des services destinés aux habitants d’un certain bassin de vie). Paid me semble plus adéquate que Client (les éléments None/Free sont plutôt des qualificatifs).
Il me semble important de faire la distinction entre :
les assos dont les services sont réservés à un ensemble de membre ET où on ne devient pas membre dans l’optique d’avoir accès à ces services (exemple EEDF)
celles où n’importe qui peut devenir membre juste dans l’optique d’accéder à un service (exemple ARN / Sans-nuage.fr )
C’est sûr
Le soucis n’est pas que ce soit sale. J’ai des clients avec ReflexLibre et ça me pose aucun soucis.
Chez ARN, faut savoir qu’on fait zéro marge. Concrètement le prix que les gens paient c’est du partage de frais du contrat Cogent. Vu le prix il nous semble difficile de faire autrement. On a pas la notoriété de Frama pour un modèle basé sur des petits dons. Personne n’est payé/salarié. L’enjeu c’est que tous les membres comprennent que tout est basé sur le volontariat, la contribution. Donc, il faut éviter tout doute sur l’attitude à avoir, les attentes à avoir (notamment lors des demandes de supports) etc. La communication a un gros impact sur cette question (on refait notre siteweb). En terme d’UX, si les gens arrivent chez nous via un filtre marqué « Réservé aux clients » ben ça peut être un soucis, et je pense pas qu’on soit les seuls.
Je manque de temps pour faire une proposition concrète bien ficelée sur ce point. Mais voilà, je pose notre cas d’usage.
Après une longue réflexion et plusieurs discussions, tentatives, explorations intellectuelles, le groupe de travail a pris la décision de ne pas changer les valeurs proposées. Au moins pour l’instant.
En effet, en statistique, la notion de catégorie implique nécessairement des groupements basés sur des critères qui cachent des nuances. Dans notre cas, cela nous apporte peu (au collectif et aux visiteurs) de faire la nuance entre member et premiumMember. De même, une catégorie « Autre » ferait perdre de l’intérêt au champ. Donc cher @ljf, nous t’invitons à utiliser la valeur « Member ».
De même, « customer » « restricted » et « paid » n’ont pas pour l’instant générés suffisamment d’élan pour motiver une campagne de changement dans les 258 fichiers properties actuels.
Merci @ljf et @PoluX pour vos propositions et cas d’usages qui serviront de référence pour d’éventuels futurs changements
