nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practice for bug & feature creation by non dev users

Mike Applegate

I am looking for some tips or best practices on better ways to use Jira in our organization. Currently only our development and support teams have access to Jira but I want to open it up to more users within our organization. We have projects for our different products and then a separate project to track bugs and feature requests coming from support or non-development members. However, when something is considered a bug or valued feature, we move the item to our development projects.

I feel that this is not the best approach because we have this stranded project that is separate from the bugs and feature requests entered by members of the development teams. I was thinking one possible idea is to force all new bugs/features from non-dev users to go to a Backlog or other version but I am not sure it is possible to limit a version for specific users. Any ideas or tips on how you handle a similar scenario is greatly appreciated.

Regards,

Mike

Accepted answers

SimonS

Hey Mike!

We do this at Atlassian too - anyone can file a feature request or bug.

We let them do it in the same projects that developers use. When an issue is created, it automatically gets assigned to a team lead who can triage it. This way, the reporter gets immediate feedback - "yes this is a valid bug and we'll include it in X release" or "no, this is actually not a bug so we're closing this as a non-issue." etc.

Docs for auto assigning new issues:

http://confluence.atlassian.com/display/JIRA/Defining+a+Component#DefiningaComponent-defaultassignee

-Simon

All comments

SimonS

Hey Mike!

We do this at Atlassian too - anyone can file a feature request or bug.

Docs for auto assigning new issues:

http://confluence.atlassian.com/display/JIRA/Defining+a+Component#DefiningaComponent-defaultassignee

-Simon

Mike Applegate

Ok great. Are there any other flags you use to distinguish those items from others or it is just based on the assignee? So in other words, the dev team knows not to touch it if it has been assigned to the team lead. Further, if you want to filter issues not yet 'approved' for development, you simply filter on the team lead(s)?

SimonS

Someitmes people use a custom field that says something like "locked for editing" or something. You could do something similar for "not yet approved" and filter on that field, or filtering by the assignee would work too.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

best-practice