Dne 13.6.2014 15:16, Martin Vidner napsal(a):
Developer happiness matters to me, but it is hard to quantify. I really enjoyed the progress spreadsheet we had for YCP Killer, and I think it is important to find a meaningful metric and see it improving as we work together. So the most important questions below are Which parts to refactor and How to measure success.
+1 I also enjoyed the YCP Killer project because we had a clear goal (with clear steps) and a metric to measure and evaluate the progress. It was really great to see that at the end of the day that the percentage of the current step was increased. The change was very small (usually just about 2% a day, sometimes more, sometimes less), but it was clear that we were progressing and that we had the right direction towards the target. Anytime during the conversion we exactly knew where we were and how much work was left.
1. Measure code quality everywhere (with metric_fu) and pick the worst code. 2. Measure code changes (metric_fu churn), assuming what has changed in the past will need change in the future. 3. Count bugs. Probably hard on a file level but easy on a package level by counting "bnc" in *.changes. That counts fixed bugs, not reported ones. 4. Count feature requests (done and pending).
I think that (1) is wrong, as it is perfectly OK to leave bad code alone as long as it works.
Yes, and there are some yast packages which are not used much and might be potentially removed in the future. So it's OK to leave them in the current (not perfect) state. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org