Marquage de version pendant le développement de jeux

Question

Pendant la conception d'un JDR, celui-ci passe par de nombreuses itérations. Si l'on a un PDF, ou une copie imprimée des règles, ou un .docx ou quoi que ce soit, il est important de savoir à quelle version on se réfère.

Particulièrement, lorsque cela se fait en "open-source"/ communauté. Avec de nombreuses personnes apportant des contributions différentes et peut-être se lançant dans leurs propres variantes.

Pendant longtemps, mon club de jeu jouait à une version d'Adeptus Evangelion appelée "AdEva, v2.0 édition Delta". Elle avait été scindée de l'ensemble de règles AdEva original avant la sortie de la v2.0, et des changements avaient été apportés par un type dont le nom de personnage était "Delta". C'est très déroutant lorsqu'on essaie d'améliorer les changements.

Les logiciels maîtrisent bien cela avec le contrôle de version. Vous pouvez toujours vérifier une branche et retracer son historique.

Malheureusement, le texte brut et le contrôle de version sont beaucoup trop rebutants pour la plupart des gens qui créent des JDR pour s'amuser (croyez-moi, j'ai essayé plusieurs fois). Particulièrement, lorsqu'il s'agit d'un effort d'équipe de personnes ayant toutes sortes d'expérience. Je veux dire que mon projet actuel est seulement à deux, et déjà le manque de compétences techniques de l'autre personne empêche l'utilisation du contrôle de version. AdEva avait plus de 15 contributeurs, et 2 à 3 personnes contrôlaient le document canon (si je me souviens bien). Je suppose que ce contrôle a entraîné des variantes dérivées.

Quelle méthode puis-je utiliser pour m'assurer qu'il est clair à quelle version d'un JDR en développement correspond une copie particulière? Si cela implique des numéros de version, comment devrais-je les mettre à jour, etc.

En ce moment, j'appelle ma version actuelle alpha-X.y, et j'ai l'intention de continuer à l'appeler alpha jusqu'à ce que je commence à faire des playtests ouverts. Ensuite, je l'appellerai beta-X.y. X restera à 1 sauf si je décide de refondre radicalement le système. J'incrémenterai y à chaque fois que je ferai des changements - si je passe quelques heures à écrire une soirée, j'augmenterai y à la fin.

D'autres options pourraient être d'augmenter y uniquement lorsque je publie un PDF, mais certains de mes playtesteurs ont un accès en lecture à la version en direct : j'exporte vers un PDF pour qu'ils puissent lire dans le bus, etc. Ils pourraient exporter un PDF et il pourrait être différent d'une autre copie exportée par un autre joueur 12 heures plus tard, avec la même balise alpha-X.y dans l'en-tête.

SemVer ne peut pas m'aider, car SemVer ne fonctionne jamais sans une API pour le casser. Je recherche un système plus proche de SemVer que de git (ou Google Docs) cependant. Pas de contrôle de version, mais de nommage de version.

Il s'agit d'une question de processus de conception de jeux. Il ne s'agit pas de JDR publiés. Les JDR publiés sont généralement des éditions X avec des errata.

Answer 1

Je pense que vous attendez un peu plus de votre numéro de version qu'il ne le livre réellement.

Tout d'abord, oui, vous pouvez insérer un identifiant de commit Git dans votre fichier. Il existe des équivalents dans d'autres outils, et vous pouvez envisager des choses comme le suivi des modifications d'Office ou similaire.

Cela permettra aux utilisateurs de savoir "mes documents sont différents des siens", mais cela ne résout pas vraiment le problème "les utilisateurs finaux ne sont pas sûrs de quelle version est la dernière, ou comment comparer deux versions." Surtout lorsque vous utilisez quelque chose de non séquentiel, comme les hachages Git.

Étape un : Utilisez les versions

Les numéros de version sont différents des numéros de commit/hachages en ce qu'ils identifient les versions. De temps en temps, vous devez identifier un point où vous avez fait des progrès substantiels, et le publier sous une forme quelconque (une exportation PDF est bien), avec un numéro de version.

