[PROPOSAL] Components for JIRA

[Mark Brouwer <ma...@cheiron.org>]

I think we should have in JIRA at least the following components:

   Website (with or without space)
   Infrastructure
   Contributions
   ServiceUI
   JTSK

If the above is not proper we can move afterwards without a fuzz, that
is better than having nothing at the moment.
-- 
Mark

Re: [PROPOSAL] Components for JIRA

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I see, but sometimes a component is at the class level I guess

Seems rare.

> and a complete package name is too wide

For the most part we've found it adequate to stop at top-level packages
within our namespaces.  And it's easy to adopt abbreviation of the
few package prefixes (e.g., com.sun.jini -> csj).
oar_outrigger is shorter than "Outrigger implementation". :)

- Bob

Re: [PROPOSAL] Components for JIRA

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I know Bob and I don't find it very intuitive.
> 
> Dunno how to respond further to that.
> 

I thought it was wise to call it something you couldn't held me
accountable for, saves us both a lot of time ;-)

>
>> I always used 'any' to
>> browse or search with a proper keyword. For example sometimes I was
>> curious to see what kind of issues where against the specs, sometimes I
>> was just interested in implementation details. Going through that pull
>> down menu to select all the relevant packages was one bridge too far.
> 
> I haven't actually used JIRA yet, so I can't comment on its search
> capabilities.  Yes, there are many possible axes that one might want
> to search and/or organize on; that fact shouldn't preclude us from
> picking one.
> 
>> Can you also explain the advantage of such a granular level.
> 
> A typical mode of operation for someone working on a given component
> is to filter down to just the issues for that component, and
> Java package is a good match for component in the starter kit.
> More often than not when reporting a bug you know what package it's in;
> having to figure out how that package maps to some other component
> naming scheme just adds complexity (which is why, as I recall, we
> migrated away from earlier component naming and to package names).

I see, but sometimes a component is at the class level I guess and a
complete package name is too wide. Just searching on a package name or
class name will result in too much garbage i JIRA. But if component is
important I suggest creating a custom field called component (JIRA is
very easy to customize) where we enter the package name or class name,
this component can be individually searched.

The advantage is that the average user who really shouldn't know about
com.sun.jini.outrigger can submit its issue against "Outrigger
implementation". The developer who inspects the issue can then assign
the component and will make all the correction to priority etc.

You can even go wild with process flows to separate between issue
submitted by users and those dealt with by developers, etc. But I think
given the number of issues submitted in the past that is a bit over the top.
-- 
Mark

Re: [PROPOSAL] Components for JIRA

[Bob Scheifler <Bo...@Sun.COM>]

Nigel Daley wrote:
> Bob, perhaps it would be useful to post all the categories (and 
> subcategories?) that you currently have in BugTraq.

Absent interest in using package names, I cease.

- Bob

Re: [PROPOSAL] Components for JIRA

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> With the custom field I told about we can also make it a list with a
> fixed set of options to choose from.

Don't spend time on this just on my account.

- Bob

Re: [PROPOSAL] Components for JIRA

[Mark Brouwer <ma...@cheiron.org>]

Nigel Daley wrote:
> Perhaps the package names worked well for the engineers that originally 
> wrote the code and were the ones filing the bugs.  In addition, the 
> packages for the most part delineated code ownership by engineers.  I 
> think package names as JIRA categories have issues, however, in this new 
> context.
> 
>   - pkg names can change
>   - to encourage bug filing by the largest possible
>     audience, I wouldn't want to assume a submitter knows
>     the pertinent package(s)
>   - a bug can cross package boundaries
>   - there is no code ownership, per se

And it is a list to pick your component from, that means a lot of
scrolling which ain't very user friendly.

With the custom field I told about we can also make it a list with a
fixed set of options to choose from.

> However, I suspect it would be easier for the conversion process if the 
> old categories matched the new ones.  Is that part of the reasoning with 
> sticking to the current categories?

Sounds reasonable. It is very easy in JIRA to 'delete' components and
have all the issues moved over to another component.

BTW and for the mentors, what are the permissions a committer has with
regard to the various JIRA 'administration' tasks?
-- 
Mark

Re: [PROPOSAL] Components for JIRA

[Nigel Daley <nd...@mac.com>]

Perhaps the package names worked well for the engineers that  
originally wrote the code and were the ones filing the bugs.  In  
addition, the packages for the most part delineated code ownership by  
engineers.  I think package names as JIRA categories have issues,  
however, in this new context.

   - pkg names can change
   - to encourage bug filing by the largest possible
     audience, I wouldn't want to assume a submitter knows
     the pertinent package(s)
   - a bug can cross package boundaries
   - there is no code ownership, per se

