Salut,

Histoire d'alimenter les réflexions autour des histoires de  
fonctionnalités des auteurs, je crois intéressant de rappeler ce qui suit,  
et qui pose énormément de difficultés avec SPIP (et avec beaucoup d'autres  
systèmes du même genre, je crois).

=> Les "auteurs" dans SPIP correspondent à plusieurs usages différents:

      * fonction éditoriale: il s'agit de "signer" les articles, afin de  
pouvoir publier un article en indiquant qui est son auteur (ou ses  
auteurs);

      * fonction de gestion de droits: le statut d'un auteur dans la base  
détermine ses droits dans l'espace privé (admin ou rédacteur, mais aussi  
les articles qui sont "les siens" en tant qu'éditeur et qu'il peut donc ou  
non modifier...) et dans une moindre mesure sur le site public (notamment  
forums sur abonnement);

      * fonctions collaboratives dans l'espace privé: identification  
automatique lors des discussions dans les forums internes, et aussi  
fonctions de messagerie.

=> Ces trois usages sont, dans SPIP (comme dans de nombreux systèmes),  
fondus et gérés au même endroit (spip_auteurs), parce que dans l'usage  
principal prévu à l'origine (la gestion d'un webzine), c'est très logique  
et extrêmement pratique.

Mais cette façon de procéder n'était pas une obligation, et n'apporte pas  
que des avantages.

- Par exemple, sur le site Vuibert (sur lequel une partie des premiers  
principes de SPIP ont été expérimentés), les éditeurs et les auteurs sont  
deux tables séparées, car deux notions totalement différentes: les  
éditeurs qui mettent à jour le catalogue ne sont _jamais_ des auteurs des  
livres qu'ils publient, du coup les "éditeurs" accèdent à l'espace privé  
et mettent en ligne le site, mais les "auteurs" qui sont associés aux  
livres sont une notion totalement séparée.

- Sur un site comme le Diplo, l'exemple a déjà été donné: les journalistes  
qui gèrent le site peuvent parfois être des auteurs d'articles, et  
généralement ils ne le sont pas. D'où une astuce pour faire la différence  
entre un journaliste en tant qu'intervenant dans la mise en ligne d'un  
article, et ce même journaliste lorsqu'il signe un article publié.

=> Beaucoup de difficultés d'interface et/ou limites fonctionnelles de  
SPIP sont liées à cette gestion de 3 fonctions radicalement différentes au  
même endroit.

Ainsi:

      * toujours cettes relative lourdeur lorsqu'on veut différencier celui  
qui met en ligne un article et celui qui le signe (pour les sites ou une  
équipe effectue la mise en ligne de textes sans intervention des auteurs  
d'origine);

      * pour assurer la cohérence du site (et la responsabilité  
individuelle), les droits des rédacteurs sont largement liés au fait  
qu'ils sont les auteurs des articles; pratique en général, lourd parfois;

      * les fonctions de messagerie interne peuvent très difficilement être  
complétées par une notion de "Contacts", avec numéros de téléphone,  
adresse, etc., (ce qui serait très pratique par exemple au sein d'une  
association), parce que potentiellement ces informations risqueraient de  
devenir publiques (ouverture d'un accès automatique à l'espace privé,  
publication d'infos "privées" parce qu'un "Contact" est devenu le  
signataire d'un article, etc.).

      * lourdeur de la gestion des visiteurs du site public, parce que le  
but de SPIP est principalement d'amener les visiteurs à devenir des  
contributeurs, avec accès à l'espace privé; de ce fait les visiteurs sont  
gérés comme des rédacteurs dotés de droits spécifiques (et restreints)  
dans la même base.

Ce genre de choses...

=> De fait, on a déjà constaté ces difficultés, avec les déplacements du  
bouton "Auteurs" dans la barre de navigation de l'espace privé: parfois  
considéré comme un élément éditorial, comme les articles et les brèves  
(version 1.7), parfois comme élément de gestion de droits, donc présenté à  
part (toutes les autres versions).

=> Les récentes discussions autour des mots-clés, abonnements, etc. liés  
aux auteurs, doivent prendre en compte cet aspect. Et quand ce cumul de  
trois types de fonctionnalités des auteurs est oublié, on tombe rapidement  
et involontairement sur: un système de flicage, encore plus de lourdeur  
d'utilisation, une ergonomie catastrophique, la divulgation de la vie  
privée, etc. )

Amicalement,
ARNO*

Salut,

Histoire d'alimenter les réflexions autour des histoires de  
fonctionnalités des auteurs, je crois intéressant de rappeler ce qui suit,  
et qui pose énormément de difficultés avec SPIP (et avec beaucoup d'autres  
systèmes du même genre, je crois).

=> Les "auteurs" dans SPIP correspondent à plusieurs usages différents:

      * fonction éditoriale: il s'agit de "signer" les articles, afin de  
pouvoir publier un article en indiquant qui est son auteur (ou ses  
auteurs);

      * fonction de gestion de droits: le statut d'un auteur dans la base  
détermine ses droits dans l'espace privé (admin ou rédacteur, mais aussi  
les articles qui sont "les siens" en tant qu'éditeur et qu'il peut donc ou  
non modifier...) et dans une moindre mesure sur le site public (notamment  
forums sur abonnement);

      * fonctions collaboratives dans l'espace privé: identification  