Vous pourriez le faire tous les N jours (donc la version alpha 1.2 est publiée une semaine après la version alpha 1.1, qui a été publiée une semaine après la version alpha 1.0). Ou vous pourriez le faire à des points arbitraires à mesure que vous progressez (la version alpha 1.2 a un système de collecte retravaillé par rapport à la version alpha 1.1).

Le point ici est que les versions, une fois publiées, sont stables et semi-permanentes. Si quelqu'un dit avoir un problème avec la version alpha 1.2, vous avez un moyen de revenir en arrière et de voir à quoi ressemblait la version alpha 1.2.

Étape deux : Verrouillez la version en direct

Les testeurs devraient utiliser vos versions numérotées. Cela vous permet de vous concentrer sur vos tests et d'obtenir des comparaisons raisonnables.

Votre copie "en direct" du document Google ne devrait être disponible que pour vos contributeurs/collaborateurs/acolytes directs. Ces utilisateurs devraient être assez "sophistiqués" pour comprendre que cette version du document évolue constamment. Ils ne devraient généralement pas avoir besoin d'un numéro de version... Si quelque chose n'est pas clair, ils devraient savoir comment obtenir la dernière version. S'ils ont aimé quelque chose qui a disparu, ils devraient savoir qu'ils doivent demander son réintroduction.

Intégrer les changements de plusieurs contributeurs

Gérer plusieurs auteurs est une question distincte des numéros de version. Beaucoup de bons changements ont été proposés... De la collaboration sur un document Google partagé, au suivi des modifications d'Office, en passant par des logiciels de contrôle de source tels que Git.

Les éléments importants ici sont :

• Vous êtes tous d'accord sur la façon dont les nouvelles versions sont publiées.

• Vous êtes tous d'accord sur la manière de résoudre les conflits.

• Vous avez un flux de travail qui fonctionne (ou qui peut être ajusté) pour tout le monde.

Il n'y a pas de solution miracle qui permette à tout le monde de "faire simplement ce qu'il veut" et que tout se passe bien. Vous avez ultimement besoin de quelqu'un pour résoudre les contradictions.

Les Forks

La dernière complication ici concerne les forks : quelqu'un publie une nouvelle version de votre travail sous son contrôle (et, par conséquent, son système de versioning). Honnêtement, je n'ai jamais été dans cette situation, mais il n'y a pas grand-chose que vous pouvez faire dans ce cas.

Si votre processus est strictement contrôlé, vous pourriez créer des forks plus permissifs (probablement ce qui est arrivé à AdEva). Si votre processus est moins contrôlé, vous pourriez voir apparaître des forks à partir de contradictions non gérées (le cas extrême est que la version de chaque contributeur est son propre fork), ou vous pourriez voir apparaître un fork plus étroitement organisé.

De toute façon, les forks sont le résultat du passage du contrôle d'un seul auteur au contrôle de la communauté. Si vous en êtes seulement à alpha pour l'instant, vous n'êtes pas encore là.

Answer 2

Utilisez Google Docs

J'ai déjà conçu des règles de GN à l'aide de Google Docs, et c'était génial. Les règles de GN, même si elles sont généralement plus courtes que celles des RPG sur table (une centaine de pages contre plusieurs centaines de pages), doivent être beaucoup plus précises, car il n'y aura pas de présence constante du MJ pour juger de chacune des applications des règles. Elles doivent également passer par de nombreuses itérations, ce qui peut également être source de confusion.

J'ai également une grande expérience de l'utilisation de Google Docs à différentes fins, que ce soit avec quelqu'un ou seul. Je l'utilise comme mon principal programme de bureau, et je n'ai même pas de programmes de bureau hors ligne normaux installés sur mon PC.

Pourquoi devriez-vous utiliser Google Documents, ou, pour être plus exact, Google Drive ?

