remove files, update readme to note this repo as outdated

[msudol]

Discussing with the team, this repo is to some extent outdated and/or misleading and improved information exists elsewhere. In-line with best practices for deprecating a public github repo.

1. Update the README to explain the repository status and include links and information regarding updated information.
2. Git branch main to a backup branch for historical purposes.
3. Update other links and information through the repository if there are any, eg. wiki, issues, etc.
4. At some point - add outdated or deprecated to the repo title.

This repo continues to be referenced in lieu of more aptly maintained documentation.

An example of what the frontend will look like after merge:

[cweinschenk]

I'm not sure we completely deprecate this. There are lots of folks that use this for the type files and such that are not as easy to use the api for. I think we need to strip logic from the modules since there is out of date, but removing this will result in a ton more work and questions/tickets/file requests.

[msudol]

I'm not sure we completely deprecate this. There are lots of folks that use this for the type files and such that are not as easy to use the api for. I think we need to strip logic from the modules since there is out of date, but removing this will result in a ton more work and questions/tickets/file requests.

That's why I was just advocating to keep it available but mark up the README and note that this repo is currently unmaintained. We can link to the branch with the documentation, but it serves as a sort of disclaimer - note this discussion thread that was asked back in Sept. #39 - it's sort of a 6 of one, half dozen of the other if we're not keeping this repo up to date and keeping with the discussion, also generating works and tickets. Maybe we can find a sweet spot?

[thegioserg]

@cweinschenk,

As @msudol pointed out, I noticed differences between this repo and FSRI's data dictionary. Lots of documentation currently points to this repo as the appropriate source. Our departments haven't onboarded to NERIS, but I'm trying to develop training and coding guidelines in the meantime.

A further complication, the enumerators on the NERIS API Documentation, Swagger, reflect this repo and not the FSRI DD.

[taylorkuno]

I'm not sure we completely deprecate this. There are lots of folks that use this for the type files and such that are not as easy to use the api for. I think we need to strip logic from the modules since there is out of date, but removing this will result in a ton more work and questions/tickets/file requests.

Software developer here. I wanted to provide my perspective on how I've been using this repo in my work.

This repository has been invaluable as a knowledge database that integrates seamlessly with AI coding tools. By having a local copy, I can query AI assistants directly about fire department workflows, terminology, and data structures - enabling me to design more informed and contextually appropriate solutions.

Despite the deprecations, this repo has served as an excellent orientation point for to help my understanding the complex data systems and operational workflows that firefighters use daily. The structured format makes it particularly useful for programmatic exploration and learning.

I hope this developer perspective is helpful! This resource has genuinely saved me weeks of research and domain learning. Thank you for making it available, even as you consider its future maintenance approach.