|
| 1 | +# Proposal: Toward a Unified Contributing Experience Across AboutCode Projects |
| 2 | + |
| 3 | +This document outlines a proposal for creating more consistency across contribution workflows in AboutCode repositories. The goal is to make contributing easier for newcomers, reduce friction for maintainers, and simplify CI and development workflows over time. |
| 4 | + |
| 5 | +This is **not** a policy document. |
| 6 | +It is a starting point for discussion based on observed patterns across ScanCode.io, VulnerableCode, DejaCode, Workbench, and other projects. |
| 7 | + |
| 8 | +Feedback and suggestions are welcome. |
| 9 | + |
| 10 | +--- |
| 11 | + |
| 12 | +## 1. Motivation |
| 13 | + |
| 14 | +Across AboutCode projects, contributors encounter several differences: |
| 15 | + |
| 16 | +* Different formatting tools (Black, isort, Ruff). |
| 17 | +* No consistent PR checklist or structure. |
| 18 | +* Some repos use pre-commit, others do not. |
| 19 | +* Different levels of test guidance. |
| 20 | +* No shared branch naming recommendations. |
| 21 | +* No unified guidance around dependency introduction. |
| 22 | +* DCO is required everywhere, but enforcement varies. |
| 23 | + |
| 24 | +Unifying these practices does **not** mean changing project identities. |
| 25 | +It simply makes contributions more predictable and reduces small inconsistencies that create noise in reviews and CI. |
| 26 | + |
| 27 | +--- |
| 28 | + |
| 29 | +## 2. Proposed Areas for Unification |
| 30 | + |
| 31 | +These are suggestions for discussion — maintainers can expand, remove, or refine them. |
| 32 | + |
| 33 | +### 2.1. Common Contributing Flow |
| 34 | + |
| 35 | +A shared baseline across repos: |
| 36 | + |
| 37 | +1. Issue-first: discuss changes before implementation. |
| 38 | +2. Fork → branch → develop → tests → PR. |
| 39 | +3. Keep PRs small and focused. |
| 40 | + |
| 41 | +Most projects already follow this; standardizing the wording would help contributors. |
| 42 | + |
| 43 | +--- |
| 44 | + |
| 45 | +### 2.2. Code Style & Tooling |
| 46 | + |
| 47 | +Many AboutCode projects use: |
| 48 | + |
| 49 | +* **PEP8** conventions |
| 50 | +* **Black** for formatting |
| 51 | +* **isort** for imports |
| 52 | +* **flake8** or **ruff** for linting |
| 53 | + |
| 54 | +A unified recommendation could: |
| 55 | + |
| 56 | +* Clarify preferred formatting/linting tools per project. |
| 57 | +* Optionally move toward a single toolchain for simplicity. |
| 58 | +* Provide a shared baseline `.pre-commit-config.yaml` template that each repo can customize. |
| 59 | + |
| 60 | +This would not replace per-project decisions unless maintainers agree. |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +### 2.3. Pre-commit Hooks (Optional but Helpful) |
| 65 | + |
| 66 | +Many contributors find pre-commit helpful for catching formatting issues early. |
| 67 | +A shared template could simplify onboarding: |
| 68 | + |
| 69 | +```bash |
| 70 | +pip install pre-commit |
| 71 | +pre-commit install |
| 72 | +``` |
| 73 | + |
| 74 | +Each repository could choose which hooks to enable. |
| 75 | + |
| 76 | +--- |
| 77 | + |
| 78 | +### 2.4. DCO Enforcement |
| 79 | + |
| 80 | +All AboutCode projects rely on DCO sign-off, but implementation varies: |
| 81 | + |
| 82 | +* Manual sign-offs |
| 83 | +* CI validation |
| 84 | +* Local commit hooks |
| 85 | + |
| 86 | +Clarifying best practices could reduce accidental CI failures. |
| 87 | + |
| 88 | +--- |
| 89 | + |
| 90 | +### 2.5. Testing Expectations |
| 91 | + |
| 92 | +A common section across repos could clarify: |
| 93 | + |
| 94 | +* When tests are required |
| 95 | +* How to run the test suite |
| 96 | +* What CI will check |
| 97 | +* Expected test structure (if helpful) |
| 98 | + |
| 99 | +--- |
| 100 | + |
| 101 | +### 2.6. Branch Naming (Light Recommendation) |
| 102 | + |
| 103 | +Not a rule, just a helpful suggestion: |
| 104 | + |
| 105 | +* `feature/...` |
| 106 | +* `fix/...` |
| 107 | +* `chore/...` |
| 108 | + |
| 109 | +This aids readability but is optional. |
| 110 | + |
| 111 | +--- |
| 112 | + |
| 113 | +### 2.7. Introducing New Dependencies |
| 114 | + |
| 115 | +A lightweight checklist could help: |
| 116 | + |
| 117 | +* Why is the dependency needed? |
| 118 | +* Is the license compatible? |
| 119 | +* Is it actively maintained? |
| 120 | + |
| 121 | +Many maintainers already consider these factors implicitly. |
| 122 | + |
| 123 | +--- |
| 124 | + |
| 125 | +## 3. Proposed Folder Structure for a Unified Guide |
| 126 | + |
| 127 | +If maintainers agree, each repo could follow: |
| 128 | + |
| 129 | +``` |
| 130 | +CONTRIBUTING.md → short, friendly guide (PR #1) |
| 131 | +docs/unified-contributing.md → optional detailed guidance (this document) |
| 132 | +.github/PULL_REQUEST_TEMPLATE.md |
| 133 | +.pre-commit-config.yaml → optional template |
| 134 | +``` |
| 135 | + |
| 136 | +--- |
| 137 | + |
| 138 | +## 4. Open Questions for Maintainers |
| 139 | + |
| 140 | +1. Should AboutCode standardize on a single formatting/linting toolchain? |
| 141 | +2. Should pre-commit be recommended across repos? |
| 142 | +3. Should we create a shared PR template? |
| 143 | +4. Should each repo adopt a version of the dependency checklist? |
| 144 | +5. Should we define common “make lint” / “make test” targets? |
| 145 | + |
| 146 | +--- |
| 147 | + |
| 148 | +## 5. Next Steps (If Approved) |
| 149 | + |
| 150 | +Future PRs could introduce: |
| 151 | + |
| 152 | +* A shared PR template |
| 153 | +* Optional pre-commit configuration |
| 154 | +* Optional Ruff/Black templates |
| 155 | +* Reusable documentation snippets |
| 156 | + |
| 157 | +Each change would be small and incremental. |
| 158 | + |
| 159 | +--- |
| 160 | + |
| 161 | +## 6. Feedback |
| 162 | + |
| 163 | +This proposal is intentionally broad to allow refinement. |
| 164 | +Suggestions and corrections are welcome. |
0 commit comments