Acho que você espera um pouco mais do número da sua versão do que realmente oferece.

Para começar, sim, você pode insira um ID de confirmação do Git no seu arquivo. Existem equivalentes em outras ferramentas, e você pode considerar coisas como o Office Change Tracking ou similar.

Isso permitirá que os usuários saibam "meus documentos são diferentes dos dele", mas isso realmente não resolve o problema de "os usuários finais não têm certeza de qual versão é a mais recente ou de como comparar duas versões". Especialmente quando você está usando algo não sequencial, como hashes Git.

Etapa 1: usar versões

Os números de versão são diferentes dos números de confirmação / hashes, pois identificam lançamentos. De vez em quando, é necessário identificar um ponto em que você fez um progresso substancial e publicá-lo de alguma forma (uma exportação de PDF é boa), juntamente com um número de versão.

Você pode fazer isso todo N dias (a versão alpha 1.2 é publicada uma semana após alpha 1.1, que foi publicada uma semana após alpha 1.0). Ou você pode fazer isso em pontos arbitrários à medida que avança (o alpha 1.2 possui um sistema de coleta revisado do alpha 1.1).

O ponto aqui é que os lançamentos, uma vez feitos, são estáveis ​​e semi-permanentes. Se alguém disser que tem um problema com o alpha 1.2, é possível voltar e ver como era o alpha 1.2.

Etapa 2: Bloquear a versão ao vivo

Playtesters devem estar usando seus lançamentos numerados. Isso permite que você concentre seus testes e obtenha comparações razoáveis.

Sua cópia "ao vivo" do documento do Google deve estar disponível apenas para seus colaboradores / colaboradores / acólitos diretos. Esses usuários devem ser "sofisticados" o suficiente para entender que esta versão do documento está em constante evolução. Eles geralmente não precisam de um número de versão ... Se algo não estiver claro, eles devem saber para obter a versão mais recente. Se eles gostaram de algo que aconteceu, eles devem saber que precisam pedir que ele seja reintroduzido.

Integrando alterações de vários colaboradores

Lidar com vários autores é um problema separado dos números de versão. Muitas boas mudanças foram propostas ... Qualquer coisa, desde um documento compartilhado do Google Doc, até o rastreamento de alterações do Office, até softwares de controle de origem, como o Git.

As partes importantes aqui são:

• Todos vocês concordam em como novas versões são lançadas.

• Todos vocês concordam em como resolver conflitos.

• Você tem um fluxo de trabalho que funciona (ou pode ser feito para funcionar) para todos.

Não existe uma bala mágica aqui que permita que todos "façam suas coisas" e funcionem. Você finalmente precisa alguém resolver contradições.

Forks

A complicação final aqui são os garfos: alguém publicando uma nova versão do seu trabalho sob seu controle (e, portanto, seu sistema de versão). Sinceramente, nunca estive nessa situação, mas realmente não há muito que você possa fazer aqui.

Se seu processo for rigidamente controlado, você poderá criar garfos mais permissivos (provavelmente o que aconteceu com o AdEva). Se o seu processo for controlado livremente, você poderá ver os garfos aparecerem de contradições não gerenciadas (o caso extremo é a versão de cada colaborador é seu próprio garfo) ou poderá surgir um garfo com curadoria mais precisa.

De qualquer maneira, os garfos são o resultado da transição do controle de um único autor para o controle da comunidade. Se você está no alpha agora, ainda não está lá.

Use o Google Docs

Tenho experiência no design de regras LARP usando o Google Docs, e foi incrível. As regras LARP, embora sejam tipicamente menores que as regras de RPG de mesa (cerca de cem páginas contra várias centenas de páginas), precisam ser muito mais precisas, porque não haverá presença constante da GM para julgar cada um dos aplicativos das regras. Também os faz passar por muitas iterações, o que também pode causar confusão.

Também tenho muita experiência em usar o Google Docs para diferentes fins, tanto junto com alguém quanto sozinho, eu o uso como meu programa de escritório principal e nem tenho programas de escritório offline normais instalados no meu PC.

Por que você deve usar o Google Docs ou, para ser mais exato, o Google Drive?

