Agreed. Improvement is definitely adding something new, refactoring, etc for existing features. It seems the most important distinction is between BUG and others - from Rick's description.
On Fri, Dec 22, 2017 at 12:18 PM, Philip Zampino <pzamp...@gmail.com> wrote: > Since there is a New Feature type, would Improvement be a change to > something that exists, which is not broken, but could be done differently? > > I think the splitting of hairs is the reason for most people just using > "Bug" ;-) > > That being said, I think it would be helpful for us to reserve the Bug type > for existing functionality that is defective; this would at least help with > Rick's use case. > > We can discuss the need to distinguish between New Feature and Improvement > when the difference becomes a problem. > > - Phil > > > On Fri, Dec 22, 2017 at 11:59 AM, larry mccay <lmc...@apache.org> wrote: > > > Well, there are a handful of types. > > * Bug > > * New Feature > > * Improvement > > * Test > > * Wish > > * Task > > > > I think we should take some care to set it appropriately for JIRAs we > file > > ourselves and to set it when they come in from the community at large. > > I often set the Fix Version when they come in from others, so I will try > > and assess the type as well. > > > > Thanks for the explanation, Rick! > > > > > > On Fri, Dec 22, 2017 at 11:19 AM, Philip Zampino <pzamp...@gmail.com> > > wrote: > > > > > If this distinction is valuable (which sounds to be the case based on > > > Rick's explanation), then I agree with Larry's suggestion to avoid > having > > > someone spend a lot of time re-categorizing issues in bulk. > > > > > > So, defects are of type Bug, and new features are Improvement type > > issues? > > > > > > > > > > > > On Fri, Dec 22, 2017 at 9:01 AM, Rick Kellogg <rmkell...@comcast.net> > > > wrote: > > > > > > > Greetings, > > > > > > > > The primary reason I spent some time updating this field was to allow > > > > searching for bugs. When I use an open source project and something > > does > > > > not work, I generally take a look at the outstanding bugs in a > project. > > > If > > > > this is not set it can take an inordinate amount of time to wade > > through > > > > all the issues. > > > > > > > > A suggestion might be to leave the field blank and make it required > in > > > the > > > > JIRA setup. This would force people to pick an suitable value. > Just a > > > > suggestion though. > > > > > > > > Happy holidays to everyone. > > > > Rick > > > > > > > > -----Original Message----- > > > > From: larry mccay [mailto:lmc...@apache.org] > > > > Sent: Friday, December 22, 2017 7:27 AM > > > > To: dev@knox.apache.org; Kellogg, Richard M. (CIV) < > > > > richard.m.kell...@usdoj.gov> > > > > Subject: [DISCUSS] Proper Use of JIRA Type Field > > > > > > > > All - > > > > > > > > As you may have seen, Rick Kellogg spent what seems like a good > amount > > of > > > > time yesterday cleaning up and setting the Type field in the JIRAs to > > > > appropriate values. > > > > > > > > If we feel that this is a worthwhile task then we should probably try > > and > > > > set it to a meaningful value as they come in - as to not allow that > to > > > get > > > > out of control again. > > > > > > > > I have certainly been neglectful of this field and only pay attention > > to > > > > the type of a patch when it comes to updating the CHANGES file for a > > > > release. > > > > > > > > @Rick - would you like to describe your motivation for doing all that > > > > cleanup (which was much appreciated, btwenera)? > > > > > > > > thanks, > > > > > > > > --larry > > > > > > > > > > > > > >
