-
Notifications
You must be signed in to change notification settings - Fork 50
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
[FEAT] - Convert consulting
site blog machinery to match that of labs
site
#396
Comments
I'm not sure why this needs to depend on #182. If #182 is done before this, then when we migrate the blog posts out of Storyblok and Wix, we'll just use the multi-author mechanism in place. If #182 is done after this, then we'll have to go back and fix whatever markdown files are already in place (as we will have to already do with several Labs posts). |
Hm. I guess it depends on where the code for this lives. I was picturing that as part of implementation of this issue, the blog post handling code would get moved to the shared code, and then #182 would be a single fix in that shared code. |
And that the addition of multiple authors to the individual blog posts would be a series of PRs following the merge of #182 |
I'm not strongly tied to this, though -- and I haven't thought it through in careful detail. |
Notes from the 2022-09-19 sprint planning call between @bskinn, @kherma and @tokordys:
|
@kherma -- I've been poking around the Library section of the code and of Storyblok, and the Post Categories data is used by all of the items in the Library: both blog posts and Library Links. Would it be possible to retrieve Post Categories from both the Storyblok data source and the metadata of the blog posts housed in the repo? It seems like that might be less work than migrating both the Library Links and the blog posts to live in the repo...but I'm not sure. From a content-creator-interaction perspective, I think it makes the most sense to keep the Library Links defined in Storyblok, if it's not too hard to achieve. Library Links are most likely going to be added only by Marketing, and Storyblok is the more natural interface there. |
Reproducing here the conversation between @kherma and me in order to attach the discussion to the issue. |
kherma:
bskinn:
kherma:
|
kherma:
bskinn:
kherma:
|
kherma:
bskinn:
|
@trallard @noatamir (cc @gabalafou): Downstream of the above discussion, @kherma pointed out that it would simplify the codebase if both the Consulting and Labs blogs were implemented using a key-value pair for categories: identical machinery could then be shared by both sites. As best I can figure, there would be ~no changes to the Labs blog authorship workflow: the post categories would still be selected by entering category names (the keys, of the key-value pairs) in the metadata header. The only change would be in definition of new categories: both the key (category name) and the value (category slug) would have to be defined. (As a one-time task, the slugs for existing categories in It seems like the best course of action to me. Thoughts? |
There will be no change in the workflow, but that would mean opening PRs to fix the existing posts + opened PRs. So I would rather not have this changed now that we have managed a steady workflow and cadence for the migration, and considering that we have a big backlog of PRs to review and merge.
This makes it sound that consulting and Labs would share categories, in which case this is a hard no for me. While the underlying workflow + system should be the same for both sites - the actual implementation should be tailored to the use cases and whatever makes sense to each site and its audiences. So my vote goes to not changing the Labs workflow or system from its current state at all. |
@kherma has already implemented the Consulting blog machinery conversion in #577 without touching anything in the Labs portion of the codebase, so this is what we will be doing. For completeness, and for possible future reference:
This is not correct. There would be no changes required to Labs blog posts at all. The only Labs staff action would be to review the proposed new values for each category in the key/value mapping introduced in https://github.com/Quansight/Quansight-website/blob/develop/apps/labs/posts/categories.json. These new values would be the slug-like representations of the category names, used e.g. in filtering blog posts for display. For example, the current
This is not correct. They would be independent. Labs categories are defined in https://github.com/Quansight/Quansight-website/blob/develop/apps/labs/posts/categories.json Consulting categories are defined in https://github.com/Quansight/Quansight-website/blob/feat/QUAN-14-llc-blog-machinery-conversion/apps/consulting/posts/categories.json (not yet present on This independent definition would hold even if the Labs categories were converted. |
@bskinn for my understanding: where would we use the new categories slugs in the Labs side? |
@kherma may know of more points of use, but the primary one I'm aware of is in the query portion of the URL for a filtered view of the blogs listing. Viz.:
The new setup would permit (at minimum) custom selection of the slugs used as the URL It would also reduce at least some of the work required for future changes/augmentations to blog-related site machinery, because more of the Labs and Consulting code (again, to emphasize, not the categories themselves) could be directly shared. |
So, the slugs would replace the current categories in the links you mentioned? To clarify, I have no idea if anyone externally is linking to our categories currently, so I am not necessarily concerned. But there are a few older blogs where we were considering linking to the categories as part of the migration (they had links to defunct categories in the old website). I am in general in favor of making this change as I understand that it doesn't cause any significant workflow overhaul to Labs, and it will reduce complexity on future maintenance of both websites. Let's see if Tania mentions some other difficulty that we haven't foreseen?! |
Excellent point, I hadn't thought of that at all. Yes, a change to the slug (not sure about letter-case-only changes) would break incoming and intra-site links to categories: such links would be pointing to a now-nonexistent category, and so the page would list no posts. |
Nope it should pick them up automatically |
What site is this for?
Quansight LLC
Expected behavior
No response
Actual behavior
Upon further internal discussion, we've decided that we want the
consulting
blog to be converted to use the same machinery as thelabs
blog. All posts are to be composed within the repo as Markdown files, and none are to be drawn from Storyblok.Once the functionality of this PR has been implemented, all sixteen (16) of the blog posts currently in Storyblok will need to be migrated before the whole functionality+content package is merged into
develop
.This change should be completed before work on #182 starts, so that the work of #182 can be smoothly applied to both the
consulting
andlabs
blog code.We will need to decide whether we want an RSS feed to be generated for the LLC blog, analogous to the Labs blog. This will require fixing of the RSS machinery first, however, per #403.
How to Reproduce the problem?
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: