Ticket content

• Summary
• Software version
• Reproducible in latest version?
• Environment details: compiler/interpreter, operating system, etc.
• Steps to reproduce
• Expected results
• Actual results
• Screen capture (if relevant)

References

• https://codingnest.com/how-to-file-a-good-bug-report/
• https://testlio.com/blog/the-ideal-bug-report/

• Code changes are stored in git
• Setup continuous integration (e.g., GitHub Actions)
• Use dependency management (e.g., uv)
• Have a testing framework (e.g., pytest)
• Define a code standard, enforced through tools and not documentation (e.g., ruff)
• Prefer typed function/method over dynamic types
• On every commit to git
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
    • Code coverage should be recorded during tests and a report made available
• Prior to pushing
  • Use an LLM tool to review the changes to identify potential issues
• On pushes, the CI should
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
• A project repository must have
  • a README.md explaining how to run the project on your own computer
  • a RELEASING.md explaining how to release the code
  • a CHANGELOG.md listing relevant changes made
• Responsibilities are made explicit in terms of roles
• Critical roles, such as project lead, must have a backup/shadow individual
• Setup telemetry, alerts, profiling, logging

• One liner describing what changed (not period terminated)
• A few lines describing in more details why things changed
• GPG signed commit

How to Write a Git Commit Message

• Separate subject from body with a blank line
• Limit the subject line to 50 characters
• Capitalize the subject line
• Do not end the subject line with a period
• Use the imperative mood in the subject line
• Wrap the body at 72 characters
• Use the body to explain what and why vs. how

References

• https://chris.beams.io/posts/git-commit/

When joining a new project without tests, here is the value you need to provide through the addition of tests:

1. the application works and doesn't crash
2. the application works and supports a few input cases
3. the application works and supports a variety of input cases
4. the application works and is robust to most input cases

• Write a test that tests the common case usage of your function
• Write tests that cover edge cases of your function
• Write tests to cover all statements, branches, paths

• Make sure you understand what you have to implement
• Make it work
• Write a test for what you implemented
• Refactor the code for reusability/code standard
• Verify that your code passes linting and tests
• Commit your code on a branch
• Push to the central repository
• Verify that CI passes
• Create pull request
• Annotate code to explain intent of changes