ZEP-08 Utilisation de git pour gérer les tutos et articles

Ça me semble plus simple et cohérent de garder ça dans un fichier, non ?

Et il se passe quoi si l'auteur / le contrib vire les autres auteurs malgré le boulot qu'ils puisse abattre dans une version de son tuto ?

Dans ce cas, c'est aux autres contributeurs de se plaindre pour violation de leur propriété intellectuelle. Git conservera la trace des contributions de chacun. Si ça ne se règle pas à l'amiable, on pourra fournir ces informations au tribunal compétent. Zeste de Savoir ne pourra rien décider seule.

Je pense qu'il suffit de ne pas valider ?

Hum…Houston, we have a problem.

Les CGU précisent clairement:

1) Que les auteurs gardent l'ensemble de leurs droits sur leurs publications

2) Que différents droits (modifs, adaptation,…) sont donné à l'éditeur du site pour qu'il puisse effectuer correctement son boulot de validation, de présentation de la publication.

Inhérent à cela:

• Permettre à un membre de signaler des erreurs que l'auteur peut intégrer s'il le souhaite, ça marche.
• Mais que le membre signalant des erreurs ou effectuant des changements (sous réserve ou pas d'acceptation par l'auteur) et qu'il puisse (selon un prorata, whatever) devenir automatiquement co-auteur pose un problème.

Pourquoi ? Eh bien premièrement, l'auteur garde ses droits comme spécifié dans les CGU. De fait, il doit être le seul à pouvoir décider ou non de l'ajout d'un autre membre comme co-auteur. Ainsi, mettre en place un système automatique (dont l'auteur n'a pas forcément conscience de son existence) va à l'encontre des droits de l'auteur et causera - j'en ai quasiment la certitude, vu des litiges pour moins que ça - des litiges.

De même, si tout membre a pertinemment le droit de signaler des erreurs, qu'il puisse les corriger lui-même (dans une autre version du tuto/article certes, mais également soumise au droit d'auteur) alors que ce droit n'est clairement pas spécifié dans les CGU (et en ce qui concerne les tutos dont l'auteur se réserve les droits, ce serait problématique (pour ne pas dire fou) de le permettre à tout membre) nous placerait vite dans une mauvaise posture face à l'auteur au moindre litige.

Donc on ne peut pas faire de système de PR? Même quand il n'y a pas de license qui interdisent la dérivation?

Tout dépend de la licence, c'est ça le problème. Si c'est une licence qui l'autorise, alors pas de problème pour les modifs. Pour l'ajout comme auteur, c'est un autre délire.

Si la licence choisie par l'auteur interdit toute modification non autorisée, c'est un non inconditionnel.

Si j'ai bien compris les propros d'Arius, un système de PR pour les corrections est implémentable et légal, par contre, un système dans lequel l'auteur d'une PR corrective devient automatiquement auteur de la publication peut ne pas être légal en fonction de la licence.

Conclusion : les auteurs de commit c'est bien joli, mais il faut versionner les "vrais" auteurs des tutos ailleurs, c'est à dire dans le fichier manifest.

Pour l'ajout comme auteur, c'est un autre délire.

perso j'aurai pas ajouté "comme auteur" un gars qui sur le site fait juste un changement pour l'orthographe.

PS : pourquoi utiliser l'auteur du commit? Pourquoi ne pas simplement utiliser le pseudo de celui qui merge la PR de correction?

Un système de PR corrective est implémentable et légal, si et seulement si la licence le permet. En ce qui concerne l'ajout comme auteur, dans les deux cas, cela ne l'est pas forcément.

• Si la licence autorise les modifications: L'auteur d'une PR corrective est l'auteur de ses modifications, pas de l'ensemble du tuto. De fait, à moins de spécifier quels sont ses modifications (ce qui serait pas vraiment user-friendly), ça pose un pépin vu que ça lui donne des droits sur ce qui n'est pas de lui.

• Si la licence ne permet pas de modifs: il ne peut absolument pas être auteur.

Voilà pourquoi c'est un autre délire. Gérer la différenciation serait trop long, pas très user-friendly et donc pas vraiment pertinent.

Je pense qu'il serait intéressant dans le premier cas (si les modifs sont acceptées par la licence) de permettre au contributeur qui estime avoir contribué de façon majeure à la publication de se proposer comme co-auteur et laisser l'auteur discuter avec lui et refuser/accepter.

Bon … Quand est-ce que quelqu'un prend un peu de temps pour écrire un tuto sur les licences et leurs implications ?

Du coup, je doute très franchement que ça a sa place dans le manifest. Pourquoi ? Un type qui rédige le tuto dans son coin (toujours dans l'idée d'ouvrir derrière…) n'a pas forcément les infos de BDD (pk des auteurs, … etc) en stock. En somme, dans le manifest, c'est juste la structure du tuto, pas les méta-données de celui-ci…

