Crucible best practices

[J. Caldwell]

Hi all,

I've been working with multiple teams on doing a Crucible(with Fisheye) POC. We've moved on to buying the licenses, but one of the things I'm going to have to produce is a series of best practices. I'm getting feed back from those who have participated in the POC, and read the limited bits in the Crucible docs, but I wanted to see if the community who has more experience with it has any specific practices they have found they needed, if so, what and why?

Thanks

[Sten Pittet · Accepted solution]

Hi,

The first thing I'd recommend to do is to read Geoff Crain's post about code reviews. He's part of the Crucible development team and his post is full of good recommendations to have an optimal review process.

I do have more practical tips around reviews in Crucible, things related to the interface itself. Is that what you're looking for as well?

Sten
FishEye / Crucible Product Manager

[Renjith Pillai]

Some other aspect depending on the culture of the company. There could be occasions in which managers may get suddently interested in the metrics of code reviews in which you may have some issues with Crucible. Another common question I have heard is whether a code review comment is accepted or not. Frankly the focus on review is not about having a status of a comment available in Crucible, but to get the code changed if the review is valid. Some times managers tend to forget this and require that we invent some way to find whether a comment is accepted or not. What we followed was to have a fixed string in the comment which says this.