automatique lors des discussions dans les forums internes, et aussi  
fonctions de messagerie.

=> Ces trois usages sont, dans SPIP (comme dans de nombreux systèmes),  
fondus et gérés au même endroit (spip_auteurs), parce que dans l'usage  
principal prévu à l'origine (la gestion d'un webzine), c'est très logique  
et extrêmement pratique.

Mais cette façon de procéder n'était pas une obligation, et n'apporte pas  
que des avantages.

- Par exemple, sur le site Vuibert (sur lequel une partie des premiers  
principes de SPIP ont été expérimentés), les éditeurs et les auteurs sont  
deux tables séparées, car deux notions totalement différentes: les  
éditeurs qui mettent à jour le catalogue ne sont _jamais_ des auteurs des  
livres qu'ils publient, du coup les "éditeurs" accèdent à l'espace privé  
et mettent en ligne le site, mais les "auteurs" qui sont associés aux  
livres sont une notion totalement séparée.

- Sur un site comme le Diplo, l'exemple a déjà été donné: les journalistes  
qui gèrent le site peuvent parfois être des auteurs d'articles, et  
généralement ils ne le sont pas. D'où une astuce pour faire la différence  
entre un journaliste en tant qu'intervenant dans la mise en ligne d'un  
article, et ce même journaliste lorsqu'il signe un article publié.

=> Beaucoup de difficultés d'interface et/ou limites fonctionnelles de  
SPIP sont liées à cette gestion de 3 fonctions radicalement différentes au  
même endroit.

Ainsi:

      * toujours cettes relative lourdeur lorsqu'on veut différencier celui  
qui met en ligne un article et celui qui le signe (pour les sites ou une  
équipe effectue la mise en ligne de textes sans intervention des auteurs  
d'origine);

      * pour assurer la cohérence du site (et la responsabilité  
individuelle), les droits des rédacteurs sont largement liés au fait  
qu'ils sont les auteurs des articles; pratique en général, lourd parfois;

      * les fonctions de messagerie interne peuvent très difficilement être  
complétées par une notion de "Contacts", avec numéros de téléphone,  
adresse, etc., (ce qui serait très pratique par exemple au sein d'une  
association), parce que potentiellement ces informations risqueraient de  
devenir publiques (ouverture d'un accès automatique à l'espace privé,  
publication d'infos "privées" parce qu'un "Contact" est devenu le  
signataire d'un article, etc.).

      * lourdeur de la gestion des visiteurs du site public, parce que le  
but de SPIP est principalement d'amener les visiteurs à devenir des  
contributeurs, avec accès à l'espace privé; de ce fait les visiteurs sont  
gérés comme des rédacteurs dotés de droits spécifiques (et restreints)  
dans la même base.

Ce genre de choses...

=> De fait, on a déjà constaté ces difficultés, avec les déplacements du  
bouton "Auteurs" dans la barre de navigation de l'espace privé: parfois  
considéré comme un élément éditorial, comme les articles et les brèves  
(version 1.7), parfois comme élément de gestion de droits, donc présenté à  
part (toutes les autres versions).

=> Les récentes discussions autour des mots-clés, abonnements, etc. liés  
aux auteurs, doivent prendre en compte cet aspect. Et quand ce cumul de  
trois types de fonctionnalités des auteurs est oublié, on tombe rapidement  
et involontairement sur: un système de flicage, encore plus de lourdeur  
d'utilisation, une ergonomie catastrophique, la divulgation de la vie  
privée, etc. )

Amicalement,
ARNO*