Create CONTRIBUTING.md
This commit is contained in:
66
docs/CONTRIBUTING.md
Normal file
66
docs/CONTRIBUTING.md
Normal file
@@ -0,0 +1,66 @@
|
|||||||
|
This document outlines the process for developing and contributing to my own thesis project. By following these guidelines, this will ensure consistent quality and maintain a clear development history.
|
||||||
|
|
||||||
|
## Development Workflow
|
||||||
|
|
||||||
|
### 1. Issue Creation
|
||||||
|
Before working on any new feature, experiment, or bug fix:
|
||||||
|
- Create a GitHub issue using the appropriate template
|
||||||
|
- Assign it to myself
|
||||||
|
- Add relevant labels
|
||||||
|
- Link it to the project board if applicable
|
||||||
|
|
||||||
|
### 2. Branching Strategy
|
||||||
|
Use the following branch naming convention:
|
||||||
|
- `feature/<issue-number>-short-description`
|
||||||
|
- `bugfix/<issue-number>-short-description`
|
||||||
|
- `experiment/<issue-number>-short-description`
|
||||||
|
- `doc/<issue-number>-short-description`
|
||||||
|
|
||||||
|
Always branch from `main` for new features/experiments.
|
||||||
|
|
||||||
|
### 3. Development Process
|
||||||
|
- Make regular, atomic commits following the commit message template
|
||||||
|
- Include the issue number in commit messages (e.g., "#42")
|
||||||
|
- Push changes at the end of each work session
|
||||||
|
|
||||||
|
### 4. Code Quality
|
||||||
|
- Follow PEP 8 guidelines for Python code
|
||||||
|
- Document functions with docstrings
|
||||||
|
- Maintain test coverage for custom functions
|
||||||
|
- Keep notebooks clean and well-documented
|
||||||
|
|
||||||
|
### 5. Pull Requests
|
||||||
|
Even working alone, use PRs for significant changes:
|
||||||
|
- Create a PR from your feature branch to `main`
|
||||||
|
- Reference the issue(s) it resolves
|
||||||
|
- Include a summary of changes
|
||||||
|
- Self-review the PR before merging
|
||||||
|
|
||||||
|
### 6. Versioning
|
||||||
|
Follow semantic versioning:
|
||||||
|
- Major version: Significant thesis milestones or structural changes
|
||||||
|
- Minor version: New experiments, features, or chapters
|
||||||
|
- Patch version: Bug fixes and minor improvements
|
||||||
|
|
||||||
|
### 7. Documentation
|
||||||
|
Update documentation with each significant change:
|
||||||
|
- Keep README current
|
||||||
|
- Update function documentation
|
||||||
|
- Maintain clear experiment descriptions in notebooks
|
||||||
|
- Record significant decisions and findings
|
||||||
|
|
||||||
|
## LaTeX Guidelines
|
||||||
|
- Use consistent citation style
|
||||||
|
- Break long sections into multiple files
|
||||||
|
- Use meaningful label names for cross-references
|
||||||
|
- Consider using version-control friendly LaTeX practices (one sentence per line)
|
||||||
|
|
||||||
|
## Experiment Tracking
|
||||||
|
For each experiment:
|
||||||
|
- Create an issue documenting the experiment design
|
||||||
|
- Reference related papers and previous experiments
|
||||||
|
- Document parameters and results in the notebook
|
||||||
|
- Summarize findings in the issue before closing
|
||||||
|
|
||||||
|
## Commit Categories
|
||||||
|
Use the categories defined in the commit template to clearly classify changes.
|
||||||
Reference in New Issue
Block a user