The JIRA default issue type, in my browser, actually appear to be the last one I selected (probably saved in a cookie). "Bug" might be the default if no previous issue type had been selected, though.
Personally, I'd prefer this field be blank, but required, for new issues, regardless of previous issue type selected. That way, the reporter is forced to consider which category it fits in. I'm not sure JIRA can be modified to enforce that, though. I don't have a strong opinion about the rest... but fixVersion is probably useful to leave on the creation screen, because we don't have a good triage system in place to effectively schedule fixes right away. Ideally, component leads would be in charge of scheduling fixes for their respective component, but I don't think we're mature enough for that yet (though, the project is becoming more modularized to enable that at some point in the future). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Apr 7, 2014 at 11:05 AM, Mike Drob <[email protected]> wrote: > I think a tangible improvement to come out of this would be to tweak our > "report an issue" page. > > Our current JIRA defaults are for each issue to be a "Major" priority > "Bug." This seems to cause a lot of noise for determining which issues are > actually bugs or improvements, and which issues are really major instead of > minor. > > I propose that we set the default to "Minor" and the issue type to > something else... "Wish" possibly? > > Also, I think we should remove the Due Date, Original Estimate, Epic Link, > and Sprint fields from the creation page. I do not care if they are still > present, just hoping to remove some clutter from the screen for first time > users. > > We might be able to get away with removing the Fix Version from the > creation screen too, but I don't have particularly strong opinions about > that. > > > On Mon, Apr 7, 2014 at 10:57 AM, Christopher <[email protected]> wrote: > >> In the >> '[DISCUSS] Bugs-only strictness for bugfix releases' thread, Mike Drob >> brought up the concern that the definitions of "bugs", "improvements" >> and "new features" may be ill-defined. >> >> I provided one explanation for how I was interpreting those in that >> thread, which I won't duplicate here, for brevity. >> >> JIRA has some views also, which I think are similar to what I've outlined: >> https://confluence.atlassian.com/display/DEV/JIRA+usage+guidelines >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >>
