-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add code organization section and update feature flag & permission gu… #93
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for working on this.
@@ -7,7 +7,11 @@ | |||
represents `create:donor` `read:donor` `update:donor` `delete:donor`. | |||
- Don't update roles or permissions directly within Auth0. | |||
- Use Terraform in the [DevOps] repository to update permissions. | |||
- Ensure the [Permissions Matrix] is up to date. | |||
- Ensure new permissions have detailed descriptions. Our customers need to understand |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we state where to document this?
|
||
- Prefer creating packs to encompass business flows (i.e. Processing, Payments). | ||
- Prefer adding pack specific models and concerns inside the pack if possible. | ||
- Prefer setting stewards. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we state where this happens and what it should look like?
- SOPs are impacted | ||
- Training required | ||
- Release flexibility | ||
- Examples where feature flags may not be needed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we bold "may not" to emphasis that these aren't always true.
- Training required | ||
- Release flexibility | ||
- Examples where feature flags may not be needed: | ||
- Label changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I would include this as many of the label changes can impact SOPs, and it is hard to know what is in our customer SOPs.
@@ -0,0 +1,12 @@ | |||
# Packwerk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you title the page code-organization
, but would carry that to this title, then have a "Packwerk" section.
The reason I really like this is because it sparked an idea of documenting how we use "Form Models" or "Service Models" (or maybe they are separate things?) to organize our code over using "Service Objects".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like where you are going @craineum and think we possibly need more of that documented.
We do have a section already with a few OO things here https://github.com/BuoySoftware/guides/tree/1cd099841ca46aeae3aa25d79b9d0154c762db3a/object-oriented-design
So I actually wonder if the OOD pages bullets should be moved here, or vice versa, if we should be putting a Packwerk section in the OOD page and later adding more around what else you have mentioned?
Updating our feature flag and permission guides to reflect changes to our processes. Also adding a new
code-organization
section to start building some guides around our use ofpackwerk
.Updates include:
code-organization
section with a few packwerk guides.