1. Google Drive est essentiellement très similaire à un dossier normal sur votre ordinateur. Vous pouvez diviser vos règles en parties qui se trouvent toutes dans un seul dossier, ce qui réduit considérablement la confusion. Par exemple, nous avons placé les règles de combat dans un document distinct des règles d'économie, afin qu'il soit plus facile de comprendre ce qui est modifié.
2. Il est entièrement gratuit. Il vous suffit d'enregistrer un compte GMail. À moins que vous n'ayez besoin de stocker des fichiers particulièrement volumineux, les 15 Go gratuits que vous obtenez devraient être plus que suffisants. La conception d'un GN a un budget très limité, car elle est réalisée par des bénévoles, et le budget est formé par les joueurs couvrir les coûts de l'organisation de l'événement, la gratuité est donc un atout majeur. Un RPG open-source n'a probablement pas de budget.
3. Son utilisation ne nécessite que très peu de formation. Si vous êtes formé à l'utilisation d'un logiciel de bureautique standard comme Microsoft Office ou Open/Libre Office, vous apprendrez à utiliser Google Documents en un temps record. En fait, tout ce que vous aurez à savoir, ce sont les paramètres de partage et le contrôle de l'historique des versions, dont l'utilisation ne demande que très peu d'efforts particuliers. Si vous n'êtes pas intéressé par l'apprentissage d'un grand nombre de nouvelles choses complexes, Google Docs offre de nombreuses fonctionnalités qui sont vraiment faciles à apprendre.
4. Il prend en charge de nombreux types de fichiers : pas seulement du texte brut, mais aussi des dessins, des feuilles de calcul de type Excel, etc. Nous avons utilisé une feuille de calcul Google pour les calculs budgétaires, un dessin Google pour le marquage du territoire de jeu, des formulaires Google pour accepter les données des joueurs, et une feuille de calcul pour les stocker. Vous n'aurez probablement pas besoin de calculer le budget d'un RPG "open-source", mais vous pourriez utiliser des feuilles de calcul pour d'autres calculs importants, pour lesquels vous auriez typiquement besoin d'Excel.
5. Vous pouvez télécharger facilement tout fichier que vous pouvez visualiser dans l'un des formats courants, tels que .odt, .docx ou .pdf. Vous pouvez également en faire une copie distincte ajoutée à votre Google Drive.
6. Le téléchargement de Google Drive ne nécessite absolument aucun logiciel spécial. Si vous disposez de l'un des navigateurs les plus courants, vous pouvez utiliser Google Drive. Si vous avez un smartphone Android, vous pouvez aussi avoir un Google Drive entièrement fonctionnel ! Cela signifie également que la configuration requise pour utiliser Google Drive est très faible, et que vous pouvez l'utiliser sur n'importe quel PC, même si vous n'êtes pas autorisé à y installer des logiciels.
7. Google Drive permet à plusieurs personnes de modifier le même fichier en même temps. Elles verront quelles parties sont en cours d'édition par les autres. Cela peut se passer très bien si vous avez tous une bonne connexion Internet, ou moins bien - dans ce dernier cas, vous devrez vous abstenir de modifier les mêmes lignes dans le même document, mais la plupart des systèmes que je connais ne le permettent pas du tout ! Et, encore une fois, vous pouvez le faire si votre internet est bon, surtout si vous utilisez une sorte de communication vocale lors de l'édition, comme Discord, TeamSpeak, Skype, ou simplement en vous asseyant ensemble lors d'une réunion hors ligne :)
8. Vous n'avez pas besoin d'une connexion Internet permanente pour modifier les fichiers de votre Google Drive. La quasi-totalité des fonctionnalités de Google Drive sont disponibles hors connexion. Je n'ai pas l'expérience du travail hors ligne pendant de longues périodes (plus de quelques heures pour des documents partagés, plus de quelques jours pour des documents édités uniquement), mais vous pouvez, par exemple, éditer un fichier pendant quelques heures lorsque vous êtes dans le train, et les changements seront automatiquement téléchargés la prochaine fois que vous aurez une connexion Internet.
9. Vous pouvez également avoir des fichiers autres que Google Docs dans votre Google Drive. Mais Google Docs ne prend pas d'espace dans votre Drive, alors que les fichiers 3d prennent de l'espace.
10. Il dispose d'une fonction intégrée de sauvegarde automatique qui se produit toutes les quelques secondes. Vous ne perdrez pas votre travail si l'électricité s'éteint soudainement, ou si votre système d'exploitation se plante.
11. Vous ne pouvez pas non plus perdre vos fichiers en raison d'une défaillance du disque dur. Vous pouvez en fait faire confiance à Google pour le stockage de vos fichiers.
12. Il possède des paramètres parfaits de partage et de contrôle de version que j'aborde dans les deux prochains chapitres :)

