• Bug tracking
• Feature Requests
or even to collect user input.
In fact the ticket app can be configured to use different fields and a different workflow. So you can configure it for many kinds of use cases where you want to have a structured interface between people.
To give you an example:
Let's imagine your project has a built-in directory of supported web pages. You may create a ticket tracker, with much less fields as usual, where users might post URLs of new sites or report problems with existing ones.
Anyway we will focus on the main use case here. And this is, that you have a ticket system, which tracks bugs and improvements in your software.
Bug Tracking / Feature Request
This kind of tickets always expects a change on the product. So they are always assigned to a milestone, which is usually one if the next releases. Most Open Source projects don't have the luxury of fix development ressources. So nobody can define a fix release schedule. But at least you can work with lists of tickets, which are planed to be implemented or fixed for the next release.
The milestones are defined by the project mainainers. The tickets can usually be edited by everyone.
The commits for the tickets should always contain the Ticket number in the commit message. This makes it easier for others to review your changes and potentially merge them.
In the chapter about Source Code management we recommended to use tickets ahead of "Merge Requests" in Git. The reason is, that:
you can manage a ticket, which issues changes in more than one repository.
it is possible to work on a branch in one repository and do a small direct change on trunk in another.
The idea is to create a ticket and commit your stuff, referencing the ticket. To reference a ticket, just add the ticket number in brackets to your commit messages.
Depending on the rights in the project, either the maintainer of the project or the developer who did the change can later on merge the changes back to "trunk" or "Master". This is usually done when a ticket is closed.