1. O Google Drive é essencialmente muito semelhante a uma pasta normal no seu computador. Você pode dividir suas regras em partes que estão todas em uma pasta, diminuindo muito a confusão. Por exemplo, tínhamos regras de combate em um documento separado das regras de economia, portanto é mais fácil entender o que está sendo alterado.
2. É totalmente gratuito. Você só precisa registrar uma conta no GMail. A menos que você precise armazenar arquivos particularmente grandes, o 15 GB gratuito que você recebe deve ser mais do que suficiente. O design do LARP tem um orçamento muito limitado, como é feito por voluntários, e o orçamento é formado por atores cobrindo os custos de sediar o evento, portanto, ser livre é um grande trunfo. Um RPG de código aberto provavelmente não tem orçamento.
3. Requer muito pouco treinamento para usar. Se você for treinado para usar algum software de escritório padrão, como o Microsoft Office ou o Open / Libre Office, aprenderá o Google Docs quase em tempo zero. Basicamente, tudo que você precisa saber é o compartilhamento de configurações e o controle do histórico de versões, que exigem muito pouco esforço especial para serem utilizados. Se você não está interessado em aprender muitas coisas novas e complexas, o Google Docs oferece muitas funcionalidades realmente fáceis de aprender.
4. Ele possui muitos tipos de arquivos suportados: não apenas texto simples, mas também desenhos, planilhas semelhantes ao Excel etc. Usamos uma planilha do Google para cálculos de orçamento, um desenho do Google para a marcação do território do jogo, formulários do Google para aceitar os dados dos jogadores e uma planilha para armazená-lo. Você provavelmente não precisará calcular o orçamento de um RPG de "código aberto", mas poderá usar planilhas para outros cálculos importantes, para os quais normalmente precisaria do Excel.
5. Você pode fazer o download de qualquer arquivo que possa visualizar como qualquer um dos formatos comuns com facilidade, como .odt ou .docx ou .pdf. Você também pode fazer uma cópia separada adicionada ao seu Google Drive.
6. O Google Drive não requer nenhum software especial para fazer o download. Se você possui um dos navegadores comuns, pode usar o Google Drive. Se você possui um smartphone Android, também pode ter o Google Drive totalmente funcional! Também significa que os requisitos do sistema para usar o Google Drive são muito baixos e você pode usá-lo em qualquer PC, mesmo que não tenha permissão para instalar software nele.
7. O Google Drive permite que muitas pessoas editem o mesmo arquivo ao mesmo tempo. Eles verão quais partes estão sendo editadas pelas outras. Pode ser muito bom se todos tiverem uma boa conexão com a Internet ou não tão bem - neste último caso, você terá que evitar editar as mesmas linhas no mesmo documento, mas a maioria dos sistemas que conheço não o permite. tudo! E, novamente, você pode fazer isso se a sua Internet estiver boa, especialmente se você usar algum tipo de comunicação de voz durante a edição, como Discord, TeamSpeak, Skype ou simplesmente ficar juntos durante uma reunião offline. :)
8. Na verdade, você não precisa de uma conexão constante à Internet para editar arquivos no seu Google Drive. Quase toda a funcionalidade do Google Drive está disponível offline. Não tenho experiência em trabalhar off-line apenas por longos períodos de tempo (mais de algumas horas para documentos compartilhados, mais de alguns dias para documentos editados apenas), mas é possível, por exemplo, editar um arquivo para um algumas horas quando você estiver em um trem, e as alterações serão enviadas automaticamente na próxima vez que você tiver uma conexão com a Internet.
9. Você também pode ter arquivos que não são do Google Docs no seu Google Drive. Mas o Google Docs ocupa zero espaço no seu Drive, enquanto os arquivos de terceiros do 3d ocupam espaço.
10. Ele possui um recurso de salvamento automático embutido, que acontece a cada poucos segundos. Você não perderá seu trabalho se a eletricidade desligar repentinamente ou se o seu sistema operacional travar.
11. Nem você pode perder seus arquivos devido a falha no disco rígido. Você pode confiar no Google para armazenar seus arquivos.
12. Ele possui configurações perfeitas de compartilhamento e controle de versão que discutimos nos próximos dois capítulos. :)

Como as configurações de compartilhamento do Google Drive funcionam?

O Proprietário do documento tem todos os direitos para este documento e só podem ser revogados pelo proprietário: o proprietário precisará transferir o documento para outro proprietário.