Comment fonctionnent les paramètres de partage de Google Drive ?

El Propriétaire du document a tous les droits sur ce document, et ils ne peuvent être révoqués que par le propriétaire lui-même : le propriétaire devra transférer le document à un autre propriétaire.

Le propriétaire, entre autres, peut faire les choses suivantes avec n'importe quel document Google ou dossier Google Drive :

1. Ajoutez des personnes spécifiques avec des adresses GMail spécifiques à la liste de partage, en attribuant des privilèges spécifiques à chacune d'entre elles. Le propriétaire peut également supprimer des personnes de la liste.
2. Créez un lien vers le document qui peut être partagé, en attribuant un niveau de privilège à l'utilisateur. tout personne qui reçoit le lien.

Les niveaux de privilèges sont, par ordre croissant, les suivants :

1. "Peut voir". Vos fichiers ne sont visibles par personne par défaut, vos données sont donc privées, mais vous pouvez autoriser des personnes spécifiques à les consulter, ou les partager par le lien avec un nombre illimité de participants. Les personnes autorisées à consulter le document verront également le processus d'édition en cours, le cas échéant. Ils ne seront pas autorisés à voir l'historique des versions, à partager le fichier avec quelqu'un d'autre et à modifier les paramètres de partage. Dans les GN, nous utilisons ces paramètres pour les joueurs qui sont autorisés (et tenus !) à lire les règles, mais certainement pas à les modifier.
2. "Peut commenter". Très utile pour vos bêta-lecteurs. Ceux qui ont ce privilège sont autorisés à sélectionner une partie du document et à saisir leur commentaire pour celle-ci. C'est très utile pour discuter de parties spécifiques de votre texte. Les commentaires ne sont visibles que par les autres commentateurs et par ceux qui peuvent effectivement modifier le document. Les commentateurs sont également autorisés à suggérer des modifications : elles apparaissent dans un formatage spécifique afin qu'il soit facile de distinguer une suggestion d'un texte fini. Les suggestions ne sont pas visibles par les "spectateurs", mais uniquement par ceux qui peuvent modifier le texte et le commenter. Même si vous êtes autorisé à modifier vous-même le document, il peut être utile d'utiliser la mécanique des suggestions et des commentaires pour que les spectateurs ne voient vos modifications que lorsqu'elles sont prêtes, mais puissent toujours accéder à votre document par le même lien. Nous n'avons pas eu de personnes qui n'étaient autorisées qu'à commenter, mais ces fonctionnalités étaient couramment utilisées.
3. "Peut éditer". Ces personnes peuvent faire à peu près tout : modifier le texte directement, changer les paramètres de partage, accepter et rejeter les modifications suggérées, supprimer les commentaires et les marquer comme résolus, etc. Ils peuvent voir et utiliser pleinement l'historique des modifications. Ceci devrait être utilisé pour l'équipe de vos principaux collaborateurs. Mais gardez à l'esprit, encore une fois, que les "éditeurs" ont également la possibilité de suggérer des modifications, et qu'il est souvent préférable de retravailler une partie du texte via une modification suggérée et de ne l'"accepter" vous-même que lorsque la modification est prête à être présentée.

Notez que les mêmes niveaux de privilèges existent pour votre équipe avec des adresses e-mail données (évidemment, les privilèges de chaque membre sont séparés) et pour le partage de liens. Si vous ne donnez pas votre lien à beaucoup de personnes, vous pouvez activer le commentaire de lien, mais ce sera un désordre si beaucoup de personnes ont ce droit alors que vous travaillez activement sur le document.

Si vous travaillez sur quelque chose avec votre seul ami proche et uniquement avec lui, vous pouvez lui donner un lien avec des privilèges d'édition. Mais s'il y a une fuite, toute personne qui le trouve pourra modifier le document.

Pour gérer les paramètres de partage, faites un clic droit sur le fichier et appuyez sur "Partager".

Ici est le manuel officiel de partage.

Comment fonctionne l'historique des versions de Google Drive ?

Il y a un très bon manuel officiel sur le contrôle de version mais, par souci d'exhaustivité, je vais en partager les bases ici.

Pour accéder à l'historique des versions, cliquez sur le bouton situé à droite du bouton "Aide". Il peut être lu de l'une des manières suivantes :

1. "Toutes les modifications sont enregistrées dans Drive" -- si vous venez de l'éditer, et que les modifications sont enregistrées avec succès.
2. "La dernière modification a été faite [période de la dernière modification]". -- s'il a été édité par vous il y a quelque temps.
3. "La dernière modification a été faite [période de la dernière modification] par [auteur de la dernière modification]". -- s'il a été édité il y a quelque temps, et pas par vous.

Vous pouvez éditer lorsque vous êtes hors ligne, et il y aura un signal textuel si les modifications sont enregistrées hors ligne ou si quelque chose se passe mal, mais vous ne pouvez pas accéder à l'historique des versions hors ligne.

Lorsque vous cliquez sur ce bouton, vous verrez une liste de versions (révisions), classées par ordre chronologique (la plus récente en premier, la plus ancienne en dernier). Pour chaque version, vous verrez l'heure et la date, ainsi que les auteurs.

Si vous cliquez sur une révision, vous pourrez voir chaque modification dans le texte, y compris l'auteur de chaque modification, et vous pourrez revenir à la révision en question.

Si vous cliquez sur les trois points alignés verticalement à droite du nom de chaque révision, vous pourrez nommer une révision, en signalant brièvement les modifications. Un bouton dans le coin supérieur droit vous permet de ne regarder que les révisions nommées ou de les regarder toutes en même temps.

Vous pouvez signaler les modifications nommées dans le texte, comme "Version 3.1a : blablabla modifié". La meilleure façon de s'assurer que la version que vous lisez sur papier est très claire est d'ajouter des en-têtes de page : ils seront ajoutés automatiquement pour chaque page si vous appuyez sur "Insérer", puis "En-tête", et ensuite entrez le nom/numéro de la version.

Pendant que vous travaillez sur un document, vous pouvez entrer les modifications comme "suggérées", et nommer une révision chaque fois que vous acceptez quelque chose, en le signalant dans le texte. Il est également bon d'avoir un journal des modifications écrit. Nous n'en avons pas eu besoin parce que nous n'avions pas besoin de forker nos règles, mais d'autres Russes qui conçoivent des GNL avec Google Docs l'ont fait (par exemple, celui qui a créé un modèle de médecine très populaire, peut-être le plus populaire en Russie).

Lancement de nouvelles versions

D'après mon expérience, c'est une très mauvaise idée d'autoriser l'accès à la version en direct à toute personne qui n'est pas censée la modifier. Une fois que vous avez apporté un nombre important de modifications, vous pouvez décider que vous êtes prêt à faire une nouvelle version alpha. Que devez-vous faire alors ?

1. Mettez à jour le journal des modifications, qui devrait se trouver dans le fichier débutant de votre document. Lorsque vous lisez une version légèrement différente d'un document familier, il est très facile de ne pas voir les modifications importantes. Vous pouvez passer en revue toutes vos modifications dans le Google Doc depuis la dernière version, et écrire simplement ce qui a changé depuis. Il est en fait préférable d'écrire le journal des modifications. tandis que travailler sur une nouvelle version, mais si certains de vos participants ne font pas tout correctement, vous devrez peut-être procéder à une nouvelle vérification, ou même décider de faire tout le travail de versionnement vous-même, ce qui n'est pas une mauvaise idée. Nous n'avons pas eu de véritables changelogs pendant notre développement, mais nous avions des documents de "résolution", où nous avons écrit ce que nous avions décidé de changer à chacune de nos réunions.
2. Mettez à jour le numéro de version. Il doit figurer quelque part sur la page de titre, afin que vous puissiez le voir clairement, mais n'oubliez pas de l'ajouter également sur un en-tête de page, de sorte que si vous avez une version imprimée et que les pages sont séparées, vous ne soyez pas perdu dans le chaos. Changez également le nom du document, afin de ne pas vous y perdre. C'est une bonne idée de baser votre nom de version sur la date et l'heure de la version et sur le nom de la fourche, ainsi il pourrait se lire comme suit : " Version 30.11.2017 2:22 alpha Main_fork ", où " Main_fork " est le nom de votre fork. Mieux vaut inventer quelque chose de plus ou moins original, de sorte qu'il soit facile de Ctrl+F pour cela. N'utilisez pas de mots communs comme noms de fork.
3. Faites une copie de votre document dans votre propre Drive, et gèlez toute modification du document publié. Révoquez les droits d'édition de tous ceux qui y ont accès, afin qu'ils ne puissent pas modifier l'ancienne version, et ne la modifiez pas vous-même. Nommez l'ancien document exactement de la même manière que sa version, et publiez-le de la manière que vous utilisez : partage de liens, exportation au format PDF, etc.
4. Copiez les données du journal des modifications de l'ancienne version dans le journal des modifications principal à la fin du document, afin de disposer d'une liste complète de vos modifications.

De cette façon, tout lecteur comprendra très clairement quelle version il lit, quelles modifications ont été apportées et, grâce aux bons outils de gestion des versions, il sera très facile de marquer les modifications.

Comment peut-on avoir une bifurcation ?

Comme nous l'avons mentionné, Google Docs dispose d'un outil intégré permettant de faire une copie de tout document que vous pouvez consulter, y compris vos propres documents. Pour ce faire, il suffit de cliquer sur "Fichier", puis sur "Faire une copie". Le problème est que la copie ne diffère en rien du fichier original, à l'exception de son nom : elle s'appellera "Copie de [nom du fichier précédent]". Elle sera également no héritent de l'historique des versions du fichier original. Cela signifie que vous devrez de toute façon marquer les modifications manuellement.

Si quelqu'un veut bifurquer votre projet, vous pouvez donner les actions suivantes, que vous pouvez exiger dans votre licence :

1. Faire une copie du document via la fonctionnalité "Faire une copie".
2. Nommez votre nouvelle fourche en remplaçant l'ancien nom par le vôtre. Par exemple, si l'ancien nom était "Main_fork", vous pouvez le remplacer par "Brave_new_fork" dans les en-têtes de page, sur la page de titre et dans le nom du document.
3. Déplacez le changelog de la fourche que vous avez copiée à la fin du document.
4. Commencez votre nouveau changelog avec une ligne qui dit quelque chose comme "Forked from version X of fork Y, named Z, on day DD.MM.YYYY".

Comment obtenir la liste des modifications d'un document ?

Imaginons que quelqu'un ait bifurqué de votre RPG, qu'il ait fait une liste de changements populaires, mais qu'il ait omis de les documenter correctement. Pour les trouver, vous devrez faire une copie de la version sur laquelle elle est basée, et du document forqué lui-même. Vous devez sélectionner toutes les données du document bifurqué et les copier (Ctrl+A, Ctrl+C), puis sélectionner tout et le coller sur la copie du document de l'ancienne version (Ctrl+A, Ctrl+V). Vous pouvez ensuite examiner les modifications apportées en vérifiant l'historique des révisions. Vous pourrez documenter vous-même toutes les modifications et, peut-être, les incorporer dans votre fourche principale.