However, I suspect it would be easier for the conversion process if  
the old categories matched the new ones.  Is that part of the  
reasoning with sticking to the current categories?

Bob, perhaps it would be useful to post all the categories (and  
subcategories?) that you currently have in BugTraq.

Cheers,
Nige

On Jan 5, 2007, at 11:06 AM, Bob Scheifler wrote:

> Mark Brouwer wrote:
>> I know Bob and I don't find it very intuitive.
>
> Dunno how to respond further to that.
>
>> I always used 'any' to
>> browse or search with a proper keyword. For example sometimes I was
>> curious to see what kind of issues where against the specs,  
>> sometimes I
>> was just interested in implementation details. Going through that  
>> pull
>> down menu to select all the relevant packages was one bridge too far.
>
> I haven't actually used JIRA yet, so I can't comment on its search
> capabilities.  Yes, there are many possible axes that one might want
> to search and/or organize on; that fact shouldn't preclude us from
> picking one.
>
>> Can you also explain the advantage of such a granular level.
>
> A typical mode of operation for someone working on a given component
> is to filter down to just the issues for that component, and
> Java package is a good match for component in the starter kit.
> More often than not when reporting a bug you know what package it's  
> in;
> having to figure out how that package maps to some other component
> naming scheme just adds complexity (which is why, as I recall, we
> migrated away from earlier component naming and to package names).
>
>> For some parts I don't see harm in it (when we consider each net.jini
>> package a separate spec), but if somebody (also the uninformed  
>> user) has
>> a problem against Outrigger, he or she would like to assign to
>> Outrigger, the notion of a package name is not very helpful for  
>> such a
>> person.
>
> Anyone dealing with outrigger, even a user, has to know about the
> com.sun.jini.outrigger package name.
>
> - Bob

Re: [PROPOSAL] Components for JIRA

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I know Bob and I don't find it very intuitive.

Dunno how to respond further to that.

> I always used 'any' to
> browse or search with a proper keyword. For example sometimes I was
> curious to see what kind of issues where against the specs, sometimes I
> was just interested in implementation details. Going through that pull
> down menu to select all the relevant packages was one bridge too far.

I haven't actually used JIRA yet, so I can't comment on its search
capabilities.  Yes, there are many possible axes that one might want
to search and/or organize on; that fact shouldn't preclude us from
picking one.

> Can you also explain the advantage of such a granular level.

A typical mode of operation for someone working on a given component
is to filter down to just the issues for that component, and
Java package is a good match for component in the starter kit.
More often than not when reporting a bug you know what package it's in;
having to figure out how that package maps to some other component
naming scheme just adds complexity (which is why, as I recall, we
migrated away from earlier component naming and to package names).

> For some parts I don't see harm in it (when we consider each net.jini
> package a separate spec), but if somebody (also the uninformed user) has
> a problem against Outrigger, he or she would like to assign to
> Outrigger, the notion of a package name is not very helpful for such a
> person.

Anyone dealing with outrigger, even a user, has to know about the
com.sun.jini.outrigger package name.

- Bob

Re: [PROPOSAL] Components for JIRA

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I think we should have in JIRA at least the following components:
>>
>>   Website (with or without space)
>>   Infrastructure
>>   Contributions
>>   ServiceUI
>>   JTSK
> 
> In Sun's existing issue DB, we use Java package names as the
> component granularity for code, and I think it has worked well.

I know Bob and I don't find it very intuitive. I always used 'any' to
browse or search with a proper keyword. For example sometimes I was
curious to see what kind of issues where against the specs, sometimes I
was just interested in implementation details. Going through that pull
down menu to select all the relevant packages was one bridge too far.

Can you also explain the advantage of such a granular level.

For some parts I don't see harm in it (when we consider each net.jini
package a separate spec), but if somebody (also the uninformed user) has
a problem against Outrigger, he or she would like to assign to
Outrigger, the notion of a package name is not very helpful for such a
person.

BTW I expect JTSK to get split in multiple components, but I think it is
nice if we have at least a component for now so we can start. Gregg's
issue is already lingering in the 'unknown'.
-- 
Mark

Re: [PROPOSAL] Components for JIRA

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I think we should have in JIRA at least the following components:
> 
>   Website (with or without space)
>   Infrastructure
>   Contributions
>   ServiceUI
>   JTSK

In Sun's existing issue DB, we use Java package names as the
component granularity for code, and I think it has worked well.

- Bob