O Proprietário, entre outras coisas, pode fazer o seguinte com qualquer pasta do Google Doc ou Google Drive:

1. Adicione pessoas específicas com endereços GMail específicos à lista de compartilhamento, atribuindo privilégios específicos a cada uma delas. O proprietário também pode excluir pessoas da lista.
2. Faça um link compartilhável para o documento, atribuindo um nível de garantia qualquer pessoa que recebe o link.

Os níveis de priveledge são, por nível ascendente, são:

1. "Pode ver". Por padrão, seus arquivos não são visíveis a ninguém; portanto, seus dados são privados, mas você pode permitir que pessoas específicas os visualizem ou os compartilhem pelo link com uma quantidade ilimitada de participantes. Aqueles que têm permissão para visualizar o documento também verão o processo de edição, se houver algum. Eles não terão permissão para ver o histórico da versão, compartilhar o arquivo com outra pessoa e tocar nas configurações de compartilhamento. No LARP, usamos essas configurações para os jogadores que têm permissão (e são obrigados!) Para ler as regras, mas certamente não têm permissão para alterá-las.
2. "Pode comentar". Muito útil para seus leitores beta. Aqueles com esse limite privado têm permissão para selecionar uma parte do documento e inserir seu comentário. É muito útil para discutir partes específicas do seu texto. Os comentários são visíveis apenas para outros comentaristas e para aqueles que realmente podem alterar o documento. Os comentaristas também podem sugerir alterações: eles aparecem em uma formatação específica, portanto é fácil distinguir uma sugestão de um texto finalizado. As sugestões não são visíveis para os "espectadores", apenas para aqueles que podem editar o texto e comentar sobre ele. Mesmo se você tiver permissão para editar o documento, pode ser útil usar o mecanismo de sugestões e comentários, para que os espectadores só vejam suas alterações quando estiverem prontos, mas ainda possam acessar o documento pelo mesmo link. Não tínhamos pessoas com permissão para comentar, mas esses recursos eram comumente usados.
3. "Pode editar". Eles podem fazer praticamente tudo: editar o texto diretamente, alterar as configurações de compartilhamento, aceitar e rejeitar as edições sugeridas, excluir comentários e marcá-los como resolvidos, etc. Eles podem ver e usar completamente o histórico de edições. Isso deve ser usado para a equipe de seus colaboradores principais. Mas lembre-se, novamente, de que "editores" também têm a capacidade de sugerir edições, e geralmente é melhor refazer uma parte do texto via edição sugerida e apenas "aceitá-lo" quando o retrabalho estiver pronto para ser apresentado.

Observe que existem os mesmos níveis de limite de privilégio para sua equipe com endereços de email específicos (obviamente, os privilégios de cada membro são separados) e o compartilhamento de links. Se você não fornecer seu link para muitas pessoas, poderá ativar os comentários, mas será uma bagunça se muitas pessoas tiverem esse direito enquanto você também trabalha ativamente no documento.

Se você estiver trabalhando em algo com seu único amigo próximo e apenas com ele, poderá fornecer um link para editar privilégios. Mas, se vazar, qualquer pessoa que encontrar poderá editar o documento.

Para gerenciar as configurações de compartilhamento, clique com o botão direito do mouse no arquivo e pressione "Compartilhar".

Aqui é o manual oficial de compartilhamento.

Como o histórico de versões do Google Drive funciona?

Há uma muito boa manual oficial de controle de versão, mas por uma questão de integridade, vou compartilhar o básico aqui.

Para acessar o histórico da versão, clique no botão direito do botão "Ajuda". Pode ler-se de uma das seguintes maneiras:

1. "Todas as alterações salvas no Drive" - se foi apenas editado por você e as edições foram salvas com sucesso
2. "A última edição foi feita [período da última edição]" - se foi editado por você há algum tempo.
3. "A última edição foi feita [período da última edição] por [autor da última edição]" - se foi editado há algum tempo, e não por você.

Você pode editar quando estiver offline e haverá sinalização de texto se as alterações forem salvas offline ou se algo der errado, mas você não poderá acessar o histórico da versão offline.

Ao clicar neste botão, você verá uma lista de versões (revisões), classificadas por tempo (mais recentes primeiro, mais antigo por último). Para cada versão, você verá a hora e a data e os autores.

