Skip to end of metadata
Go to start of metadata

Every project has one or more administrators, and while a Jira project doesn't usually need to be actively administered, there are a few things that it may help for an Project Administrator to understand and set up for their project. These can all be gotten at via the Administration tab that you should see as a Project Administrator:

  • Membership management - Here a Project Administrator can set who is in a project. By default, everyone in UW-IT can view a project, but only Project Developers can work on issues. See the description of Project Roles for further information. For ease of management, we recommend using UW Groups where possible. Jira will sync a user's groups when they log in to Jira. You can grant access to non-UW federated members (eg. ProtectNetwork) by adding them to any of your UW groups
  • Project Roles - Our implementation currently supports the three default Project Roles. Administrators can change settings on a project, Developers can work on issues, and users can view issues and add comments. It should be enough to add someone as a Developer without the need to also add them as a User. Project Administrators should not be confused with Jira Administrators, which we try to refer to as Jira System Administrators.
  • Project Information - Edit Project for your project, this enables you to set things like project name, description, avatar and project lead
  • Project Versions - Versions are a good way to group issues, and is usually the first step to making your project viewable from the Agile tab. They are generally tied to a release date. While the obvious way to version is by product version, there really is no limit to what you want to call a version
  • Project Components - Like versions, breaking a project into components is another way to group issues. Unlike versions, components are not tied to a release date.

When to contact help@washington.edu - Here are a few things that can be set up for a project but unfortunately require intervention by a Jira system administrator to change:

  • Creating a new project Use the project creation form or let us know of a project whose settings you would like to be copied for your own new project
  • Changing project permissions - Jira has a whole host of permission settings, but usually the default set is enough for basic usage, and most issues that arise from lack of adequate permission are a result of not being in the correct Project Role (see above)
  • Changing project notification settings - Common problems encountered with Jira's notification scheme are that it is too chatty and an administrator would like to turn off notifications, or there is a separate mailing list they would like notifications to go to.
  • Adding custom fields - It is possible to configure a project or multiple projects to have any number of custom fields
  • Changing the project workflow - For most the default workflow should be enough, but it is possible to use custom workflows
  • Pulling information from subversion - A project can connect to a subversion repository to look up revisions and match them to Jira issues if those issues are referenced in the svn comments.
  • No labels