wer macht was?

We should probably set down some guidelines on what exactly review means...

Does this include things in the style guide? How about code documentation or user documentation (the latter should probably be an extra bug)

Maybe someone ask Marco what he thinks a good code review should contain?

Aside from that, some general ideas from my side:

• noone should review code they wrote themselves
• prioritize open source code before closed source code in the review process (as we are likely going to run out of time imo)

For user documentation see T9781

I think, the code-review should not cover too much detail, mainly the basics:

• avoid massive amounts of commented-out code
• ensure basic documentation of the classes and members
• look over the copyright and version statements

Marco, do you have any tips/suggestions here?

Should the reviewer fix said problem or just inform the reviewee?

I will take a look at all files in MITK\Modules\DiffusionImaging\Algorithms and post my summary here

I will review MITK\Modules\DiffusionImaging\Tractography

ok, just read that we should not review out own code. sounds reasonable. so i will take a lokk at the rendering folder.

I will have a look at MITK\Modules\DiffusionImaging\Rendering

ok, then I will go through Tractography

So it is Rendering for me.

Correction: Peter is reviewing Rendering, so I will take DicomImport and Reconstruction

Wat is the status on this one and the two bugs that depend on it?