Refactor data directory

[mattstratton]

See devopsdays/devopsdays-web#133 for a long list of bikeshedding on this.

The model for the data directory should change to look like this:

/data
├── events
│   └── 2016
│       └── ponyville
│           ├── meta.yml
│           └── speakers
│               ├── apple-jack.yml
│               ├── rainbow-dash.yml
│               └── twilight-sparkle.yml
└── sponsors
    └── 2016
        ├── bluthcompany.yml
        └── sitwell.yml

The meta.yml file will contain what is in the current yyyy-city.yml file. Speaker bios go in the "speakers" folder. This way you can have different bios for each year, as they will likely change.

Sponsors directory is also changed YOY as URL's may differ. We will likely also make a change to the /static directory as such:

/static

├── events
│   └── 2016
│       └── ponyville
│           ├── logo.png
│           └── prospectus.pdf
└── sponsors
    └── 2016
        ├── bluthcompany.png
        └── sitwell.png

So each event gets it's own static folder in the appropriate year, as well as each sponsor. The url for the 2016 Ponyville event would be devopsdays.org/events/2016/ponyville/logo.png

This is definitely a 2.0 enhancement, but I want to track it in the theme repo.

[mattstratton]

Mulling this over, I have a few thoughts.

1. We don't really have a speakers data directory going forward, which is nice, so that bit of helpfulness isn't obtained by doing this. Of course, we still need to support it for the old content.
2. I do like breaking up the YAML files, as adding the program to the YAML is making it huge. Having a meta.yml in the event directory, and then a program.yml next to it probably makes it less unwieldy.
3. It would be super rad if we could refactor the content/events directory to be yyyy/city but somehow maintain the url's; I don't think that's really feasible. The reason I bring it up is that I am seeing how tough it is to look though those directories that have potentially hundreds of elements at their root. There might be a way to do it with permalinks, but it seems challenging. The other thing would be to, at some point, cut it over so the URL is now https://devopsdays.org/events/2017/ponyville, etc and put aliases on the old stuff.
4. I'm not sure how I feel about breaking the sponsors directory out that way as it seems that it would create a lot more duplication than it would help.

[bridgetkromhout]

The other thing would be to, at some point, cut it over so the URL is now https://devopsdays.org/events/2017/ponyville, etc and put aliases on the old stuff.

As long as we rewrite URLs I am fine with this.

[mattstratton]

Yep, if we do it with redirects, then the google juice is maintained.

[mattstratton]

I still really like this idea - but this is something to consider in the "off-season" as it's a pretty hefty breaking change. Refactoring the YAML might make the cli tool easier to deal with as well.

[bridgetkromhout]

a pretty hefty breaking change

Which is why I worry greatly. Have you noticed how many people instantiate next year by copying last year? :)

[bridgetkromhout]

I'm not sure how I feel about breaking the sponsors directory out that way as it seems that it would create a lot more duplication than it would help.

Having per-year sponsors seems unneeded at this point. It's so much easier to keep them the same and occasionally update; sponsors who makes changes will do so on their own schedule, not on year boundaries, and so very many cities copy from the past that they'd all be using the previous-year sponsor files if we didn't intervene.

So I guess my question is, does this issue still contain anything we want? If so, let's figure out what that is, for migration to devopsdays-web.