Reorganizing JIRA components

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Reorganizing JIRA components

Shai Erera
Hi

I noticed that we don't have a component for every contrib/module today, as well as some components are misplaced, due to recent changes (e.g., analysis should be IMO under modules/analysis).

I would like to propose the following reorganization to JIRA components:
* core/index, core/search etc. -- for all *core* issues
* modules/<name> for every module issues
* remove modules/*

As for modules/<name>, I think we should start w/ the existing modules that are already listed in JIRA and add additional ones "on demand". That way, if 1 year from now we look at JIRA and don't find a modules/xyz, we know that module was inactive for one year and can consider removing it entirely (this follows a proposal made by Grant a while ago about removing unused/unmaintained contribs).

By removing modules/*, we force anyone who wants to report an issue about a module for which we don't have a JIRA component yet, asking first to open such a component. This might look a big overhead, but it's something we'll do only once, and I think we can already identify the 'active' modules and pre-create components for them.

As for an "other" component, I think it'd be best if we can avoid it. What do you think?

Shai
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing JIRA components

Mark Miller-3

On May 15, 2011, at 2:20 PM, Shai Erera wrote:

> Hi
>
> I noticed that we don't have a component for every contrib/module today, as well as some components are misplaced, due to recent changes (e.g., analysis should be IMO under modules/analysis).
>
> I would like to propose the following reorganization to JIRA components:
> * core/index, core/search etc. -- for all *core* issues
> * modules/<name> for every module issues
> * remove modules/*
>
> As for modules/<name>, I think we should start w/ the existing modules that are already listed in JIRA and add additional ones "on demand". That way, if 1 year from now we look at JIRA and don't find a modules/xyz, we know that module was inactive for one year and can consider removing it entirely (this follows a proposal made by Grant a while ago about removing unused/unmaintained contribs).
>
> By removing modules/*, we force anyone who wants to report an issue about a module for which we don't have a JIRA component yet, asking first to open such a component. This might look a big overhead, but it's something we'll do only once, and I think we can already identify the 'active' modules and pre-create components for them.

+1, all sounds good to me.

>
> As for an "other" component, I think it'd be best if we can avoid it. What do you think?

Sure - other will likely be not picking a component - common enough.

>
> Shai

- Mark Miller
lucidimagination.com

Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing JIRA components

Shai Erera
Thanks Mark.

Is it technically ok to rename existing components? Will the JIRA issues assigned to that component "survive" the rename?

Sure - other will likely be not picking a component - common enough.

I was aiming at avoiding that scenario. I think every issue should be assigned to a specific component, and if there isn't one available, we should create it. Nevertheless, an 'Other' component will make contributions easier (i.e., the person who opens the issue doesn't need to ask for a new component beforehand), and we can always review all the 'Other' issues and assign them to the right component before a release.

Shai

On Mon, May 16, 2011 at 2:48 AM, Mark Miller <[hidden email]> wrote:

On May 15, 2011, at 2:20 PM, Shai Erera wrote:

> Hi
>
> I noticed that we don't have a component for every contrib/module today, as well as some components are misplaced, due to recent changes (e.g., analysis should be IMO under modules/analysis).
>
> I would like to propose the following reorganization to JIRA components:
> * core/index, core/search etc. -- for all *core* issues
> * modules/<name> for every module issues
> * remove modules/*
>
> As for modules/<name>, I think we should start w/ the existing modules that are already listed in JIRA and add additional ones "on demand". That way, if 1 year from now we look at JIRA and don't find a modules/xyz, we know that module was inactive for one year and can consider removing it entirely (this follows a proposal made by Grant a while ago about removing unused/unmaintained contribs).
>
> By removing modules/*, we force anyone who wants to report an issue about a module for which we don't have a JIRA component yet, asking first to open such a component. This might look a big overhead, but it's something we'll do only once, and I think we can already identify the 'active' modules and pre-create components for them.

+1, all sounds good to me.

>
> As for an "other" component, I think it'd be best if we can avoid it. What do you think?

Sure - other will likely be not picking a component - common enough.

>
> Shai

- Mark Miller
lucidimagination.com

Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing JIRA components

Mark Miller-3

On May 15, 2011, at 10:42 PM, Shai Erera wrote:

> I was aiming at avoiding that scenario. I think every issue should be assigned to a specific component, and if there isn't one available, we should create it.


Based on history and how these things normally go, unless you are planning on spending a *lot* of time curating JIRA for the forceable future, this is an unlikely outcome. Better categories will hopefully mean more compliance, but I'd bet the standard hodgepodge of JIRA submissions and curation is going to remain fairly similar to what we have seen. Version is a much more important field - and even it is not curated even close to this 'ideal' world level.

I think every issue should be fully filled out, correctly filled out, cross linked with all relevant issues, etc, etc.

But I don't plan on it being the normal scenario ;)

FWIW: I fill out component sometimes, and other times I'm just not worried about it. Someone can always come along after us types and random users and clean up after them, but I surmise that won't last long.

- Mark Miller
lucidimagination.com

Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing JIRA components

Shai Erera
I renamed all current components, plus deleted two (contrib/analyzers and contrib/wikipedia). 

core/codecs
core/index
core/other
core/query/scoring
core/queryparser
core/search
core/store
core/termvectors
general/build
general/javadocs
general/test
general/website
modules/analysis
modules/benchmark
modules/examples
modules/grouping
modules/highlighter
modules/other
modules/queryparser
modules/spatial
modules/spellchecker

Shai

On Mon, May 16, 2011 at 7:07 AM, Mark Miller <[hidden email]> wrote:

On May 15, 2011, at 10:42 PM, Shai Erera wrote:

> I was aiming at avoiding that scenario. I think every issue should be assigned to a specific component, and if there isn't one available, we should create it.


Based on history and how these things normally go, unless you are planning on spending a *lot* of time curating JIRA for the forceable future, this is an unlikely outcome. Better categories will hopefully mean more compliance, but I'd bet the standard hodgepodge of JIRA submissions and curation is going to remain fairly similar to what we have seen. Version is a much more important field - and even it is not curated even close to this 'ideal' world level.

I think every issue should be fully filled out, correctly filled out, cross linked with all relevant issues, etc, etc.

But I don't plan on it being the normal scenario ;)

FWIW: I fill out component sometimes, and other times I'm just not worried about it. Someone can always come along after us types and random users and clean up after them, but I surmise that won't last long.

- Mark Miller
lucidimagination.com

Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]