Creating components in JIRA

[Adam Lally <al...@alum.rpi.edu>]

We should probably create some "Components" in JIRA, under which
issues can be classified.  Two questions: (1) Who has access to do
this?  (2) What components should we have?

(1) I don't seem to have administrator access to JIRA.  Marshall
might, since he is listed as Project Lead.  Or maybe only our mentors
can do this.  The JIRA docs show that if you have administrator access
there should be an "Administration" item on the bar at the top of the
JIRA web interface.

(2) I imagine the components should correspond to our modules:
website
documentation
uimaj-core
uimaj-cpe
uimaj-examples
uimaj-tools
uimaj-ep-configurator
uimaj-ep-debug
uimaj-ep-jcasgen
uimaj-ep-pear-packager
uimaj-ep-runtime
uimaj-adapter-soap
uimaj-adapter-vinci
uimaj-distr

We might drop the uimaj suffix but then would be stuck if later we
have, say, a uimacpp-core module.

-Adam

Re: Creating components in JIRA

[Marshall Schor <ms...@schor.com>]

+1 - you have my go-ahead to do something here along these lines.  These 
look very readable.

-Marshall

Adam Lally wrote:
> On 11/10/06, Marshall Schor <ms...@schor.com> wrote:
>> What's the trade-off between fine-grain (for example - each plugin is
>> it's own component) versus coarser grained (have one thing for all 
>> plugins)?
>>
>> I'm guessing that some good criteria would be:
>>
>>   - obviousness (someone submitting an issue would find it obvious where
>> it goes)
>>   - not too fine grained (otherwise you lose summary info, or list
>> becomes too long - not sure about this)
>>   - each category can have a default initial assignee person
>>
>> My instincts point me toward wanting fewer categories here.  If the list
>> gets to big, it's harder to find things.
>> <snip/>
>
> I'm OK with that fewer categories.  Those seem like good reasons.
>
>
>> website
>> documentation
>> uimaj-core
>> uimaj-collection-processing
>> uimaj-????  (adapters, protocols, transports, ???)
>> uimaj-examples
>> uimaj-tools        <<< other than eclipse
>> uimaj-eclipse-plugins
>> uimaj-build        <<< build, packaging, distribution of uimaj
>> legal        <<< license, etc. issues
>> <snip/>
>
> Category names can have spaces and punctuation.  So we could have 
> names like:
> Website
> Documentation
> Core Java Framework
> Collection Processing
> Transport Adapters -- SOAP, Vinci
> Examples
> Eclipse Plugins
> Tools
> Build, Packaging
> Legal, Licensing
>
>
> We can rename the components later, so this doesn't have to be perfect.
>
> BTW, I do have administration access after all, I was confused.  I
> tested that I was able to create a component (the Website component).
>
> -Adam
>
>

Re: Creating components in JIRA

[Adam Lally <al...@alum.rpi.edu>]

On 11/10/06, Marshall Schor <ms...@schor.com> wrote:
> What's the trade-off between fine-grain (for example - each plugin is
> it's own component) versus coarser grained (have one thing for all plugins)?
>
> I'm guessing that some good criteria would be:
>
>   - obviousness (someone submitting an issue would find it obvious where
> it goes)
>   - not too fine grained (otherwise you lose summary info, or list
> becomes too long - not sure about this)
>   - each category can have a default initial assignee person
>
> My instincts point me toward wanting fewer categories here.  If the list
> gets to big, it's harder to find things.
> <snip/>

I'm OK with that fewer categories.  Those seem like good reasons.


> website
> documentation
> uimaj-core
> uimaj-collection-processing
> uimaj-????  (adapters, protocols, transports, ???)
> uimaj-examples
> uimaj-tools        <<< other than eclipse
> uimaj-eclipse-plugins
> uimaj-build        <<< build, packaging, distribution of uimaj
> legal        <<< license, etc. issues
><snip/>

Category names can have spaces and punctuation.  So we could have names like:
Website
Documentation
Core Java Framework
Collection Processing
Transport Adapters -- SOAP, Vinci
Examples
Eclipse Plugins
Tools
Build, Packaging
Legal, Licensing


We can rename the components later, so this doesn't have to be perfect.

BTW, I do have administration access after all, I was confused.  I
tested that I was able to create a component (the Website component).

-Adam

Re: Creating components in JIRA

[Marshall Schor <ms...@schor.com>]

What's the trade-off between fine-grain (for example - each plugin is 
it's own component) versus coarser grained (have one thing for all plugins)?

I'm guessing that some good criteria would be:

  - obviousness (someone submitting an issue would find it obvious where 
it goes)
  - not too fine grained (otherwise you lose summary info, or list 
becomes too long - not sure about this)
  - each category can have a default initial assignee person

My instincts point me toward wanting fewer categories here.  If the list 
gets to big, it's harder to find things.

Perhaps:

website
documentation
uimaj-core
uimaj-collection-processing
uimaj-????  (adapters, protocols, transports, ???)
uimaj-examples
uimaj-tools        <<< other than eclipse
uimaj-eclipse-plugins
uimaj-build        <<< build, packaging, distribution of uimaj
legal        <<< license, etc. issues

uimacpp-xxx
uimacpp-yyy etc.

sandbox
corpora   <<< future?

-Marshall

Thilo Goetz wrote:
> Adam Lally wrote:
> ...
>> (2) I imagine the components should correspond to our modules:
>> website
>> documentation
>> uimaj-core
>> uimaj-cpe
>> uimaj-examples
>> uimaj-tools
>> uimaj-ep-configurator
>> uimaj-ep-debug
>> uimaj-ep-jcasgen
>> uimaj-ep-pear-packager
>> uimaj-ep-runtime
>> uimaj-adapter-soap
>> uimaj-adapter-vinci
>> uimaj-distr
>
> Looks good to me.
>
>>
>> We might drop the uimaj suffix but then would be stuck if later we
>> have, say, a uimacpp-core module.
>
> ;-) Even I would vote for keeping the uimaj prefix here, unless there 
> is a hierarchical project organization on Jira.
>
> --Thilo
>
>
>
>

Re: Creating components in JIRA

[Thilo Goetz <tw...@gmx.de>]

Adam Lally wrote:
...
> (2) I imagine the components should correspond to our modules:
> website
> documentation
> uimaj-core
> uimaj-cpe
> uimaj-examples
> uimaj-tools
> uimaj-ep-configurator
> uimaj-ep-debug
> uimaj-ep-jcasgen
> uimaj-ep-pear-packager
> uimaj-ep-runtime
> uimaj-adapter-soap
> uimaj-adapter-vinci
> uimaj-distr

Looks good to me.

> 
> We might drop the uimaj suffix but then would be stuck if later we
> have, say, a uimacpp-core module.

;-) Even I would vote for keeping the uimaj prefix here, unless there is 
a hierarchical project organization on Jira.

--Thilo