Closed ekansa closed 9 months ago
@mradamcox You've done lots of customizations with Arches and I think your feedback here would be super valuable. That is if you have the time!
One other thought: Over time Arches has added a lot of patterns for customizations, like search components, datatypes, plugins, workflows, "apps", etc. One thing I've been doing as much as I can in the last couple of years is migrating old, "hand-made" customizations that fit into some of these categories into these new extension patterns as they become available. It may be worth a note that developers keep this in mind not only as they build new Arches implements, but also as they encounter and maintain legacy codebases.
@mradamcox
Thanks for these comments, this is super helpful. Yes, there are SO MANY different pathways to customizing Arches, that it would be great to have some clarity about how to navigate these options. I raised this a the dev standup just now also. I will make that a priority for documentation, but I'll need to do lots of investigation to get my head around the issues.
I'm going to try to incorporate some of your thoughts into this update. Thanks again for the feedback! It's much appreciated!!
brief description of changes
Added high-level guidance for making customizations. Will need to coordinate with the dev team about what customization pathways are best for different scenarios.
issues addressed
None, but we needed to provide some discussion about maintainability in customizing Arches.
further comments
TODO: Add more specifics about to make choices across different kinds of customizations (cards, widgets, extensions, apps..)
Updates can be temporarily read here: https://arches.readthedocs.io/en/dev_m/developing/getting-started/customization-considerations/
This box must be checked
This box should be checked
This box should only be checked you intend to follow through on it (we can do it on our end too)
cherry-pick
all commits in this PR into other branches that should have them after this PR is merged