Add Community to website navbar, add events to community as subfolder

[mrcdb]

This PR addresses open issues mentioned in #1257 regarding the Events content that is currently conveyed on the TAG security website.

In particular, the PR:

• enables the top-level community folder as a navbar item in the website in place of the existing events page, which is currently managed from website/content
• creates a community/events subfolder in the repository
• moves existing markdown files related to events to the community/events subfolder (also updating naming convention so they all show with hyphens on the website)
• creates README.md files for community/ and community/events for improved website navigation experience
• removes boilerplate community HTML layout

[netlify]

✅ Deploy Preview for tag-security ready!

Name	Link
🔨 Latest commit	a012a19
🔍 Latest deploy log	https://app.netlify.com/sites/tag-security/deploys/6675bce687ec5200085e99f9
😎 Deploy Preview	https://deploy-preview-1281--tag-security.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mrcdb]

I have been trying to fix the linter links check but it looks like a couple of sched links keep returning 429 (too many requests), and I suspect its due to the large amount of links being tested in this PR. I can open the links fine from my laptop. Is there a workaround for that?

EDIT: fixed the issue by increasing retry times and number of retries on the links checker CI job

[brandtkeller]

Thanks for grabbing this off of the #1257 TODO list! Each iteration helps with finding a state of flow.

Community as a navbar item feels appropriate in my opinion. The placement of events among a list of initiatives feels like something we can refine. (maybe we can nest the initiatives under a sub-directory?).

Thoughts on a structure such as:

.
|-- community
|   |-- events
|   |   |-- README.md
|   |-- working-groups
|   |   |-- README.md
|   |   |-- controls
|   |   |   |-- README.md
|   |-- research
|   |   |-- README.md

CC: @eddie-knight @anvega

[eddie-knight]

This highlights an issue regarding sorting past events and future events.

Having this file within events is a dramatic improvement from having it at the repo top level, but does it now require website visitors to click and read the entry to determine whether it is a past or upcoming event? If so, do we have any way to improve that?

Happy to file this as a nit to address in a followup PR, if we have some type of consensus the matter.

[eddie-knight]

@mrcdb @brandtkeller

What if we can set this up to behave like the Blog page? Might be as simple as overriding this layout file with a copy of the blog template. Might also take more work, but WDYT— worth a try?

[eddie-knight]

Some extra formatting will need to be done on each event page to format them correctly, but what do yall think about this as an approach?

[mrcdb]

Blog posts get grouped by year based on their heading, e.g.:

---
title:  "Clusters for all cloud tenants"
date:   2022-06-02 13:04:00 +0200
author: Josh Gavant 
---

I think the best approach would be to create standalone files for each event (both past and future, e.g. each CNSCon event gets its own page) and creating a heading for each of them so that they are automatically grouped based on the year. This would improve readability and fix the sorting issue you mentioned above, but it requires a bit more work as individual files are created for each event.

[eddie-knight]

That matches the approach I used for the image above. If we add the headers to the event files, they will behave like blog posts within this subsection. Then we'd be able to remove the past and future events files.

[eddie-knight]

@brandtkeller @mrcdb Do yall want me to push the commit to this PR or in a follow-up?

[mrcdb]

I can help with updating the event files and checking in the blog-alike layout for community events myself, but please feel free to push any commit to this PR if you have already built some of that 👍

[mrcdb]

@eddie-knight I have pushed an initial commit that would add the events on a timeline similarly to what is done for blogs. the only problem I couldn't fix is how to apply the custom layout to community/events, not sure if this is a Hugo limitation (I am not really an expert on that).

As a workaround, I had to move Events as a top-level menu item so that the custom layout would only apply to the events and not affect the other pages in community, which otherwise wouldn't display correctly.

[eddie-knight]

The last commit seems to be a large divergence from your previous approach 🤔 If you'd like to roll it back, I can make a small commit that allows for a similar result while keeping the Events content in the Community directory.

[mrcdb]

Yep, I did try to make it work (see my comment above) but faced some limitations. I have reverted my previous commit, please feel free to push your commit 👍

[eddie-knight]

Community as a navbar item feels appropriate in my opinion. The placement of events among a list of initiatives feels like something we can refine. (maybe we can nest the initiatives under a sub-directory?).

I like the idea. Stirs up more ideas about community structure... but I'll save those for later.

[mrcdb]

Community as a navbar item feels appropriate in my opinion. The placement of events among a list of initiatives feels like something we can refine. (maybe we can nest the initiatives under a sub-directory?).

@brandtkeller I thought the same when testing out the changes. Having the events page at the same level as each working group sounds a bit inconsistent, I'd second your idea of having a "working groups" folder that includes all the WGs collaterals as sub-folders. Happy to give a try at this in this PR.

[eddie-knight]

@brandtkeller I thought the same when testing out the changes. Having the events page at the same level as each working group sounds a bit inconsistent, I'd second your idea of having a "working groups" folder that includes all the WGs collaterals as sub-folders. Happy to give a try at this in this PR.

What if we modify the directories to have WG at the end of each? We could open this up for discussion as a followup item.

[mrcdb]

@brandtkeller I thought the same when testing out the changes. Having the events page at the same level as each working group sounds a bit inconsistent, I'd second your idea of having a "working groups" folder that includes all the WGs collaterals as sub-folders. Happy to give a try at this in this PR.

What if we modify the directories to have WG at the end of each? We could open this up for discussion as a followup item.

Appending -wg on each WG directory name will improve the clarity of the Community sidebar for sure

[anvega]

Dottore @mrcdb! Nice one.

To respond to @brandtkeller, I don't have strong thoughts on a final structure. It's all fluid, and we can continue to iterate until we arrive at what it should be for now, although the thinking is synchronized with #1283. As part of the lift there, I created an events directory and moved two of the three files. I removed the safe-kubecon.md as it was notes that, due to lack of context, don't mean much to new visitors. It probably still deserves an entry under past events but without the hyperlink to the markdown file.

If you have a look at this document, you can get a view of the current target structure of the repo org. I deliberately didn't contemplate website impact there, so I'll defer on that to you all. It hadn't really been part of the workflow on maintaining the repo until your work that is underway here.

As part of that first #1283, I also moved the workgroup subdirectories under a working-groups directory. There are a few more changes like moving assessments to community/resources and moving the Makefile and dockercompose.yml inside the CI folder and adjusting the Actions workflow, which I'm still working on. I should probably create individual issues and a milestone tracker for visibility for the rest of the work and for us to be in sync.

I didn't create markdown READMEs for community or its subdirectories, so this is a super welcome addition to fix that.

[anvega]

From a sequencing standpoint, we should probably review #1273 given its size, as merging this one first will result in conflicts that won't be easily resolved.

[eddie-knight]

@mrcdb I left a comment above— I don't think this PR is in a good state right now, but if we roll it back I'm happy to add a follow-up PR or commit with the changes needed to get the bloggy behavior in community/events

[mrcdb]

@mrcdb I left a comment above— I don't think this PR is in a good state right now, but if we roll it back I'm happy to add a follow-up PR or commit with the changes needed to get the bloggy behavior in community/events

Agree on that, I just rolled this back to the previous state. Happy for you to add a commit in the repo to get the desired behaviour for community/events (as I wasn't able to get that working without affecting other community pages unless I moved it to a top-level menu item)

[eddie-knight]

LGTM! Thanks Marco.