GitHub Standards

[gopigof]

This PR introduces a new set of GitHub standards to standardize developer experience for the feminicide repositories.

• Issue Templates: Whenever a new issue is to be created, the format of the issue will be preloaded by GitHub which makes it easier to work with issues
• PR Templates: The Pull Request body will have a template, and streamlines the information required for reviewing a PR
• Python Linter: Ruff (https://docs.astral.sh/ruff/) is a python linter which will auto-lint the code.
• Git Commit Message Standard:
  • Commitizen (https://github.com/commitizen/cz-cli) is a tool that allows for standardized git commit messages and streamlining release management.
  • Each feature commit (commits with feat type) will increase the minor version of the project by 1 automatically. It will also generate changelogs automatically using commit history
  • Here is an example commit history: https://github.com/slarson/minian/commits/master
• Code Formatter: Black introduces automated code formatting. Based on some of the rules defined by Black, all the code changes are formatted on commits.

[rahulbot]

A few initial comments:

• The templates seems fine.
• Big fan of listing and code formatting. Are there any instructions for integrating them with Visual Studio, PyCharm, etc? If so those should be added to the readme. Also 100 feels pretty short for line length, and is closer to PEP suggestion, but we all have widescreens now so can we make it something more realistic like 120?
• Commitizen seems fine as a template for commit messages, but I'm hesitant about handing off version management to that automated process. I see the potential benefit of automatically generating change-logs, but it seems like it will be overly verbose for a small project like this. Also, how would that version number get sync'd with the constant we refer to in code? (processor.VERSION)
• Is there a standard approach to splitting dev and prod requirements? For instance, on prod we don't need black, ruff, etc installed.

[gopigof]

• Updated the line length to 120. I will try to figure out a way to re-run the linter with 120 as the max line length
• I have added instructions on setting up these tools on IDEs (PyCharm for now)
• So, the version is synced with commitizen (it looks at common locations that hold the current VERSION string - pyproject.toml, setup.py, __init__.py, etc.)
• I agree commitizen can be too much for the current manual release cycle. I disabled the version management in commitizen
• The common standard for splitting the requirements.txt file is to use requirements.txt for prod dependencies and requirements-dev.txt for developer tools, test frameworks, etc.

[rahulbot]

(sorry I accidentally changed it from draft to ready, so I just changed it back to draft so you're in control of that)