GameBrains / er-core

The Core component for the Epic Remastered project.
Apache License 2.0
0 stars 0 forks source link

Consider separate repository for the Armies section #24

Closed digi-brain closed 2 years ago

digi-brain commented 3 years ago

While it made more sense in the end to put the 'Experimental' rules section inside the Core repository, I think it might make good sense to put the entire Armies section in its own repository. If needed, this new repo could also have its own 'Experimental' section inside it — much as we have in the Core repo, but for stuff that is specific to the Armies repo.

This might pay off in the long run, if we find that we want to organise and delegate community attention on the army lists (away from the largely fixed core rules, not unlike EA community efforts on army lists).

I think that this idea is good, but it is probably worth a little thought in case there are any particular drawbacks. There's no real rush to decide until we get to the point where we're about to add content to the Armies section.

digi-brain commented 2 years ago

I'm still not sure about this. If we do go down the path of separate repositories, then it might make sense to put the Battles content into another repository too.

I need to make time to list the pros and cons I think, not only in terms of organisation and future delegation, but also in terms of navigation in the output and so on.

IJW-Wartrader commented 2 years ago

Yeah, I'm not sure of the pros and cons. But yes, if Armies is in a separate repository then I'd expect Battles to be separate as well.

digi-brain commented 2 years ago

Some thoughts, before I forget again, with respect to the idea of '1 book = 1 component (repository)':

Pros

  1. Simpler versioning. There are two parts to this:
    1. The way that the Antora UI can provide access to different versions of the output. (Not essential, but nice to have.)
    2. The way that we might want to version the different 'books'. I think it's easier to version and communicate 'what's new' when we break each book down as a separate component.
  2. Simpler delegation. I feel that it is important to maintain a certain standard of writing and presentation in the primary rules content — that which is the essential part of the Core component. But we could perhaps be a little less strict with secondary rules content that is typical to the Armies and Battles books. If we put that content in separate components then I think it'll be easier to manage future contributors with looser reins than it would be if they worked inside the Core component.
  3. Freedom to simplify and perhaps flatten the left-hand (secondary) navigation menu a bit. We'll just need to add some links to the top (primary) navigation menu and to the content — we can't rely on the bottom-left 'component' menu for users to switch between components, because they often won't even realise it's there. But this is easy to do, and it will probably make navigation a little easier overall.

Cons

  1. Requires some effort to set up properly. But it isn't excessive and is a one-time operation.
  2. A little more complex to cross-reference content that exists in a different component. But it really just means a longer string to type for the xref macro in such cases, to address the correct component.
  3. Unfortunately, it isn't straightforward to move content between components without loss of the commit history — and this history is in effect the record that gives attribution for people's contributions. But as I understand it, this can be done, and it'd be rare — so this should not be a blocker.
    • Example situation: If a contributor works on a new faction within the Armies component, and wants to develop a new special ability, then they will naturally tend to rough it out in that repository. But, if we want to accept it as a new 'official' ability then it would ultimately belong in the Core component.
digi-brain commented 2 years ago

I've pretty much come down in favour of separate repositories/components for each of the 'books'. I've added the appropriate repositories and keys in GitHub, and I'm developing locally at the moment to test and prepare. So far so good. The potentially tricky bit comes when I attempt to 'go live' with it online — especially when it comes to making sure that the Action runs correctly to build the site correctly with the extra components. This shouldn't be too much trouble, but it's possible that I break it for a while and have to troubleshoot XD

IJW-Wartrader commented 2 years ago

Aye.

digi-brain commented 2 years ago

All done, both on the GitHub side and inside the project code. Published successfully, all seems good.