Guide: Issues

Issues is what you may know from other services as tickets. Basically, you can write anything in an issue: bug reports, enhancement requests, or technical questions. Issues help the project maintainers to have an overview of open tasks. Often, the maintainers open issues themselves as a reminder.

In Gitea, issues happen completely in the web interface, so there's no interaction with your command line terminal required. So make sure to be logged in to git.fsfe.org.

Open your first issue

First of all, let's create a new issue in a test repository, ideally the one you created in an earlier guide. So, go to git.fsfe.org/username/test, and click on Issues in the repository navigation bar (beneath Code and Wiki). Note, that the Issues button in the very top navigation panel only shows you issues you're involved with.

In the following screen, you can find all open issues of the repository. To see closed issues, you can find a button to switch the view. Click on a green button named New Issue to proceed.

Now, you can give the new issue a short and useful title, and a longer description where you explain your problem or request. You can format your text with the Markdown format, and preview the text before sending it. You can also add attachments, e.g. screenshots or log files. By pressing Create Issue, the issue will be saved and visible to other people.

Notifications

From now on, you'll automatically receive email notifications when people reply to your issue. These notification will also be visible in your inbox in the web interface. You can find the inbox in the top right corner, left to the +-icon.

To receive emails and notifications for each issue created, even if it's not your's, you can watch a repository. You're automatically watching a repository if you created it yourself.

Advanced issue settings

In order to categorize issues, you can label them. These are like tags, and you can freely define them. For example, an enhancement label could mark an issue as feature request, while bug states that this is a technical error which needs to be fixed. Labels grant overview to you and other people.

For larger projects which are in heavy development, you can set milestones. For example, the release milestone can contain all issues that are necessary to be solved/closed in order to make the project ready for public release. This way, you can separate urgent issues from more long-term issues.