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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
