$npx -y skills add MLOps-Courses/mlops-coding-skills --skill mlops-collaborationGuide to prepare MLOps projects for sharing, collaboration, and community engagement.
| 1 | # MLOps Collaboration |
| 2 | |
| 3 | ## Goal |
| 4 | |
| 5 | To transform a private project into a public, collaborative resource by establishing **Governance** (License, Code of Conduct), **Documentation** (README, Contributing), **Standardization** (Templates, Workstations), and **Release Management**. |
| 6 | |
| 7 | ## Prerequisites |
| 8 | |
| 9 | - **Language**: Python |
| 10 | - **Platform**: GitHub |
| 11 | - **Context**: Open sourcing or team collaboration. |
| 12 | |
| 13 | ## Instructions |
| 14 | |
| 15 | ### 1. Repository Governance |
| 16 | |
| 17 | Set the rules of engagement. |
| 18 | |
| 19 | 1. **Code of Conduct**: Add `CODE_OF_CONDUCT.md` to foster a safe community. |
| 20 | 2. **Protection**: Protect the `main` branch (require PRs, status checks). |
| 21 | 3. **Review**: Automate preliminary reviews with tools like **Gemini Code Assist** (`.gemini/config.yaml`). |
| 22 | 4. **Ignore**: Comprehensive `.gitignore` (exclude secrets, data, venvs). |
| 23 | |
| 24 | ### 2. Comprehensive Documentation |
| 25 | |
| 26 | Make the project usable and understandable. |
| 27 | |
| 28 | 1. **README.md**: The landing page (Badges, Hook, Quickstart). |
| 29 | 2. **MkDocs**: Use for full documentation sites (API ref, tutorials) when `README.md` gets too long. |
| 30 | 3. **CONTRIBUTING.md**: Guide for developers (env setup, PR process, testing standards). |
| 31 | 4. **CHANGELOG.md**: Generate from **Conventional Commits** with `git-cliff` (replaces Commitizen); commit the rendered file. |
| 32 | |
| 33 | ### 3. Standardization & Workstations |
| 34 | |
| 35 | Eliminate "it works on my machine". |
| 36 | |
| 37 | 1. **Templates**: Use `cookiecutter` for scaffolding and `cruft update` to keep projects synced. |
| 38 | 2. **Workstations**: Add `.devcontainer/devcontainer.json`. |
| 39 | - Define Docker image, extensions, and settings. |
| 40 | - Enable GitHub Codespaces support. |
| 41 | |
| 42 | ### 4. Release Management |
| 43 | |
| 44 | Ship with confidence. |
| 45 | |
| 46 | 1. **Versioning**: Follow **SemVer** (MAJOR.MINOR.PATCH) driven by **Conventional Commits**. |
| 47 | 1. **Changelog**: Generate with `git-cliff` from the commit history (replaces Commitizen/Keep-a-Changelog by hand). |
| 48 | 1. **Workflows**: |
| 49 | - **GitHub Flow**: Small teams, continuous delivery (`main` is stable). |
| 50 | - **Git Flow**: Scheduled releases (`develop` + `release` branches). |
| 51 | - **Forking**: Open source, distributed contributors. |
| 52 | 1. **Process**: Bump version -> `git-cliff` changelog -> annotated `vX.Y.Z` tag (`git tag -a vX.Y.Z`) -> `gh release create vX.Y.Z`. |
| 53 | |
| 54 | ## Self-Correction Checklist |
| 55 | |
| 56 | - [ ] **License**: Is a `LICENSE` file present? |
| 57 | - [ ] **Readme**: Does `README.md` have installation instructions? |
| 58 | - [ ] **Contributing**: Is `CONTRIBUTING.md` clear? |
| 59 | - [ ] **Devcontainer**: Does `.devcontainer/devcontainer.json` exist? |
| 60 | - [ ] **SemVer**: Are releases semver-tagged (`vX.Y.Z`) via `gh release create`? |
| 61 | - [ ] **Changelog**: Is `CHANGELOG.md` generated by `git-cliff` from Conventional Commits? |