-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guest page should show links to all shows with all versions of a guest #117
Comments
The problem I can see with this is that people (more commonly women) sometimes change their names. If we don't want to assign a unique identifier, then we need to link to at least one of their past identifiers.
Because of that, this sounds like the sensible way to handle this. |
I should add that I agree keeping to flat files is the right way to go (and possibly the only way, given that this is a static site generator...?) I don't want to have to pull data elements out of somewhere else. |
Yeah, the guest page is the "source of truth" for data with that guest. If we added an optional frontmatter parameter that was an array of "aka", we could include all episodes with all of the "aka" guests in the list as well as the ones that the guest page already shows. From various conversations with other podcasters, they seem to care less about the retcon issue than ADO does, so as long as we solve this for ADO in the way that makes sense to us, we are good :) |
I care deeply about the retcon issues because I loathe conference systems that can end up putting your new bio next to your old talk description. "Bridget of Pivotal talks about building a Docker-based platform to stream video!" Er, wtf?! =) |
We also should explicitly preserve the option to retcon if it's the right thing to do (for example, if a guest wants us to avoid deadnaming them). |
Well that's easy, right? Just don't create a bkromhout2.md, but keep using bkromhout.md? Or am I missing something? |
@bridgetkromhout so here's how I think it gets implemented: A new (optional) frontmatter field is added to guest pages, called It's totally optional, so if someone wants to retcon, all you have to is change the guest file (of course, you also have to change all references to it, but a mass search and replace would make that okay). I don't see how that's any different than how we do it now, unless I'm missing something. |
This change allows for the "aka" field, which points a guest at another version of their guest file (for example, if a bio changes, a name changes, etc) in the interests of not rewriting history. Fixes #117
This change allows for the "aka" field, which points a guest at another version of their guest file (for example, if a bio changes, a name changes, etc) in the interests of not rewriting history. Fixes #117
For Arrested DevOps, we often times will create a secondary guest file (for example, when a guest's bio becomes out of date, and we don't want to retcon history).
Ideally, when you view a guest's page, the list of episodes should include all of the episodes for all incarnations of that guest.
I prototyped this once, but never committed the code, so i cannot find it. What i'm wondering about is that if you follow the naming standard of firstinitiallastnamenumber (number being optional), I think that a "like" statement in the query works.
Additionally we could add frontmatter to the guest that is "also known as" which would include them. That's probably safer.
The text was updated successfully, but these errors were encountered: