docs: reorganize newsletter archive by year using content tabs

[indexing]

No description provided.

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[github-actions]

Preview url: https://benefits-3820--cal-itp-previews.netlify.app

[thekaveman]

@indexing this is a great idea to reorganize, but I'd like to propose something slightly different:

Since we are in the process of migrating away from HubSpot for Cal-ITP, we need a new home for these archived pages. All of the hs-sites.com URLs will cease to exist by the end of this year. (The question of how we send the newsletter in this world is a separate, but equally important question to answer as well! Let's get back to that at some point soon.)

@Scotchester is working on data exports from HubSpot as part of the transition work. He and I will discuss what it could take to export the entire back-catalog of Benefits newsletters as content that can be migrated into (markdown) pages that live directly in our Docs site.

I would also propose that these don't belong under Reference, but more likely Explanation pages.

In any case, I suggest we press pause on any further restructuring of the current newsletter archive page until we have a better plan for handling the content.

[indexing]

@thekaveman A new way to send the newsletter was on my radar, but deprecating public links to past newsletters wasn't. The migration away from Hubspot runs deep; thanks for the heads-up.

I did some additional exploratory work locally to better present the archived content, but I have yet to commit it. The exploration is quite resolved, and I believe it will work regardless of where the archived newsletters live, so I'm thinking it makes sense to commit it as part of this PR. Any objections or different ways to preserve this work where it is? Let me know if you want to preview the changes as I have them locally.

I have no issues reevaluating where this content lives on the docs site. A number of other pages in Reference seem better organized elsewhere, so perhaps we can scope a small content reorg effort for the Reference bucket.

[jgravois]

@thekaveman: I suggest we press pause on any further restructuring of the current newsletter archive page until we have a better plan for handling the content.

@indexing: I did some additional exploratory work locally to better present the archived content, but I have yet to commit it. The exploration is quite resolved, and I believe it will work regardless of where the archived newsletters live.

makes sense to me for you to push up another commit with work you've already done to share your idea and keep this PR in draft until we figure out a longterm home for the actual newsletters.

personally i wouldn't worry about the merge conflict in this branch until we're actually ready to land it. 👼

A number of other pages in Reference seem better organized elsewhere, so perhaps we can scope a small content reorg effort for the Reference bucket.

i think it makes sense to limit the scope of this PR to rehoming the newsletter archive, but if you have ideas for shuffling others it'd be easy enough to track that in a new issue.

[Scotchester]

@indexing: I did some additional exploratory work locally to better present the archived content, but I have yet to commit it. The exploration is quite resolved, and I believe it will work regardless of where the archived newsletters live.

makes sense to me for you to push up another commit with work you've already done to share your idea and keep this PR in draft until we figure out a longterm home for the actual newsletters.

I'm curious to see what you've cooked up, too, Andy :)

Kegan and I discussed this a little bit at our 1:1 this morning and I'll be looking into how we can export the HubSpot newsletters, but we did talk about how it's worth thinking about whatever the new platform will be in tandem with how we present the newsletter archive, because we don't want to make the process of adding the archived newsletter in the new system way harder than it needs to be.

Specifically, while a one-time conversion of the exported HTML from HubSpot emails to Markdown for the native docs site pages might be simple, it may be too much to ask to do that on an ongoing basis, depending on what we use to send emails post-HubSpot.