---

Dans l'ensemble, Google Docs fonctionne parfaitement pour les petits projets développés par de petites équipes (en dessous de 10 personnes par exemple), mais je ne peux rien dire à propos de quelque chose de plus important. Notez que, bien que je l'aie fait pour moi-même, j'ai zéro l'expérience de la bifurcation de documents en tant qu'effort communautaire.

Answer 3

Si vous vous attendez à ce que des personnes "ordinaires" puissent comprendre les systèmes de contrôle de version et la version à laquelle elles font référence, vous devez le rendre aussi simple que possible.

Utilisez "Qui" et "Date" comme numéro de version

La clé est, comme d'autres l'ont mentionné, que vous devez avoir des "versions" régulières. Ne pensez pas qu'il existe une version "en direct", il y a juste des publications régulières d'une version d'un document. Le numéro de version devrait être la date (je recommande le format ISO 8601 AAAA-MM-JJ), ainsi que la personne qui le publie (comme vous vous souciez que les gens maintiennent leur propre branche). Si vous devez publier plusieurs fois dans une journée, ajoutez un numéro de révision ou simplement l'heure (dans votre fuseau horaire local ou UTC) comme "White 2017-11-28-1930" (en supposant que vous voulez utiliser "White" comme "qui").

Les détails de la manière dont cela est maintenu, ou comment trouver facilement les différences entre les différentes versions, dépendent grandement de tout logiciel que vous essayez d'utiliser pour aider à le maintenir. Mais si votre question est de "s'assurer qu'il est clair quelle version d'un RPG en développement est une copie particulière", alors c'est le seul moyen de le rendre clair (1) qui l'a créé, et (2) quelle version c'est, et si elle est plus ancienne ou plus récente qu'une autre version.

Si vous vous attendez à ce qu'un groupe soit la seule équipe à publier des versions, alors vous n'avez peut-être pas besoin d'être aussi clair sur le fait d'avoir le "qui" dans votre chaîne de publication. Mais s'il peut y avoir des forks, alors cela rend clair quel groupe l'a publié, et ensuite d'autres auteurs ou vous pourriez inclure d'autres modifications comme ils le jugent approprié (sous réserve des problèmes habituels de droits d'auteur/licence/etc.). Trouver les différences pourrait bien sûr être facilité avec un référentiel de contrôle de source que tout le monde utilise, mais presque tous les programmes de traitement de texte ont une fonction "afficher les différences", donc si vous obtenez des copies numériques des choses il devrait être possible de savoir ce qui est différent entre chaque version, et avec une désignation claire du "qui" et de la "date" il devrait être clair pour tout le monde de quelle publication d'un document il est question.

Answer 4

En fait, vous pouvez utiliser des systèmes de contrôle de version (par exemple Git) avec n'importe quel type de fichiers, donc votre plainte concernant le texte brut est mal dirigée. Vous pouvez utiliser Git avec des PDF, et sauf si vous allez vous lancer dans les branches, ce que j'espère sincèrement que vous n'auriez pas besoin de faire... Le contrôle de version ne fonctionnerait-il pas correctement? Vous pourriez avoir x.y.z pour (grande) (mineure) (correction) quelque part dans le fichier, si vous en aviez vraiment envie. Il vous suffit d'acheter un référentiel privé sur GitHub ou de mettre en place quelque chose d'autre avec une interface web quelque part.

Cela dit, pourquoi leur donner un accès en direct en premier lieu? Vous ne voulez certainement pas qu'ils copient une version tandis que vous êtes au milieu d'une phrase... Ce serait confus ! Ne le faites pas! Pour utiliser une métaphore de programmation, c'est comme donner aux gens du code qui ne compile pas!