[Feature] Prioritization

[amenity]

Per 3/23 Sprint Review, workgroup-specific project prioritization. Already related tables in IMPDB for reference. See

• AMD
• TED
• ATSD
• VZ

[amenity]

@zappfyllc - do you have opinions about implementation here? See Nathan's slides here.

[zappfyllc]

Thanks @amenity, yep, I do. Sorry for the wall-of-text. I'll diagram out what I propose later.

In the "Facilities/Components and Attributes" slide, which I know isn't the focus in this issue (but somewhat related), I think the IMPDB approach makes a lot of sense and there was a lot of thought put forward in generalizing attributes enough to apply to different components. It may not be v1.0 for Moped launch because of how detailed it gets, but if the demand is there from all groups, then I highly recommend it because it's actually a great attempt at delivering the specifics each workgroup needs at the component level without overwhelming complexity within the data model. These "specifics" are so tied to components that I don't think they apply to the program-specific tables but rather the idea of component-related data as a whole, and I'm very much in agreement with the concept.

For the program-specific tables, I believe the same thought and care was taken and I agree with the concept, but I would highly recommend inserting a "program" table in between the component-program relationships as a mechanism for describing program, tracking program metadata, and ultimately setting a path forward in the UI for users to add programs through some sort of workflow or approval process. This will aid in consistency of data structures at the program level where applicable while allowing flexibility and, although it's a bit more thought upfront than simply adding many new table relationships at the component level to fit program needs, it will ultimately reduce complexity at the component level and meet the Moped mission of allowing everyone access and transparency with Moped data.

Instead of consistently adding columns specific to the program for a given component, we can use one column to store the associated program, then a unique ID at a component-program level (e.g. SRTS ID). Imagine a situation where this unique ID column is not null throughout most of the dataset but instead contains unique IDs specified by the program selection.

Another benefit, as alluded to above, is that this allows and specifies a direct mechanism for adding those program-specific cases into the data without constantly impacting currently maintained datasets (project components). Formalizing a process for adding program data helps avoid the concept of a "data gatekeeper": isolated requests and an approval process are totally fine and encouraged but it puts a generalizable structure in place for users to fill out what info they need and who needs it while allowing transparency for others to see/approve those requests.

A future feature or set of features might look like providing an ability to add in programs and generate a program-specific table for their dataset. While this potentially extends scope more than just adding in these tables one-at-a-time, I would argue that it paves the way for a much more streamlined method of adding program-specific data to the Moped model without introducing many dependencies on the most important pieces of Moped (project-level data and components). Again, I'm not suggesting a lack of data curation, approval, etc. but that an application-driven process could help with extending the Moped model for specific use cases. In some situations, it might be more advisable to build a Knack application or utilize another SaaS product to meet those needs.