mirror of
https://github.com/syncthing/syncthing.git
synced 2026-04-08 08:27:56 -04:00
88 lines
3.3 KiB
ReStructuredText
88 lines
3.3 KiB
ReStructuredText
Issue Management
|
|
================
|
|
|
|
Bugs, feature requests and other things we need to do are tracked as
|
|
Github issues. Issues can be of various types and in various states, and
|
|
also belong to milestones or not. This page is an attempt to document
|
|
the current practice.
|
|
|
|
Labels
|
|
------
|
|
|
|
Issues without labels are undecided - that is, we don't yet know if it's
|
|
a bug, a configuration issue, a feature request or what. Issues that are
|
|
invalid for whatever reason are closed with a short explanation of why.
|
|
Examples include "Duplicate of #123", "Discovered to be configuration
|
|
error", "Rendered moot by #123" and so on. We don't use the "invalid" or
|
|
"wontfix" labels.
|
|
|
|
- **android** - Marks an issue as occurring on the Android platform
|
|
only.
|
|
|
|
- **bug** - The issue is a verified bug.
|
|
|
|
- **build** - The issue is caused by or requires changes to the build
|
|
system (scripts or Docker image).
|
|
|
|
- **docs** - Something requires documenting.
|
|
|
|
- **easy** - This could be easily fixed, probably an hour's work or
|
|
less. These issues are good starting points for new contributors.
|
|
|
|
- **enhancement** - This is a new feature or an improvement of some
|
|
kind, as opposed to a problem (bug).
|
|
|
|
- **help-wanted** - The core team can't or won't do this, but someone
|
|
else is welcome to. This does not mean that help is not wanted on the
|
|
*other* issues. You can see this as a soft ``wontfix``. (A hard
|
|
``wontfix`` is simply a close with a short explanation why.)
|
|
|
|
- **pr-bugfix** - This pull request *fixes* a bug. This is different
|
|
from the ``bug`` label, as there may also be pull requests with for
|
|
example tests that *prove* a bug which would then be labeled ``bug``.
|
|
|
|
- **pr-refactor** - This pull request is a refactoring, i.e. not
|
|
supposed to change behavior.
|
|
|
|
- **pr-wait-or-pending** - This pull request is not ready for merging,
|
|
even if the tests pass and it looks good. It is incomplete or
|
|
requires more discussion.
|
|
|
|
- **protocol** - This requires a change to the protocol.
|
|
|
|
Milestone
|
|
---------
|
|
|
|
There are milestones for major and sometimes minor versions. An issues
|
|
being assigned to a milestone means it is a blocker - the release can't
|
|
be made without the issue being closed. Issues not assigned to a
|
|
milestone can be handled whenever.
|
|
|
|
Assignee
|
|
--------
|
|
|
|
Users can be assigned to issues. We don't usually do so. Sometimes
|
|
someone assigns themself to an issue to indicate "I'm working on this"
|
|
to avoid others doing so too. It's not mandatory.
|
|
|
|
Locking
|
|
-------
|
|
|
|
We don't normally lock issues (prevent further discussion on them).
|
|
There are some exceptions though;
|
|
|
|
- "Popular" issues that attract lots of "me too" and "+1" comments.
|
|
These are noise and annoy people with useless notifications via mail
|
|
and in the Github interface. Once the issue is clear and it suffers
|
|
from this symptom I may lock it.
|
|
|
|
- Contentious bikeshedding discussions. After two sides in a discussion
|
|
have clarified their points, there is no point arguing endlessly
|
|
about it. As above, this may get closed.
|
|
|
|
- Duplicates. Once an issue has been identified as a duplicate of
|
|
another issue, it may be locked to prevent further discussion there.
|
|
The intention is to move the discussion to the other (referenced)
|
|
issue, while someone just doing a search and jumping on the first
|
|
match might otherwise resurrect discussion in the duplicate.
|