Se você clicar em uma revisão, poderá ver uma única edição no texto, incluindo o autor de cada edição, e poderá reverter para a referida revisão.

Se você clicar nos três pontos alinhados verticalmente diretamente ao nome de cada revisão, poderá nomear uma revisão, sinalizando brevemente as edições. Uma opção no canto superior direito permite que você observe apenas as revisões nomeadas ou todas elas de uma só vez.

Você pode sinalizar edições nomeadas no texto, como "Versão 3.1a: blahblah alterada". A melhor maneira de garantir que fique bem claro qual versão você está lendo na impressão é adicionar cabeçalhos: eles serão adicionados automaticamente a todas as páginas se você pressionar "Inserir", depois "Cabeçalho" e depois inserir o nome / número da versão. .

Enquanto estiver trabalhando em um documento, você pode inserir as edições como "sugeridas" e nomear uma revisão sempre que aceitar algo, sinalizando-a no texto. Também é bom ter um log de alterações por escrito. Não precisávamos disso porque não precisávamos seguir nossas regras, mas outros russos que criaram o LARP com o Google Docs (por exemplo, aquele que criou um modelo de medicina muito popular, talvez o mais popular na Rússia) )

Lançando novas versões

Pela minha experiência, é uma péssima idéia permitir acesso à versão ao vivo para quem não deveria editá-la. Depois de fazer uma quantidade substancial de alterações, você pode decidir que está pronto para fazer uma nova versão alfa. O que você deve fazer então?

1. Atualize o changelog, que provavelmente deve estar no começo do seu documento. Quando você está lendo uma versão ligeiramente diferente de algo familiar, é muito fácil perder mudanças importantes. Você pode passar por todas as suas edições no Google Doc desde a última versão e escrever o que mudou desde então. Na verdade, é melhor escrever o changelog enquanto trabalhando em uma nova versão, mas se alguns de seus participantes falharem em fazer tudo certo, talvez seja necessário verificar novamente ou até mesmo decidir fazer toda a versão, o que não é uma má idéia. Não tivemos registros de alterações adequados durante o desenvolvimento, mas tínhamos documentos de "resolução", onde escrevemos o que decidimos mudar em cada uma de nossas reuniões.
2. Atualize o número da versão. Ele deve ser incluído em algum lugar da página de título, para que você possa vê-lo claramente, mas não se esqueça de adicioná-lo também no cabeçalho da página; portanto, se você tiver uma versão impressa e as páginas se separarem, não ficará perdido no caos. . Mude o nome do documento também, para não se perder neles. É uma boa idéia basear o nome da sua versão na data e hora do lançamento e no nome do fork, para que possa ser assim: "Versão 30.11.2017 2: 22 alpha Main_fork", onde "Main_fork" é o nome do seu fork. É melhor inventar algo mais ou menos original, para que seja fácil pressionar Ctrl + F para isso. Não use palavras comuns como nomes de bifurcações.
3. Faça uma cópia do seu documento no seu próprio Drive e congele qualquer edição do documento lançado. Revogue os direitos de edição de qualquer pessoa que tenha acesso a ele, para que não possa editar a versão antiga e não a edite por conta própria. Nomeie o documento antigo exatamente como sua versão e publique-o da maneira que você usar: compartilhamento de links, exportação para PDF, etc.
4. Copie os dados do registro de alterações da versão antiga no registro de alterações principal no final do documento, para ter uma lista total de suas alterações.

Dessa forma, qualquer leitor terá um entendimento muito claro de qual versão está lendo, que alterações foram feitas e, graças às boas ferramentas de controle de versão, será muito fácil marcar as alterações.

Como você pode ter bifurcação?

Como mencionado, o Google Docs possui uma ferramenta interna para fazer uma cópia de qualquer documento que você possa visualizar, incluindo seus próprios documentos. Isso é feito pressionando "Arquivo" e depois "Fazer uma cópia". O problema é que a cópia não é diferente do arquivo original, exceto pelo nome: será chamada "Cópia do [nome do arquivo anterior]". Também não herdar o histórico de versões do arquivo original. Isso significa que você dependerá da marcação manual das alterações de qualquer maneira.

Se alguém quiser bifurcar o seu projeto, você pode executar as seguintes ações, necessárias na sua licença:

