| 1 |
Currently, to the best of my understanding, QA policies are spelt out |
| 2 |
scattered amongst the devmanual. |
| 3 |
|
| 4 |
|
| 5 |
This makes it very hard to: |
| 6 |
- Know what policies are in place |
| 7 |
- Know how to conform to each policy |
| 8 |
- Cite a given policy |
| 9 |
- Interpret a given policy unambiguously. |
| 10 |
|
| 11 |
Most of the dev-manual is written in the context of "If problem/task X |
| 12 |
-> do Y" |
| 13 |
|
| 14 |
But that doesn't really help for policy documentation. |
| 15 |
|
| 16 |
For policies to be effective, I feel we need something more like a list |
| 17 |
of policies, with numerical identifiers, with a short description of |
| 18 |
the policy (Similar to a GLEP title), which links to a document |
| 19 |
outlining what that policy means in detail. |
| 20 |
|
| 21 |
ie: |
| 22 |
|
| 23 |
[P-0001] Non-maintainer commits |
| 24 |
[P-0002] Maintainer assignment |
| 25 |
|
| 26 |
etc. |
| 27 |
|
| 28 |
Policies that are no longer "current" could be retained, but marked |
| 29 |
"inactive" ( meaning that the policy is no longer in effect, with the |
| 30 |
potential for a policy to be reinstated ), or policies could be marked |
| 31 |
as "tentative", where they're in semi-draft status and are trending |
| 32 |
towards enforcement. |
| 33 |
|
| 34 |
The hope here is that when a policy is violated, a clear citation can |
| 35 |
be made for which policy was violated. |
| 36 |
|
| 37 |
As it stands, it seems to be more like "read the whole dev manual |
| 38 |
again", "try googling the dev manual and get lucky", and sometimes |
| 39 |
"wring your hands over what the dev manual might say", or "ask QA to |
| 40 |
tell you what the policies are". |
| 41 |
|
| 42 |
None of these are ideal. |
Archives