[hibernate-dev] Micro Jiras

Gunnar Morling gunnar.morling at googlemail.com
Sun Mar 11 11:19:42 EDT 2012


Hi,

another approach would be to utilize different Jira issue types (and
in particular sub-tasks) for this.

High-level issues (typically a complete functionality, bug report
etc.) would be represented by top-level issue types ("New Feature",
"Bug" etc.) while fine-granular tasks (the "to do" granularity) would
be represented by sub-tasks which are associated to one top-level
issue.

Taking the method validation feature for Bean Validation 1.1 as
example, there is a top-level issue, BVAL-241 ("Support for method
validation", [1]), and several linked sub-tasks: BVAL-244 ("Extend
Validator API with methods for method validation", [2]), BVAL-242
("Extend the meta-data API to represent method-level constraints",
[3]) etc.

While top-level issues are typically created by users and developers,
sub-tasks are typically only created by developers to structure their
work. For the release log, only top-level issues would be considered
as the sub-tasks are not really relevant there.

I've made pretty good experiences with that scheme, and I guess it's
simpler than handling two tools or JIRA instances (plus it establishes
a link between the different type of issues).

--Gunnar


[1] https://hibernate.onjira.com/browse/BVAL-241
[2] https://hibernate.onjira.com/browse/BVAL-244
[3] https://hibernate.onjira.com/browse/BVAL-242



2012/3/11 Hardy Ferentschik <hardy at hibernate.org>:
>
> On Mar 11, 2012, at 2:49 AM, Steve Ebersole wrote:
>
>> Another though occurred to me is that one of the really nice things about Jira is keeping track of my todos. If I am working on some piece of code and realize I need to do some work it is much nicer to create a Jira rather than (a) adding a todo comment or (b) getting side-tracked from my current task.
>>
>> In the end not sure there is really a right answer here. But ultimately Jira is first and foremost a development team tool. In the end, I am not sure creating less-granular issues is the best choice. In retrospect maybe a separate project for tracking the granular issues might have been better. We would commit work against both a single high-level HHH issue and the particular granular one. Just a brain storm.
>
> I think distinguishing between granular and less-granular makes sense. As I already said, I think our public Jira should be more on a less-granular. I remember (back in the days) when I was a Hibernate users and tried to hunt down a problem X. My search chain would be, Google, Forum, Jira. When using Jira I would then often find a bug report for the problem I was seeing. By creating issues on a too  granular level you are making the latter harder imo.
>
> Personally I use a different tool for todos, e.g. RememberTheMilk. I don't think that a separate Jira project would be needed for that, nor am I convinced that Jira is the best tool for this type of things. However, if given the choice I would prefer the two Jira instances approach over the single instance one. Or at least give it a try.
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev




More information about the hibernate-dev mailing list