A more hands on review process

[Aaron J. Seigo]

On Thursday 31 July 2008, Stephen Kelly wrote:
> I propose a review process based on review criteria instead of time.
> Reviewers would 'tick the boxes' to confirm that they have reviewed it, and
> what they looked for. Multiple reviewers could tick only some of the boxes
> each if necessary (I'd have no idea if something works on solaris or has
> security flaws for example), and together create a complete review.

would this take the form of a web-based collaboration app? or?

> General
> * The application / library works and performs the expected function.
> * The library / application uses existing kdelibs classes where appropriate
> instead of reinventing the wheel.

or using Qt only ones where there are more appropriate KDE ones.

> Maintainability
> * The application / library is designed for maintainability and is
> consistent with KDE norms.
> * (Libraries only) All public classes use a private d-pointer class.

sounds like in practice there will be a few profiles with different mixes of 
items: "Public Library", "Private Library", "Plugin", "Application"?

> * Complex algorithms and optimizations are sufficiently commented to be
> understandable.
> * Methods are public, protected, virtual and const as appropriate.

this is mostly important for public libraries (though still nice for apps and 
private libs of course)

> Portability
> * The new code has no unnecessary platform specific code, such as
> reading /proc etc. This does not apply to new code which is relevant only
> on specific platforms.
> * The application compiles and runs on Windows, Mac, BSD, Solaris.

this one is going to be very hard to determine as few people have all these 
systems and afaik even fewer of those on the fledgling win/mac platform teams 
follow kdereview. this would be a nice future goal though. perhaps it would be 
good enough for now for these to be optional checkboxes =)

> Documentation and comments
> * All public methods are documented.
> * Private methods and classes are documented where necessary and marked as
> @internal.

this only really matter for public libraries of course, and should probably be 
noted as such or put into a separate heading with other similar things?

> * Comments in the code are appropriate and not excessive.
> * Application user documentation is written

> Style
> * Coding style in consistent with the rest of the library / application

i'd probably just leave this section at that; style is very much a per-project 
(PIM, plasma, dolphin, amarok, etc) thing.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080801/b6ed33c3/attachment.sig>