ben le jour on on gèrera les pull-request, il faudra bien mentionner qu'on n'accepte que des modifs mineurs ne pouvant pas être reconnues comme une œuvre originale (correction orthographique, etc…) sauf si l'auteur autorise les modifications via sa licence.

L'avantage qu'on a, c'est qu'on versionne tout, donc, au pire, on peut extraire toutes les modifs proposées par un non auteur. Si litige il y a, on revert tout, et si l'auteur des modifications exige dédommagement pour l'utilisation de ses modifications (entre leur application et leur revert), et bien on attendra un arbitrage de justice, durant lequel on montrera qu'on est de bonne foi.

Du coup, je note qu'il ne faut pas qu'on mette en prod la gestion de pull-request tant qu'on n'aura pas notre assurance (qui couvre notamment les frais de justice). Je reparlerai de ça dans la section association.

En tous cas, il faut bien différencier les auteurs de l'œuvre des autres de commits. C'est pas la même chose, tout comme un relecteur d'une maison d'édition n'est pas un auteur des œuvres dans lesquelles il corrige des fautes d'orthographe.

Par contre, avoir les auteurs dans le manifest, ça me semble bien, même si ça demande de faire un commit chaque fois qu'on ajoute ou ôte un auteur au tuto sur le site.

ben le jour on on gèrera les pull-request, il faudra bien mentionner qu'on n'accepte que des modifs mineurs ne pouvant pas être reconnues comme une œuvre originale (correction orthographique, etc…) sauf si l'auteur autorise les modifications via sa licence.

Dans ce cas, il ne faudra pas non plus oublier de compléter les CGU en indiquant que les membres peuvent éditer les publications, effectuer des corrections et les soumettre à l'auteur. Plus les CGU sont explicites, plus ZdS aura de garanties et plus les droits des membres seront couverts.

Dans ce cas, il faudra deux fichiers, un manifest et un fichier dédié aux métadonnées, même si je vois pas trop l’intérêt de séparer les deux. L'idée c'était surtout de dire que on ne peut pas lire les auteur de commit et les afficher directement comme étant auteurs d'une publication.

Le "si et seulement si" n'est pas utile ici justement, car la PR peut être :

1. Acceptée : mais celui qui a envoyée la PR ne rentre pas automatiquement dans la liste des contributeurs
2. Refusée : et basta, aucune trace de la PR dans les commits

Au final tout ceci est transparent pour l'auteur et le correcteur, car la seule façon de rajouter un correcteur dans la liste des auteurs doit rester une action manuelle d'un auteurs ou d'un co-auteur.

Ainsi quelque soit la licence, l'auteur garde la main mise sur qui-est ce qu'il rajoute dans le groupe des auteurs.

En gros, tu fais une correction, tu veux rentrer dans le liste des contributeurs, tu fais un MP, et vous vous arrangez comme ça.

En fait, les membres n'éditent pas les publications, ZdS le fait, en utilisant les propositions des membres. Du coup, ce qui est publié sur ZdS est de la responsabilité de l'asso. Par contre, le problème se pose pour un membre qui télécharge son tuto avec les corrections effectuées ici, le re-publie ailleurs. Si l'auteur des modifications décide un jour de revendiquer ses modifications comme une oeuvre originale, l'auteur du tuto est responsable de la publication sur un autre support. Il faudra faire une notice d'information pour les gens qui récupèreront leur oeuvre sur le site.

En fait, les membres n'éditent pas les publications, ZdS le fait, en utilisant les propositions des membres

Je cite:

Une possibilité basique d'utilisation serait celle-ci :

sur ZDS l'auteur publie son tuto

sur ZDS un visiteur authentifié voit une phrase mal tournée

sur ZDS le visiteur authentifié a la possibilité "d'éditer le tuto" pour y apporter sa correction

sur ZDS le visiteur authentifié appuie sur "proposer la correction"

sur ZDS l'auteur voit une proposition de correction, s'il l'accepte, la correction est fusionnée à son travail courant, s'il ne l'accepte pas, la branche de correction est fermée.

Ici, on ne quitte pas ZDS, c'est donc une fonctionnalité corporate qui s'inscrit dans le désire de voir la communauté participer à la vie du site.

Visuellement, c'est interprété comme l'édition d'une publication dans le but de proposer une correction, mais ça reste une édition. ZdS n'intervient pas dans le processus (qui concerne le membre X et l'auteur).

firm1: ouep, ça marche.

Au final, c'est ZdS qui publie. C'est donc à ZdS de respecter les droits de divulgation, de paternité, de respect de l'intégrité et de retrait des auteurs. Il n'y a jamais de mise en prod sans action d'un valido (sinon c'est qu'on a une erreur dans la spec).

Du coup, sur cette ZEP, quelqu'un saurait-il dire si le premier post est à jour ? Ou il faut nécessairement lire tous les posts avant de faire des remarques ?

je ne l'ai pas mise à jour, en effet.