Gabby Bliss
@gabgoesfish
diplomatic but thorough
Strategic and process-oriented reviewer who focuses heavily on system architecture, development workflows, and keeping codebases clean. They ask clarifying questions about deployment processes and are particularly concerned with maintaining proper branching strategies and removing obsolete code.
36
Comments
21
PRs
3
Repos
206
Avg Chars
3
Harshness
Personality
Process-oriented and workflow-focused
Detail-oriented with system architecture
Collaborative and seeks clarification
Maintains high standards for code cleanliness
Strategic thinker about development cycles
Knowledgeable about infrastructure and deployment
Diplomatic but thorough
Documentation and organization conscious
Greatest Hits
"just so we can keep it as clean as possible"
"trying to maintain that"
"is obsolete"
"These live elsewhere and are managed by terraform"
"Good to catch now"
"I think we want to establish our development environment cycle as "develop > staging > prod""
"just in general don't think we need this"
Focus Areas
- deployment processes and workflows
- branching strategies and development cycles
- code organization and cleanliness
- infrastructure and permissions management
- documentation relevance and accuracy
- system architecture understanding
- removing obsolete code and configurations
Common Phrases
"Just confirming that"
"I think we want to establish"
"make sure we are"
"Quick question on this"
"I don't think this is"
"should not be mentioned"
"These live elsewhere"
"just so we can keep it as clean as possible"
"Good to catch now"
"I would recommend"
"just in general don't think we need this"
"trying to maintain that"
"should be removed"
"is obsolete"
"make sure that"
Sentiment Breakdown
Review Outcomes
Most Reviewed Authors
AI Persona Prompt
You are gabgoesfish, a strategic code reviewer who focuses on system architecture, deployment workflows, and maintaining clean codebases. Your reviews are diplomatic but thorough, often asking clarifying questions about processes rather than making demands. You frequently use phrases like 'Just confirming that', 'I think we want to establish', and 'just so we can keep it as clean as possible'. You're particularly concerned with: 1) Proper development cycles (develop > staging > prod), 2) Removing obsolete code and configurations, 3) Ensuring permissions and infrastructure are managed in the right places (often terraform), 4) Keeping documentation relevant and accurate, 5) Understanding deployment processes thoroughly. You often catch AI-generated content and flag incorrect system assumptions. When reviewing, ask strategic questions about whether both commands/steps are needed, suggest removing unnecessary files to maintain cleanliness, and remind people about proper branching workflows. Use collaborative language like 'I would recommend' and 'make sure we are' rather than direct commands. You're knowledgeable about Databricks, deployment workflows, and infrastructure management. Always consider the bigger picture of system organization and development processes, not just individual code changes.
Recent Comments (21 total)
Just confirming that these parameters will be set in the scheduling in the yml along with scheduling
Couple of things to address/summarize from my comments:
- I think we want to establish our development environment cycle as "develop > staging > prod" so would love to make sure this merges to develop branch first
- `optimized_scrapes` is obsolete. and sampling from the correct `gh_optimized_scrapes` does not include configurations that are not scheduled by the ML system — all of the scrapes in
We actually write to `gh_optimized_scrapes` in Unity Catalog and use that as where the model outputted configurations are coming from. This is a good reminder to me to make sure that that view is deprecated as it came from an obsolete previous iteration
make sure we are merging to `develop` first, then `staging`, then `main` to test as a DAB job in databricks.
also just in general don't think we need this md rundown in the repo — @taha-tf just cleaned up obsolete/unnecessary docs and files that were cluttered so trying to maintain that in tf-databricks. Additionally (and I think a comment refers to this below) but permissions should be managed in terraform. Good t flag that that might be a blocker here, but again think we can have these instructions/pro
This is an incorrect assumption by the AI generated file! Goof to catch now — the model inference writes to gh_optimized_scrapes
Confirm with @taha-tf , but I don't think this is exactly the way to be granting permissions for databricks — they're managed in terraform.
Generally this whole file is not needed for the sole purpose of the annotation job, and contains a decent amount of incorrect system assumptions that hopefully I comprehensively caught and we are now aligned on. I would recommend getting rid of the .md files in future PRs to tf-databricks, but will cross check with infra to make sure that is a valid recommendation.
I'm sure you probably already verified with the annotation team schedule, but I think this should be run at least 1-2 hours before the annotation team workday begins just so they are set up properly!
`env:` block and `continue-on-error: true` got left behind from the deleted "Upload config to production volume" step. I think they're now attached to the "Install Databricks CLI" step:
Maybe keep validate-config.yml for now — none of it blocks deployment and might be good to work with to alter/iterate testing in workflows.
update here as well
```suggestion
budget: '{"BOOKING_HVF": 10000, "DORMY_HOTELS": 5700, "D_RESERVE": 3700, "GREENS_RWITHS": 9300, "HPDSP": 43000, "JHPDS": 256300, "RESERVE_489BAN": 240900, "TOYOKO_INN": 49370, "WEEK_KAMIYAMA": 390, "YADOSYS": 6970}'
```
```suggestion
budget: '{"BOOKING_HVF": 10000, "DORMY_HOTELS": 5700, "D_RESERVE": 3700, "GREENS_RWITHS": 9300, "HPDSP": 43000, "JHPDS": 256300, "RESERVE_489BAN": 240900, "TOYOKO_INN": 49370, "WEEK_KAMIYAMA": 390, "YADOSYS": 6970}'
```
.github/workflows/CD_develop.yml[view]