Worldbuilding - Collaboration and Governance #435
-
NavigationThis discussion is divided into four parts:
Introduction: Building a Future TogetherSo. In part one I set out why building a world for Nova is desirable, and put in some guideposts for what the initial frame should be. Now we need to talk about the how. That is, how can a community project work to collaboratively build a universe, supporting the contributions of multiple people without either having everything devolve into incoherence or having one person establish themselves as the ultimate arbiter of who is or is not "canon." Collaborative WorldbuildingTo start, I'm going to link to the Contributing and Governance documents. These documents govern how the community approaches developing the software of Thorium Nova. In my mind, the development of any worldbuilding that ships built in to Nova (and/or Classic) should follow a similar philosophy. That said, Worldbuilding is different than software development[citation needed], and therefore may need a slightly different approach to fulfill the goals of a collaboratively developed future. In addition, I do worry somewhat about clogging up the Discussion and Issues section of the existing Thorium Nova Repo with extended and detailed narrative discussions. So what are our options? There are a couple, each with pros and cons. One would be to create a new project repository on Github for the worldbuilding/mission writing/etc. Another would be to use Google Drive and/or other collaborative writing software. A third option would be using a dedicated worldbuilding software (like Bibisco, Campfire or WorldAnvil), with a custom-built collaboration workflow. Below, I discuss some of the pros and cons for each. Worldbuilding in a GitHub repo.Option one is to create a new GitHub Repository (with its own issues section, wiki, etc) for worldbuilding. The benefits of this are several: first of all, it would integrate relatively well into the existing collaboration workflow. It would let writers use already existing systems for collaborative governance designed for open source development without having to clutter the existing repo issues. It would also give us access to a suite of tools like the Github Wiki System (more on that in the next post). Unfortunately, there are also several substantial issues to this approach. First is simply barrier to entry: Github is a tool build by and for software engineers, and therefore, not everyone who is interested in assisting with worldbuilding & writing will be facile with using version control systems. There are ways to get around this, but all that I can think of are ultimately time consuming kludges that puts both the burden and the authority of integrating ideas from new writers on project maintainers who are familiar with Git. The second issue is related, but in my mind more substantial: because git is designed for software development, there are some inherent limitations in terms of formatting and organization. Basically every file will need to either be plain text, or be formatted with Git markdown, which is, again, difficult to learn for folks who aren't familiar with web development/software engineering. Additionally, while github can manage things like imagery, there are limitations, both in terms of collaboration and in terms of storage space that could quickly become an issue. Worldbuilding on Google DriveThe benefits and issues here are relatively straightforward: nearly everyone knows how to use google drive, and docs/sheets/etc keeps a visual record of any changes that have been made (including complicated formatting changes). What we gain in usability, though, we give up in governance and organization. Do change discussions happen in another document? Just on discord? In the issues section for Nova? Who is given access to the main folder? I genuinely don't know the answers to these questions, but if anybody has experience in collaborative storytelling using Google Drive, I'd love to hear how you approached the problem. Worldbuilding using other toolsThis is, to me, the dark horse. I'm not familiar with most worldbuilding tools, though I do use Bibisco (which is more of a single-user tool) on occasion. In addition to often having steep learning curves, these types of software are rarely free (as in free beer), and the question then arises who pays for it. That said, if someone has a recommendation for a system to use that incorporate the benefits of both options discussed above, I'd love to hear it! Rules for writers, or, The art of "Yes And"If folks have ideas on additional rules or policies that will make the construction of a collaborative world go more smoothly, I'd very much like to hear them! While, so I have been the ones driving this process (with help from Alex and AdminAnon), I don't want this to become "NightRose does Worldbuilding with others given the opportunity to contribute at her discretion." I want this to genuinely be a process where everyone can bring their ideas to the table. I do have one rule that I'd like to add on top of the development governance for worldbuilding: the "Yes, And" policy: ConclusionWhew this got long, so I'm going to wrap up here. You might notice that there is another topic which is implied by this topic: how de we communicate worldbuilding: do we want a fixed document (e.g. a sourcebook) or something more dynamic and interlinked (e.g. a wiki)? That, my friends, is the topic of the next section. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
I agree with almost all of this, especially the "Yes, And" policy. Criticism and suggestions for revision are important and have their place, but they should be the last resort. The focus should be on progress. While I recognize my bias as a developer, I recommend we use Github for most things. Not the git/files aspect, but the project management aspect through issues and discussions. The editor has sufficient WYSIWYG tools that make it easier for beginners to write markdown.
Major proposals should be done in Github discussions. There can be a separate repo for narrative discussions to keep them from disrupting the software development discussions.
Discussions can begin on Discord and then migrate to Github discussions once a critical mass of suggestions have been reached.
I do think that the primary artifacts of this process could be written in Google Drive. Git(hub) has great tools for making suggestions and revisions, but as mentioned those are difficult for non-developers to use. Google Drive's work well and allow us to open suggestions up to anyone with a Google account. Overarching discussions that happen in Github are eventually brought into a Google Drive document somewhere. The governance document describes a Thorium Core Team:
Git makes it very easy for changes to be approved by project leaders with an audit trail to see who changed what at what time. Google Drive doesn't make it quite so easy, so I propose these documents be cared for by members of the Core Team. They'll have full edit access, while anyone else has suggest + comment access. All of these documents should be readily accessible from the Thorium Nova git repo readme, and other places so they're easy to find. Those are all my thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding governance and version control. A quick google search kept coming up that git/github is a great place for version control for writers, even controlling for bias a little bit I was not able to find a better solution. It's not necessarily built for it, but the version control systems in git are second to none. Creating a new repo for Universe would most likely be the best way to go about it. We can include instructions in discord and the repo on the steps people can take to understand the system with the onboarding improving over time as well. This system also gives a bias towards "yes and" for writing as new writers can create a branch and go off of what is already written, then editors can merge different branches as parts start to come together. Editors can parse through the docs and if anything is found to need an overhaul of a rewrite they can go through and fix things as necessary. As for governance. The system written in the governance doc I have not found any issues with and this can be adopted as is for the Universe as it is part of the Nova project.
The nice thing about the discord and discussion boards is that we can break up topics if things start to get too bloated and then merge different discussions as necessary. This can be an ongoing thing with splitting and merging happening relatively quickly without losing any information except for if a discord channel is removed, but the important information will be in the discussion boards and repos.
This is indistinguishable from Alex's fears about Thorium. At some point, we must continue charging forward. One of my goals is to increase outreach and I'll probably be putting together more information on how people can more directly contribute to that. In any case, "build it and they will come." |
Beta Was this translation helpful? Give feedback.
-
|
I'm in general agreement that GitHub, in a separately managed narrative repo, seem to be the best option. I'd also be happy to provide some support for folks who want to contribute but don't feel able to learn Git. I think specific details about formatting and governance documents can be hammered out once we get that repo worked out. With that said, I think that lands us roughly at Lazy Consensus, so I've gone ahead and created a Narrative Repo. I'll finish out the two final conversations in that repo, so we don't clog up the dev conversations any further. |
Beta Was this translation helpful? Give feedback.
-
|
I'll look around for any options as far as some good writing software that will work with git. |
Beta Was this translation helpful? Give feedback.
I'm in general agreement that GitHub, in a separately managed narrative repo, seem to be the best option. I'd also be happy to provide some support for folks who want to contribute but don't feel able to learn Git. I think specific details about formatting and governance documents can be hammered out once we get that repo worked out.
With that said, I think that lands us roughly at Lazy Consensus, so I've gone ahead and created a Narrative Repo. I'll finish out the two final conversations in that repo, so we don't clog up the dev conversations any further.