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 <ha...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
