Site announcement

We are switching off article comments on this website. Read about the upcoming changes to Atlassian Documentation.

Skip to end of metadata
Go to start of metadata

Comments in Crucible can be used to flag a defect in the code under review.

To do this, simply check Defect when adding a comment and select a category from the drop-down list.

Screenshot: Defects

You may want to mark comments as defects in order to associate defect classifications, or simply to highlight to the author or moderator that the issue you raised in your comment requires attention. You can use the with defects filter to find files that have been flagged with defects.

(info) Crucible intentionally does not mandate how defects are to be used. The Crucible administrator can customise the defect classifications.

(info) You can only use the defect classifications on comments that are not a reply to an existing comment.

12 Comments

  1. This seems quite poor to me.  To the folks here: Flagging Defects as well.  Yet all comments such as this go unnoticed - or at least unanswered.   If really all you are doing is providing a means to change the background color of the comment from yellow to red, why not supply a color picker?  That would provide way more options!  However, as a user it is important to be able to flag review comments as a defect and have a way to enforce that they are closed and/or addressed prior to closing the review.  Can anyone please comment?

    1. Hi Joe,

      "Crucible intentionally does not mandate how defects are to be used." Please raise a feature request if you would like to see a change here.

      Marking as a defect does more than change the background colour. For example, you can use the 'Show content... with defects' filter to find files that have been flagged with defects.

      regards, Paul

      1. Joseph Gamache: I agree, and I would phrase it even more strongly.  "Flagging Defects" is a broken feature:

        • If you don't edit and unflag it before closing the review, then it looks like X defects made it right through code review and into the code base.
        • If you do unflag it, then there's no way to see that a defect was noted in the code review and subsequently resolved.

        IMO The feature request to resolve this would involve unresolved defects preventing a code review from being closed and forcing a resolution on each defect comment (perhaps a configurable value with options like: "RESOLVED" and "WON'T FIX").  Otherwise, it really is just a view change (color + filter).

        @Paul Watson [Atlassian] - if you included a link to where the feature request should be raised, and possibly gave some tip on how to avoid it being ignored, there's a lot better chance it would get reported.

        1. Additional thoughts now.

          I think it is great that Crucible CAN be used as a standalone project.  However, what about your customer's (like us) that also use JIRA?  There SHOULD be a way the behavior between YOUR TWO tools can be integrated....

          1. Hi Joseph Gamache

            You've been able to create JIRA issues directly from a Review comment for quite a while now.

            The JIRA issue will even have a link back to the Review from which it came.

            See https://confluence.atlassian.com/display/CRUCIBLE/Creating+JIRA+issues+from+the+review

            Cheers,

            Nick

            1. Nick Pellow [Atlassian] - don't you think that is a simple attempt to redirect the comments reflected here rather than address them?  Yes, that feature to 'create an issue' HAS been in the product for a long time - kudos and this is a good feature.  Can you comment on how this is tied in to the "Defects" button?  Further, can you comment that during a review flagging something as a defect does nothing other than change the color of the comment?  Finally, can you comment on what plans there are to enhance this behavior to do useful things such as not allowing a review to be closed when it has open comments marked as Defects?  Often during the code review process it would be inappropriate to log these as JIRA 'bugs'

              1. Joseph Gamache thanks for the response.

                We are definitely addressing the issues and are iterating on the design for how to handle 'Review Tasks' or things that need addressing before a review may be closed.

                (From your previous comment, i thought you were interested in, but not aware of, the Create Issue feature.)

                Can you comment on how this is tied in to the "Defects" button?

                The Create Issue functionality is not tied to Defects in any way.

                can you comment that during a review flagging something as a defect does nothing other than change the color of the comment?  

                Defects currently have no 'state' as such, so apart from setting a flag on the comment and providing a classification for the defect. There are also some reports which can summarise how many and which types are being found for a particular Project.

                Can you comment on what plans there are to enhance this behavior to do useful things such as not allowing a review to be closed when it has open comments marked as Defects

                This is in fact one of the next additions we are planning for Crucible. The current design is to allow a Task to be created from a Defect. The Task can then be marked as Resolved, and a review author will see a warning if they try closing a review with open Tasks. Thoughts ?

                1. Thoughts?  That sounds really good!  As we know though, in this business, the devil is always in the details.  I'm looking forward to seeing such details in the next release.  And thanks for providing the information people were seeking by comments here.

        2. Fair enough, Stanley! The 'Report a Bug' button at the bottom of this page links to the public Crucible issue tracker at http://jira.atlassian.com/browse/CRUC. Once there, click Create issue at the top of your screen, and choose a suitable Issue type, such as 'Bug' or 'New Feature'.

          As you can imagine, issues raised in this way get prioritised according to a number of factors... the more information you can provide about your use case and the impact on your workflow, the better we can understand the improvement and work that may be called for.

  2. If the person who posted the defect to the review leaves the company, is there a way an administrator can edit the defect for them, or transfer ownership to another user, so that Classification fields on those defects can be updated/corrected?

     

  3. One thing I would add to this discussion.  There should be additional workflow options around defects.  

    For instance in my organization a defect can only be resolved by the person that raised the defect or the moderator of the review (we use code collaborator currently).  As a large organization this is important for us because it indicates that the issue has been fixed to the reviewers satisfaction.

    We would love to switch to crucible to get better JIRA integration but can't currently.  It would be a large feature add but I would suggest just copying the defect functionality from code collaborator.  We like crucible better in many respects but this is a deal breaker for us unfortunately.

    1. Hi Adrian,

      Thanks for your feedback. We have an open feature request for this feature and you might be interested to add your feedback there.

      While I cannot give you a deadline for this development I can tell you that we are actively looking at better support for workflows during reviews. It mat not be exactly what Code Collaborator has but it would serve the same purpose to help team handle outstanding tasks coming out of a review. We're aiming at shipping those improvements in the next 6 months.

      Thanks,

      Sten Pittet
      Product Manager