Reorganizing JIRA components

[Shai Erera <se...@gmail.com>]

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

Re: Reorganizing JIRA components

[Shai Erera <se...@gmail.com>]

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 <ma...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Reorganizing JIRA components

[Mark Miller <ma...@gmail.com>]

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Reorganizing JIRA components

[Shai Erera <se...@gmail.com>]

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 <ma...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Reorganizing JIRA components

[Mark Miller <ma...@gmail.com>]

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org