Issue tracking

This page describes how to use issue tracking for reporting and working on bugs and features

Where to report issues

Report issues related to how VTechWorks functions or looks using the GitHub issue tracker for the VTechWorks project. You must have a GitHub account to open an issue, but anyone with a GitHub account may open one. Only members of the VTechWorks Team may assign or close issues.

Report security or sensitive issues in the GitLab issue tracker for the VTechWorks documentation project.

General guide to issues

• See https://guides.github.com/features/issues/ for how to use GitHub's issue tracker, including how to use useful features like mentions (using the @ symbol plus a GitHub username to get someone's attention) and references (using the # symbol plus an issue number to refer to another issue).
• Everyone on the team has the ability and the responsibility to open issues, to close issues, and to assign issues to another team member. Any resulting conflicts (as if!) will be resolved by the VTechWorks "product owner," i.e., the VTechWorks manager.
• Only the product owner will be responsible for assigning milestones to issues: more about milestones below.

Opening issues

• Be as specific as possible about the problem or feature: it's helpful to include links to examples and/or screenshots.
• Always assign a label to an issue when you create it. Only the "product owner," i.e., the VTechWorks manager, should use the green current sprint label, however. See the section on Labels below for more info.
• In general, it is best not to assign the issue to anyone when you create it, but if there is only one person who can logically address the issue, feel free to assign it to them. See the section on Assigning Issues below.

Labels

• bug - Use the "bug" label when a key functionality of VTechWorks is not working as it is supposed to. Bugs should be prioritized by developers, but even bugs can often wait until the next sprint to be fixed. If a bug is critical, meaning that it interferes with users' or administrators' ability to use the site in production, mention the VTechWorks manager in the issue and ask that the bug be assigned to the current sprint. This will only happen if the bug truly blocks crucial functions of the system.
• current sprint (green label) - Do not use the current sprint label unless you are the product owner (VTechWorks manager). The current sprint label identifies what we should be working on now. Current sprint tasks are determined and labeled in the sprint planning meeting, where the product owner prioritizes issues and developers decide which of the top priority issues they might reasonably be able to complete in the coming sprint.
• documentation - Use the "documentation" label when there are help pages for developers or system administrators that need to be written.
• dspacecore - Use the "dspacecore" label to identify fixed issues whose code should be contributed back to the core DSpace project.
• enhancement - Use the "enhancement" label to feature requests, interface requests, and requests for new modules or functions.
• question - Use the "question" label if you have a question. This can also be applied to issues that have generated long comment threads which need to be resolved.
• revisit later - Use the "revisit later" label for all issues that are not in the current sprint. Issues with this label will be evaluated at the next sprint planning meeting. Issues with this label are part of the product backlog.
• support - Use the "support" label for routine requests that are neither bug reports nor feature requests, such as changing the permissions for a particular account.
• wontfix - Use the "wontfix" label when you have determined that a bug is not really a bug (because, for instance, it results from user error) or when the product owner in consultation with the team and with users has decided that a requested feature is not desirable.

Assigning issues

• Anyone on the team may assign an issue to another team member. Any team member may also unassign themselves from a particular issue.

Closing issues

• Issues are closed (by any member of the team) when they are considered "fixed." "Fixed" in this case means that a commit has been submitted to GitHub that resolves the issue on the developer's local development environment or that can reasonably be expected to fix the issue when the code is deployed to the development server. If, during testing, the issue turns out not to be fixed after all by the commit, the issue should be reopened.
• Issues should be referenced in and closed by commits whenever possible -- see again https://guides.github.com/features/issues/