Closed MikeTheCanuck closed 6 years ago
znmeb
commented
6 years ago Snake case, please - local_elections, urban_development, etc. ;-)
Which reminds me - what happens when you rename a GitHub repo? I did it once and I think some things still worked with the old name.
MikeTheCanuck
commented
6 years ago That's a thought Ed. I am morally opposed to underscores for reasons of difficulty-to-see in certain contexts, but character separators of some sort definitely improve at-a-glance parsing/readability.
That would make the proposal:
iant01
commented
6 years ago Do not use underscore if you want to use these in S3 for bucket or folder names. S3 only permits lowecase leters, numbers, periods and dashes. Must start and end with leter or number, can not end in dash, cannot have consecutive periods and can not have a dash adjacent to a period. Bucket names can be up to 63 characters and MUST be unique across all of S3
Although a period can be used in s bucket name, its use is being discouraged as it can cause issuse in certain uses of the bucket name.
bhgrant8
commented
6 years ago @znmeb in regards to repo renaming: https://help.github.com/articles/renaming-a-repository/
MikeTheCanuck
commented
6 years ago Good catch @iant01 - I'm noticing we're using dashes as separators in the GitHub repo names already, so to encourage consistency that suggests we should use dash-separated names throughout.
That would make the proposal:
This meets both the character limitation and the length constraint.
Does anyone know of any technical constraints around using these naming then?
znmeb
commented
6 years ago they don't work as column names, table names or variable names in most situations because the interpreter thinks it's dealing with a subtraction. ;-) But they're fine as file names or in URLs.
bhgrant8
commented
6 years ago It would be good to cut down on project renaming in the future, as such wondering if there is any decision on this?
MikeTheCanuck
commented
6 years ago In the absence of contradictory arguments, I'm going to recommend that you go with transportation-systems wherever you can @bhgrant8, to get you going. I'll take the risk that this gets overridden later and will own the challenge of fixing it if necessary. Thanks for participating!
bhgrant8
commented
6 years ago Thanks @MikeTheCanuck will go head with this.
iant01
commented
6 years ago These can also be used for the project tag value for use in breaking out billing as well as in role/policy definitions for acess control to resources. (Ie. project=housing-affordability ) if the naming setup changes in the future will want to keep tags in sync on resources. disaster-resilience housing-affordability local-elections transportation-systems urban-development
MikeTheCanuck
commented
6 years ago @DingoEatingFuzz Has the "urban development" project been renamed to "neighborhood development"?
MikeTheCanuck
commented
6 years ago Apparently I got misinformation back in January - it's always been known as "neighborhood development".
MikeTheCanuck
commented
6 years ago 
DingoEatingFuzz
commented
6 years ago Due to unfortunate string length limitations within AWS, we created shorter names for each project.
iant01
commented
6 years ago 2018-DS should probably be 2018-DR to match project name Disaster-Resilience
There are a wide variety of places in code and AWS infrastructure where we need to represent each project by a well-known name, such as
and others that don't immediately jump to mind.
The five 2018 project themes are:
We need well-formed strings that will consistently represent each project. In 2017, the projects were known as budget, emerresponse, homelesness, housing and transportation.
We can do better to use fully-spelled-out words and to properly spell the words this time around.
I strongly recommend against shortened (dis_res) or truncated (housing_aff) - last year's attempts at this ended up creating confusion, opportunities for misspellings - and I don't recall any systems where there were character limitations.
Final naming convention