1. Faça uma cópia do documento através da funcionalidade "Fazer uma cópia"
2. Nomeie seu novo garfo, substituindo o nome antigo pelo seu próprio. Por exemplo, se o antigo foi chamado "Main_fork", você pode substituí-lo por "Brave_new_fork" nos cabeçalhos da página, na página de título e no nome do documento.
3. Mova o changelog do fork que você copiou no final do documento
4. Inicie seu novo log de alterações com a linha que lê algo como "Bifurcada da versão X da bifurcação Y, chamada Z, no dia DD.MM.AAAA

Como você pode obter uma lista de alterações de um documento?

Vamos imaginar que alguém tenha bifurcado seu RPG, feito uma lista de mudanças populares, mas não conseguiu documentá-las adequadamente. Para encontrá-los, você precisará fazer uma cópia da versão em que se baseia e do próprio documento bifurcado. Você precisa selecionar todos os dados no documento bifurcado e copiar (Ctrl + A, Ctrl + C), selecionar todos e colá-los na cópia do documento da versão antiga (Ctrl + A, Ctrl + V). Você analisa as alterações feitas verificando o histórico de revisões. Você será capaz de documentar você mesmo todas as alterações e, talvez, incorporá-lo ao seu fork principal.

No geral, o Google Docs funciona perfeitamente para pequenos projetos desenvolvidos por pequenas equipes (abaixo, como as pessoas da 10), mas não posso dizer nada sobre algo maior. Observe que, embora eu tenha feito isso por mim, tenho zero experiência com a bifurcação de documentos como esforço da comunidade.

Se você espera que pessoas "comuns" sejam capazes de entender os sistemas de controle de versão e qual versão eles estão visualizando, é necessário simplificar o máximo possível.

Use "Quem" e "Data" como número da sua versão

A chave é, como outros já mencionaram, que você precisa ter "lançamentos" regulares. Não pense nisso como sendo uma versão "ao vivo", existem apenas lançamentos regulares de uma versão de um documento. O número da versão deve ser a data (eu recomendaria o formato ISO 8601 AAAA-MM-DD), bem como quem está liberando (como você está preocupado com as pessoas que mantêm sua própria ramificação). Se você precisar liberar várias vezes ao dia, anexe um número de revisão ou apenas a hora (no seu fuso horário local ou UTC) como "Branco 2017-11-28-1930" (assumindo que você deseja usar "Branco" como o "quem").

Os detalhes de como isso é mantido ou de como é fácil encontrar diferenças entre diferentes versões dependem muito de qualquer software que você esteja tentando usar para ajudar a mantê-lo. Mas se sua pergunta é como "garantir que está clara qual versão de um RPG de desenvolvimento é uma cópia específica", é a única maneira de deixar claro (1) quem a criou e (2) qual versão é , e se é mais antigo ou mais recente que outra versão.

Se você espera que um grupo seja a única equipe a lançar versões, talvez você não precise ter a certeza de ter o "quem" na sua string de lançamento. Porém, se houver garfos, fica claro qual grupo o liberou e outros liberadores ou você pode incluir outras alterações que entenderem (sujeitas às questões usuais de direitos autorais / licenciamento / etc.). É claro que encontrar diferenças poderia ser facilitado com um repositório de controle de origem que todo mundo usa, mas quase todos os programas de processamento de texto têm um recurso "mostrar diferenças"; portanto, se você obtém cópias digitais das coisas, deve ser possível descobrir o que há de diferente entre versão e com uma designação clara de "quem" e "data", deve ficar claro para todos que versão do documento está sendo discutida.

De fato, você pode usar sistemas de controle de versão (por exemplo, Git) com qualquer tipo de arquivo, de modo que sua reclamação sobre texto sem formatação é minimizada. Você pode usar o Git com PDFs e, a menos que você comece a ramificar, o que eu realmente espero que você não necessidade para ... O controle de versão não funcionaria bem? Você pode ter xyz para (edição) (maior) (menor) em algum lugar do arquivo, se você realmente quiser. Basta comprar um repositório particular no GitHub ou configurar outra coisa com uma interface da Web em algum lugar.

Dito isto, por que você está dando a eles viver acesso em primeiro lugar? Certamente você não quer que eles obtenham uma cópia enquanto estiver no meio da frase ... Isso seria confuso! Não faça isso! Para usar uma metáfora de programação, é como dar às pessoas um código que não compila!