Skip to content

Enforce having the Organizer section broken out into the organizers.yml file #14979

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

Open
mattstratton opened this issue Mar 14, 2025 · 2 comments

Comments

@mattstratton
Copy link
Member

Per discussion in the wg-website slack channel, we would like to require the "organizers" section of the data file to be in a dedicated file (organizers.yml) in the data directory for the event. This will allow us to require specific approvals for changes to organizers on an event, etc.

Currently, in https://github.com/devopsdays/devopsdays-web/blob/main/themes/devopsdays-theme/layouts/partials/functions/get-event-data.html#L15 we support this as an option.

What we could do is change

{{ if fileExists (printf "/data/events/%s/%s/organizers.yml" $year $city) }}

and add an "else" clause that would throw a hugo build error and cause the site to fail to build if the file isn't there.

NOTE: if/when we do this, we will need to have a one time migration utility to break out all the existing "organizer" sections in all the main.yml files into new organizer.yml files in the different event data directories

@toshywoshy
Copy link
Contributor

I still think that when we go down the split up route, we should enforce that also for the program section : program.yml and the sponsor section : sponsor.yml.
This will provide more flexibility and we can add more automation for checks and verifications.

@mattstratton
Copy link
Member Author

I still think that when we go down the split up route, we should enforce that also for the program section : program.yml and the sponsor section : sponsor.yml.

to clarify, we already support these separate files, you're suggesting we also require it to be split out? (I don't disagree, just want to clarify for others that the feature of each of those separate is already there)

I think it makes sense to go ahead and "enforce" all of them at the same time, since if we ever want to do that, the migration work is no harder to do all of them vs doing one of them but each one if we do them one at a time is a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

2 participants