Add time and venue to the talk pages

[garym]

Just thinking the information may as well be on there as well. It may also make it quicker to spot in the schedule.

[snim2]

Hi @garym do you mean the individual pages with each abstract?

[zeth]

It would be great, won't be me doing it though sadly. There is like 100 of them or something!

[snim2]

It would be great, but the problem is keeping the time / venue information in sync with the schedule page if / when it changes. If a speaker drops out due to illness, etc. then three files will need to be changed -- unless there is a neat way to write a script to make Travis commit this stuff automagically...

[garym]

Hi, I did mean the individual talk pages with the abstract. I did make the assumption that it would be possible to get the information from the same source as the table and that a template for the talk pages could be updated to render this extra bit of information.

I agree that anything more than changing the data in a single place would be subject to too great an opportunity for a human to forget.

I'll have a look at the code if I can just find a bit of time.

UPDATE: ok, I took a peek and my assumption that the schedule might be generated from other data does not seem to hold any water :(

[snim2]

Ah, well the schedule table doesn't have a source of its information, it is the definitive source. There is no db in this deployment, only some templating. If there is a neat and easy way to do this then it would be a useful addition, I think.

[garym]

I've been having a chat with @inglesp who has given me a few ideas.

If we give each slot on the schedule an id then we could create a build step to substitute these ids for talk titles.

Then we can either put the slot ids directly in the talk page metadata or we could introduce another file to specify the mapping between the slot ids and the talk.

I think I prefer the second alternative as I suspect it would be easier to move things around in a single file and be happy that everything makes sense rather than going through all the individual talk pages to update them.

[snim2]

Hmm. This sounds good, I think. So the mapping would be id->url?

[garym]

or id->slug perhaps

[snim2]

I was thinking that, but currently different session types are in different places, content/talks/..., ../content/sprints/... etc. If you use the slug it might be easier to have a single sessions directory.

[garym]

You might be right and I could be over thinking things. I expect the slug is not particularly less subject to change that the url.

[snim2]

They should be identical, except for the directory, I think...