Propose Separate Repo for Content Contributions

[markcmiller86]

I would like to propose that we handle content contributions in a repo that is wholly separate from the repo we use for BSSw site generation and call it something like bssw-content-contributions.

It would be this new repo where Anyone would submit either issues and/or pull requests capturing content and where we'd iterate with authors, as needed to refine and get that content publication ready. It would be a simple repo, with very little in the way of structure, sort of a free-for-all bucket into which we can pour content without too much concern for organization.

Once content in this new repo is revised and made publication ready there is a step to migrate (or maybe copy) it to its proper location in the bssw publication repo (maybe following this git workflow pattern). Maybe we also migrate history. Or, maybe we leave history in the bssw-content-contributions repo and only the final version appears a single commit to the site repo.

This does probably complicate things a bit. I don't understand the full implications. But, I like the idea of having a sandbox (not to be confused with our IT support vendor) which could potentially be very messy and we won't even care, where content goes to be developed and a separate, very clean and well organized repo that isn't frankly touched by anyone other than a select few (maybe just EB Member) for the published site.

Again, I don't know all the implications here though and so am opening this issue to consider them.

[markcmiller86]

One advantage is separating these repos is that we separate content related dialog and development from site-admin related dialog and development.

A downside could be breaking some of the kinds of automation we are aiming for. For example, if we wanna automate Event issue submission --> publication workflow, having the submission in a different repo than publication could potentially break things.

[bernhold]

A couple of ideas related to @markcmiller86's suggestion, but not related to each other :-)

1. Use branches (within a single repo) to manage development and publication.

   • Advantage: it gets us closer to well-known git workflows.
   • Advantage: we could have a "preview" branch that would be connected to the preview site
   • Disadvantage: this would require some changes on the part of the frontend in terms of how it interfaces to the git repo, but should be do-able.

2. We might find it useful to use separate repos for different types of content. If the workflows and/or automations turn out to be in some way conflicting, for example.

3. Having multiple repos would allow different privacy settings. Obviously private repos are not going to be amenable to direct public engagement, but that may be desirable in some situations. (We've discussed potential concerns about the visibility of reviewer comments even for Curated Content.)

I'm not necessarily advocating any of these ideas right now, just putting them on the table in case we might find them useful in the future.

[markcmiller86]

3. Having multiple repos would allow different privacy settings.

Right, I was thinking the bssw-content-contributions repo would be public but, in theory, the actual site repo could be private. To be honest, that doesn't really do much regarding the conversations we might need to have about content though because I suspect most of those would naturally occur in the bssw-content-contributions repo anyways.

Use branches (within a single repo) to manage development and publication.

I agree we could be using branches more. That said, branches doesn't address one of the key reasons I am proposing separate repos...that we can have one really messy and one really clean.

[jarrah42]

I'm struggling to really see the benefit of doing this. Can't anyone submit issues and PR's now? Is it that people can contribute content without having to be concerned about the structure of the site?

[markcmiller86]

Can't anyone submit issues and PR's now?

Yes, and anything a submitter doesn't do precisely correctly we either have to catch as reviewers and force them to fix (or fix ourselves in their PR) or allow more and more cruft to leak into the repo backing up our live site. IMHO, that is a bit of an iffy way to operate.

Is it that people can contribute content without having to be concerned about the structure of the site?

Primarily, yes. The contributor's bucket doesn't have to be well maintained, clean, nicely structured and organized and re-structured and re-organized when we decide to adjust the structure of the live site or repo backing that up. It means we don't have to explain the structure to to potential submitters or expect them to figure it out. It means we have a clear delineation of site-admin and publication relatd work and content development related work.

[markcmiller86]

It means we have a clear delineation of site-admin and publication relatd work and content development related work.

As @bernhold indicates, we can probably achieve this same goal with an adjustment our git workflow and the use of special branches all in a single repository.

I honestly do not know how workable it might be to have content-development branches (which could potentially be messy) next to a live site branch (for example). Merging from (messy) content development branches to the live site branch might get awkward after a while. I don't know. But, instead of doing multiple repos, this is definitely something we should also look at.

[rinkug]

Is this resolved (to some extent) by the preview branch @bernhold @markcmiller86 @curfman

[bernhold]

Reiterating Rinku's question -- we've evolved our workflow to be very consistent with "traditional GitHub" approaches. To me, this negates any possible benefit of having a separate repo for initial content contributions. My feeling is that forks and branches work fine for our purposes and are more consistent with traditional GitHub workflows so our contributors are more likely to be able to grasp them easily.

So I propose that we close this thread with a "wontdo".

[bartlettroscoe]

I think ship has sailed and I would argue things are working pretty well having the EB docs and content in the same repo. Can we close this as "wontdo"?