Francis has blessed the policy, with the loc simple-metric as an
experiment; review to take place in two weeks (to see if it has
crippled our velocity etc); I've added the policy to the process list:
https://dev.launchpad.net/PolicyAndProcess
The new entry points to
https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts
I have updated the policy to cater for the feedback here; included in
it is the actual loc guidelines reviewers need to follow - I've copied
them here for ease of reference. Effectively immediately, all
reviewers need to consider the LoC difference as part of the review -
its not an ironclad rule because of the caveats and the *fact* that we
know this is a proxy metric: use your judgement and lets not get hung
up on it.
Cheers,
Rob
thou shalt not increase the LOC count for (the branch you are landing
code in) unless:
* your work has been blessed by project lead as being resourced in
some way or you are on a resourced arc which will reduce code at the
end (e.g. disclosure) - needs a waiver from the LP Project lead or CDO
Technical architect
* you have a good claim for reducing non-code costs (e.g. less
support tickets) - needs a waiver from the LP Project lead or CDO
Technical architect
* you are moving code to a smaller, leaner and more focused sub-project
* Non-source boilerplate (e.g. copyright notices) may be ignored if
folk can be bothered counting the lines.
