Thanks for the reply, Bo!

The first thing we need to do is decide on a marking system! Ideas?

About who is deciding, I’d say everybody is allowed to propose a marking, which should be backed up by positive and or negative comments about the class. That makes me think maybe having a “Status” or “Evaluation” section of the documentation. The most important/large scale TODOs should be written there, or even better, written there by doxygen! In order for this marking, which is part of the code, to get committed to mainstream, it must pass peer review. I’m afraid too few people are doing that now (me only? and nobody seems to be reviewing my code when I publish it :-( ) but hope there will be more in the near future!

You are right about the big number of classes, but I don’t say that should be done for all existing ones all at once. As code is being refactored and unit tested, it should be marked. I think marking classes is good because, as you already noted in regard to unit testing, the class is the unit in C++ ;-).

Further ideas (from others)?

Regards,

Peter

Bob wrote:Hi Peter,

Good idea! It would be helpful for new comers to know, what can be improved, where the work is.

But my question is, who is responsible to give the mark for the classes. If different people have different filling of quality, who is going to decide the mark?
Another issue is, how many classes Calitko has. Is it too much work to give all classes marks? Or can we mark modules?

Best regards!

Bo

Peter Dimov wrote:

Hello everybody,

I was thinking about how we could have a good measure of how much we are advancing with Calitko. There are undoubtedly at least two measures: quality and quantity. I think we could do an approximation of our overall progress by measuring the change of quantity and quality between releases. When we are adding new classes to solve new problems we directly increase quantity and very likely reduce quality. That will normally be the case because the new code will not be fully functional, not fully tested and not fully documented. When working on existing classes we should expect an increase in quality as functionality, tests and documentation get improved.

I’d propose that we start marking each class with values from 1 to 5 for example (just randomly chosen, we can change them). We could use this as an overall marking for the class, or have separate ranks for functionality, tests and documentation. When somebody is doing code review, one should mark or validate the marking of each of the inspected classes. The evaluator should write in the class docs header what are the problems and what can/should be improved. Once we get Trac (http://trac.edgewall.com) setup for Calitko with Bazaar, the evaluator could also create a tickets for the identified issues.

I’d be expecting some interesting ideas from you guys!

Best regards,

Peter