program template

[bridgetkromhout]

@mattstratton - you'd mentioned bikeshedding in an issue around how to make the program - this is my suggestion: #111

Of note:

• url that explains it's the program and uses the speaker names
• aliasing that can be used for former "proposal/this-is-a-title" URL scheme (or my non-SEO-friendly firstnamelastname mashup)
• removing proposals.md entirely since I don't think it should be in the template

[bridgetkromhout]

Open to suggest about better ways we can do this. I don't want to give people too many layers of indirection for building, but the speakers as yaml would probably be better; then we could put the speakers into a speaker page as well as onto their own individual talk pages.

[bridgetkromhout]

Since speakers will have bios and headshots that might need to differ between events, I'm imagining a layout like this:
data/events/2016-minneapolis/config.yml (if we can only have one yaml file, this could read in the other two)
data/events/2016-minneapolis/sponsors.yml
data/events/2016-minneapolis/speakers.yml

and a directory: static/img/events/2016-minneapolis/speakers to use for the headshots.

That way there's good separation when people are editing one type of thing or another.

[mattstratton]

No reason we can't have mulitple yaml files - it will all refer just to whatever query we do.

For example, this is an example bit of code that pulls from the events data directory:

{{ $e := (index $.Site.Data.events $event_slug) }}

there's a goofy thing that happens in go templates/Hugo when you try to shove a variable into a scope.
You think this would work:

{{ $e := (index $.Site.Data.$event_slug "config") }}

but it won't

I think that it would be {{ $e := (index $.Site.Data $event_slug "config") }} (if you want it to read the config.yml when you are pulling a template for a file in the associated city-year directory)

@bridgetkromhout has mentioned she doesn't like having One True YAML File for all the Things, but we might need that at least for a first pass, based upon my imperfect understanding of querying datafiles in Hugo.

[bridgetkromhout]

Okay. Sounds like multiple yaml files is out of scope for the first pass.

I'm going to refactor my PR to use just one.

[mattstratton]

Are we working too hard here? Could we handle most of this with frontmatter instead of a datafile?

You already are creating a markdown file for each talk, which is then doing a lookup to get data. All of the fields that are in the datafile could be frontmatter params - if we create an archetype for the "talk" page type, it would pre-populate the frontmatter as needed.

As a reference, consider how "episodes" work in ADO. (reference - https://github.com/arresteddevops/ado-hugo/blob/master/themes%2Fado%2Flayouts%2Fepisode%2Fsingle.html)

[mattstratton]

So I realized what I was suggesting was exactly what @bridgetkromhout is doing.

One option, which is not delightful, is to have one big data/speakers directory (similar to how data/sponsors works. The downside of this is the following:

1. Bios change over time, so pointing to data/speakers/mattstratton.yml all the time will mean the bio gets updated on older talks, which isn't relevent
2. Alternatively, you could name the speaker file whatever you want (for example, data/speakers/mattstratton-2016-minneapolis.yml), which would mean eventually te data/speakers directory gets huge and messy (probably a bigger deal than the data/sponsors shared directory, since there tends to be a lot more overlap in sponsors than in speakers).

For more information on our attempts in solving this problem, check out this thread on the the Hugo discussion site.

[mattstratton]

Per discussion in Slack:

the thing we might want to do in order to get this to work now is just to name the bios like `2016-mattstratton-chicago.yml` and in the frontmatter of the talk just say `speaker: 2016-mattstratton-chicago`

[7:59] 
it’s sloppy as hell but it works for now

[8:00] 
i would say if we can’t handle the dynamic query by end of week that’s what we do for now

(Basically saying if we don't get this solved by april 15, we will go with option 2 above for now)

[mattstratton]

(Per @bridgetkromhout)

Sort order year-city-speaker or city-year-speaker though
Speaker in the middle is speaker pov but doesn't help a city so much

[mattstratton]

#134 moves this in a good direction. This is close to being done (the speaker bio portion).

In that last PR, things were changed so the bios now live in data/2016/minneapolis (or whatever the city name is)

[bridgetkromhout]

This is done "enough" with #176 documenting that it works.