publiccodenet
introduction/certifying an entire codebase: unclear paragraph
If the audit process is added to an existing codebase, the new merge requests can be
certified, but the existing code cannot be certified. By auditing every new merge request
the codebase can move towards being completely certified.
I found the last sentence unclear because it does not say how many changes or how much time non-certified codebases need to be completely certified.
I would think that a non-certified codebase can become certified even if it's not entirely audited, for example after 6 months of certified pull requests or when 50% of the codebase has been certified, because I know that new pull requests are unlikely to cover 100% of a codebase in a timely manner.
That would be a bad practice, so I imagine at somepoint a full audit will be made, but the paragraph hints that this does not happen and does not state it clearly.
While it is true that new pull requests are unlikely to cover all of the code (eg initial base functionality that works perfectly fine) but we could require a full peer-reviewed refactor (or at least check) of all existing code before certification.
This seems important to, for example, ensure consistent high quality documentation throughout the codebase.
Do you feel this would be reasonable/feasible? If so, any suggestions for how to word this?
With a small codebase or with a well-written one, you can certainly do that. The problem I see is with large codebases with poor code quality and maintainability, where it's going to be too expensive or impossible to review everything.
By auditing every new merge request the codebase can move towards being completely certified.
Then this sentence becomes "illusionary", since that's never going to happen. And it conflicts with the existing code cannot be certified.
What could work is adding an exception to that, by saying that small codebases are going to be reviewed and certified. For example:
If the audit process is added to an existing codebase, the new merge requests can be
certified, but the existing code cannot be certified.
Existing codebases can be reviewed and certified when they meet these criterias:
- A coverage higher than X%
- A line count less than Y
- A mantainability metric below Z
If this text content moves from the body of the Standard to the publiccode.net, the issue should be tranfered as well.
I found the last sentence unclear because it does not say how many changes or how much time non-certified codebases need to be completely certified.
I think the key is in the first sentence in the same paragraph:
For the codebase to be completely certified every meaningful line of code, and the commits behind the code, need to meet the Standard.
Which means that the codebase stewards have to sit down with senior developers to inspect the codebase carefully. That is, it won't automatically change after a certain period of time or number of pull requests, rather it requires some dedicated effort to make sure the entire codebase have been evaluated.
