have an example_site directoy

[DaveParr]

I'm frustrated that the (top level repo)[https://github.com/satRdays/satRday_site_template] needs to have files like config.toml updated when changes to this repo are made. I also want to be able to have a way to run a command like hugo serve to preview the changes I make to the repo run in this repos root, not have to move up a level to preview them.

The reason for the previous design was to make it easier to make usable repos quickly from the template, without the individual event organisers having to worry too much about making a sub-repo. As it is they need to worry about that anyway when picking up updates, so IMHO my previous plan kind of doesn't work anyway.

Any soultion needs to add to this repo AND also update the top level repo to account for this change.

[jdblischak]

Related to this: I think files like data/schedule/Talk01.toml should be in the example site directory and not included in the theme. As it currently is, it's not possible to display the organizers without also listing these phantom speakers. Even if you deleted data/schedule/ from the top-level site, it still inherits these files from the theme. Including these files directly in the theme was another change made during Hacktoberfest: https://github.com/satRdays/hugo-satrdays-theme/commit/c3b64e44142ab1d4796265703cb9799135f92be9#diff-150e59ddb24eb64e62a4f1307fa077d2de18ee46f0cc33b7d4fa30056da9553b

Please let me know if there is some other way to exclude these files.

[jdblischak]

For now I overrode the default team.html with a version that deleted the speakers section

https://github.com/satRdays/Columbus2021/commit/095803ef2cd156ca0c4126d33f3fa54cf0d7317a

[DaveParr]

@jdblischak I'm really torn about implementing this. I'd really appreciate a second opinion. I have some pros and cons which I'm trying to debate.

Pros

1. it's standard practice in hugo
2. it removes the need to manage sub-modules from the maintainers when developing
3. it removes the need to make sometimes similar changes in 2 repos simultaneously
4. it allows netlify to preview our changes to the build in the theme on a PR request

Cons

1. Setting up a template in production for a specific conference requires more work on the initial deployment. Currently the process is almost 2-3 clicks. The new process would either require the person deploying to build a new root project, add the theme, then deploy OR educating the users to add the theme as a first step
2. Educating the users to not edit the theme submodule directly to achieve what they need (which causes cmplexity down the line if the sub-module needs anupdate), but to copy the relevant assets into the root directoy first, and then edit those

This probably isn't a complete list, but I'm effectively trying to weigh up the burden for people contributing and maintaining the project, who might have a better idea about the hugo best-practices and interals anyway, vs making things as simple as possible at the deployment and customising stages.

Any thoughts?