State of the contribution rules
Status
Open. This page records which rules for contributions demonstrably apply in this holding and which do not exist. It is superseded once the open points are decided.
Situation
The Projects area leads contributors as far as submitting a change. From there on, rules a project gives itself take over: which branch, who reviews, when it is merged. Part of those rules is written down in this holding and demonstrably in force, another part is not. Without that distinction the most expensive kind of documentation arises: one that asserts a rule nobody has bound themselves to, and which is therefore neither followed nor refuted.
What demonstrably applies
| Area | Rule | How it is evidenced |
|---|---|---|
| Coding style | PSR-12, without rule exceptions | the workspace's checking configuration and the calls composer cs and composer cbf |
| Static analysis | intended, level 4 | the analysis configuration and the call composer stan |
| Commit text | every commit names its work item on a closing line of its own | the holding's project rules; without that line no link arises between work item and code |
| Co-authorship | no model is credited as co-author of a commit | the holding's project rules |
| Acceptance per change | syntax check, boot run, interface texts in five languages, rebuild of the CSS bundle, comparison of the error log | the holding's project rules |
| Language | source comments and documents in the repository English, wiki documentation German, interfaces in five languages | the holding's project rules |
| Author credit | one fixed author and address for own code | the holding's project rules |
| Release signal | the date in the package manifest is the signal by which an update is recognised | the holding's project rules |
| Who decides on contribution | the maintainers of the project concerned, without wiki administration rights | the Mitglieder screen per project; the check lies in Domain/ProjectMembership and is held by tests of its own |
| Limit of that competence | a maintainer grants reader and contributor, not maintainer | the same check; it also refuses a hand-built submission |
| Test invocation | every package with a test directory has a test configuration of its own and is called from its own root | twelve configuration files, all with the same strictness switches |
| Static analysis in practice | all 27 suite packages, level 4, holding frozen | the analysis configuration; a run ends without findings only where nothing new has been added |
| Branch name when giving back | on the level propose the Git endpoint accepts only refs under refs/heads/users/<login>/ and refuses everything else before it reaches the source system; on the level write the barrier does not apply | the check lies in Domain/ReceivePackGuard and is held by tests of its own. None of the four mount templates grants propose; the level arises only from a rule written specially |
What does not exist
| Area | Finding |
|---|---|
| Branching model | No rule. It is not settled which branch a change belongs on, what it should be called or when it disappears again. The technical barrier of the level propose in the first table is not such a rule: it bounds what the endpoint accepts and says nothing about where a change belongs in substance. |
| Review procedure | No rule. Neither competence nor pass criterion is settled. |
| Merge rules | No rule. |
| Versioning | No scheme. The manifest date carries the release signal; a version sequence is not thereby stated. |
| Changelog | No convention. Of the own packages, one keeps a changelog. |
| Reporting route for security holes | None for the own packages. |
| Appointment of maintainers | No rule. Who becomes a maintainer of a project is decided by the wiki administration; by what measure is not settled. |
Consequences
Whoever writes documentation for this area may formulate no rule for the second table. An invented rule is more expensive here than a missing one: it looks like a settlement, gets quoted as one, and binds nobody.
The guide Submit a change therefore describes only what the platform actually does, and names the open points instead of filling them.
Whoever decides one of the open points enters it into the first table, names the evidence and adjusts the affected guide.