[Insight-developers] Bug categories in Mantis

Luis Ibanez luis.ibanez at kitware.com
Fri Jun 10 06:58:14 EDT 2011


Thanks for looking into this.

The usefulness of the categories could be tested
by thinking about the kind of queries that developers
would like to make when searching / triaging bugs.


Do we anticipate to search for

           "All the bugs in Core-Common" ?

Do we anticipate to search for

          "All the bugs related to JPEG2000" ?

Do we anticipate to search for

          "All bugs related to IO"  ?


Categories (and all the other fields in MANTIS) should
be populated based on how they will contribute to the
management of Bugs.

Once we craft how we would like to make searches,
it will be straightforward to assign values to categories.

---

Regarding the ephemeral groups (e.g. ITKv4 DICOM),
Note also that MANTIS has "tags", that could potentially
be used to mark such bugs, and facilitate queries by:

           "All the bugs tagged as ITKv4 DICOM"

---

Will add this topic to the agenda,
as well as the need to schedule
a bug triage soon.


     Luis


-------------------------------------------
On Thu, Jun 9, 2011 at 5:51 PM, David Doria <daviddoria at gmail.com> wrote:
> On Thu, Jun 9, 2011 at 9:32 AM, Cory Quammen <cquammen at cs.unc.edu> wrote:
>> Pertaining to this bug
>>
>> http://public.kitware.com/Bug/view.php?id=9541
>>
>> about the use of categories in Mantis, I have some suggestions.
>>
>> In my local projects, I typically have four categories:
>>
>> Code
>> Build
>> Install
>> Documentation
>>
>> For a project as large as ITK, it might make sense to have
>> subcategories of at least the Code category, such as:
>>
>> Code - Bridge
>> Code - Core
>> Code - Filtering
>> Code - GPU
>> ...
>>
>> and so on for the various groups. Individual module names might be too
>> much. Unfortunately, Mantis doesn't provide subcategories by default,
>> hence my naming convention of "Code - ModuleGroup".
>>
>> We might consider categories for initiatives, such as the various
>> refactoring projects going on:
>>
>> ITKv4 - DICOM
>> ITKv4 - Registration Refactoring
>> ITKv4 A2D2 - Deconvolution
>> ...
>>
>> But we may not want those to persist in the bug tracker 10 years from
>> now. Perhaps those would be better as tags?
>>
>> - Cory
>
> Including the module name in or as the category seems reasonable. I
> think so many of the issues would fall under Code (out of Code, Build,
> Install, Documentation) that those probably wouldn't help anything. My
> original concern when reporting that issue was that it just seemed
> silly to have a required field with no options to select from - I was
> not intending/suggesting to change the ITK Mantis workflow :)
>
> I agree that names relevant to particular efforts will not make sense
> if the issues persist after the effort ends.
>
> David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>


More information about the Insight-developers mailing list