Jira Convention: Resolved vs Closed

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

Jira Convention: Resolved vs Closed

Chris Hostetter-3

Is there a documented or unspoken policy about the "Resolved" vs "Closed"
bug statuses?

How/when should a resolved bug be closed?

(In my experience policy has tended towards the person fixing the bug to
"resolve" it, and the person who opened the bug to "close" once they're
verified the fix -- but that's not really possible with the way the Lucene
Jira project is setup, since anyone can open a bug, but only developers
can close them)

-Hoss


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

Reply | Threaded
Open this post in threaded view
|

Re: Jira Convention: Resolved vs Closed

Erik Hatcher
I've historically treated Closed and Resolved as the same thing and  
have closed resolved issues just to set them to that state.

        Erik

On May 15, 2006, at 9:24 PM, Chris Hostetter wrote:

>
> Is there a documented or unspoken policy about the "Resolved" vs  
> "Closed"
> bug statuses?
>
> How/when should a resolved bug be closed?
>
> (In my experience policy has tended towards the person fixing the  
> bug to
> "resolve" it, and the person who opened the bug to "close" once  
> they're
> verified the fix -- but that's not really possible with the way the  
> Lucene
> Jira project is setup, since anyone can open a bug, but only  
> developers
> can close them)
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


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

Reply | Threaded
Open this post in threaded view
|

Re: Jira Convention: Resolved vs Closed

Doug Cutting
In reply to this post by Chris Hostetter-3
Chris Hostetter wrote:
> How/when should a resolved bug be closed?

I close bugs after their "fix version" is released.

The distinction between "resolved" and "closed" is intended for projects
with a formal QA process.  An engineer fixes a bug and marks it
"resolved", and then a tester verifies the test and either closes it or
re-opens it if it has not been fixed.  In our case, we're all testers.

Released, closed issues should generally not be re-opened.  If there are
further problems related to an issue after a release is made and the
issue has been closed, then a new issue should be created.  Why?  If a
project has a Jira issues for every commit, and includes the issue name
in the commit message, then Jira's change log fully can fully document
the release, including links to subversion diffs, etc.  But re-opening a
closed bug messes this up.  It's better to add a new bug that links to
the old, closed bug.

We're trying to operate this way on Hadoop.  Issues are entered for most
planned changes and assigned a "fix release".  Then Jira's "road map"
feature can be used to see what features are planned for various
upcoming releases.  This isn't perfect, since issues dropped for one
release are pushed to the next, and the list of issues per release
becomes unrealistically large (at least for the monthly release schedule
we're on).  But on Hadoop we currently have dedicated resources who can
be assigned bugs and will work hard to fix them by a release date.  I'm
not sure whether this would work on Lucene, which currently lacks such
dedicated resources, but it might be interesting to try.

> (In my experience policy has tended towards the person fixing the bug to
> "resolve" it, and the person who opened the bug to "close" once they're
> verified the fix -- but that's not really possible with the way the Lucene
> Jira project is setup, since anyone can open a bug, but only developers
> can close them)

Note that I think it's okay to add folks the the "lucene-developers"
Jira group who are not Lucene committers.  Some folks are very involved
with Lucene, but don't submit so many patches that they need to be a
committer.  For such people it can make sense to have them able to help
manage Jira issues.

Doug

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

Reply | Threaded
Open this post in threaded view
|

Phrase IDF and collection frequency !

Samir Abdou
Hi,
 
Are there any ideas on how to compute the "document frequency" and "collection frequency" of phrases?
 
Document frequency is the number of documents containing the phrase.
 
Collection frequency is the frequency of the phrase in the whole collection.
 
 
Thanks in advance for any help
 
Samir
 
 

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

Reply | Threaded
Open this post in threaded view
|

Re: Phrase IDF and collection frequency !

Tatu Saloranta
--- ABDOU Samir <[hidden email]> wrote:

> Hi,
>  
> Are there any ideas on how to compute the "document
> frequency" and "collection frequency" of phrases?

Tokenize your input as phrases (instead of words), and
you'll get this the same way you normally get stats
for single-word tokens (Terms)? I did that for bigram
frequency analysis.

Of course, the problem is hardly getting these stats,
problem is finding what constitutes a phrase. ;-)

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

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