summaryrefslogtreecommitdiff
path: root/docs/contributing/issues-features.rst
diff options
context:
space:
mode:
authorDaniil Baturin <daniil@baturin.org>2024-04-16 19:15:42 +0100
committerDaniil Baturin <daniil@baturin.org>2024-04-16 19:19:27 +0100
commit838c852ec3d83bca184d2102b5c9c38d4947fe6e (patch)
treeaa1718d477d77413572cd208083a63bf7109f8be /docs/contributing/issues-features.rst
parent32cdf6cdb24a28b41d23e67ba265d14d96cf2db6 (diff)
downloadvyos-documentation-838c852ec3d83bca184d2102b5c9c38d4947fe6e.tar.gz
vyos-documentation-838c852ec3d83bca184d2102b5c9c38d4947fe6e.zip
Docs: refresh the issue/features page guidelines
Diffstat (limited to 'docs/contributing/issues-features.rst')
-rw-r--r--docs/contributing/issues-features.rst103
1 files changed, 79 insertions, 24 deletions
diff --git a/docs/contributing/issues-features.rst b/docs/contributing/issues-features.rst
index 9b6602f9..e57766fc 100644
--- a/docs/contributing/issues-features.rst
+++ b/docs/contributing/issues-features.rst
@@ -28,27 +28,31 @@ issue prior to opening a bug request.
Ensure the problem is reproducible
----------------------------------
-When you are able to verify that it is actually a bug, spend some time to
-document how to reproduce the issue. This documentation can be invaluable.
-
-When you wish to have a developer fix a bug that you found, helping them
-reproduce the issue is beneficial to everyone. Be sure to include information
-about the hardware you are using, commands that you were running, any other
-activities that you may have been doing at the time. This additional
-information can be very useful.
-
-* What were you attempting to achieve?
-* What was the configuration prior to the change?
-* What commands did you use? Use e.g. ``run show configuration commands``
-
-Include output
---------------
-
-The output you get when you find a bug can provide lots of information. If you
-get an error message on the screen, copy it exactly. Having the exact message
-can provide detail that the developers can use. Like wise if you have any log
-messages that also are from the time of the issue, include those. They may
-also contain information that is helpful for the development team.
+You should include the following information:
+
+* A sequence of configuration commands or a complete configuration file
+ required to recreate a setup where the bug occurs.
+ Please avoid partial configs: a sequence of commands is easy to paste into the console,
+ a complete config is easy to load in a VM, but a partial config is neither!
+ At least not until we implement a "merge from the CLI"
+ feature that allows pasting config file chunks into a session.
+* The behavior you expect and how it's different from the behavior you observe.
+ Don't just include command outputs or traffic dumps —
+ try to explain at least briefly why they are wrong and what they should be.
+* A sequence of actions that triggers the bug.
+ We understand that it's not always possible, but it makes developer's job a lot easier
+ and also allows any community member to independently confirm
+ that the bug still exists or if it's already fixed.
+* If it's a regression, tell us a VyOS version where the feature still worked correctly.
+ It's perfect if you can tell exactly which version broke it,
+ but we understand that it's not always easy or feasible — any working version is acceptable.
+
+If you aren't certain what the correct behavior is and if what you see is really a bug,
+or if you don't have a reproducing procedure that reliably triggers it,
+please create a post on the forum or ask in the chat first —
+or, if you have a subscription, create a support ticket.
+Our team and community members can help you identify the bug and work around it,
+then create an actionable and testable bug report.
Report a Bug
------------
@@ -64,15 +68,66 @@ request.
.. _feature_request:
-Feature Request
-===============
+Feature Requests
+================
You have an idea of how to make VyOS better or you are in need of a specific
feature which all users of VyOS would benefit from? To send a feature request
-please search Phabricator_ if there is already a request pending. You can
+please search Phabricator_ to check if there is already a request pending. You can
enhance it or if you don't find one, create a new one by use the quick link in
the left side under the specific project.
+You must create a task before you start working on a feature.
+Yes, even if it's a tiny feature — we use the task tracker to generate release notes,
+so it's essential that everything is reflected there.
+
+You must include at least the following:
+
+* A reasonably detailed description of the feature: what it is, how it's supposed to work,
+ and how you'd use it.
+ The maintainers aren't familiar with every feature of every protocol and tool,
+ and community contributors who are looking for tasks to work on will also
+ appreciate more information that helps them implement and test a feature.
+* Proposed CLI syntax, if the feature requires new commands.
+ Please include both configuration and operational mode commands, if both are required.
+
+You should include the following information:
+
+* Is the feature supported by the underlying component
+ (FreeRangeRouting, nftables, Kea...) already?
+* How you'd configure it by hand there?
+* Are there any limitations (hardware support, resource usage)?
+* Are there any adverse or non-obvious interactions with other features?
+ Should it be mutually exclusive with anything?
+
+It's fine if you cannot provide some of that information, but if you can,
+it makes the work of developers considerably simpler,
+so try to do the research to answer those questions.
+
+Task auto-closing
+=================
+
+There is a special status for tasks
+where all work on the side of maintainers and contributors is complete:
+"Needs reporter action".
+
+We assign that status to:
+
+* Feature requests that do not include required information and need clarification.
+* Bug reports that lack reproducing procedures.
+* Tasks that are implemented and tested by the implementation author,
+ but require testing in the real-world environment that only the reporter can replicate
+ (e.g., hardware we do not have, specific network conditions...).
+
+This is what will happen when a task is set to "Needs reporter action":
+
+* If there is no response from the reporter within two weeks,
+ the task bot will add a comment ("Any news?") to remind the reporter to reply.
+* If there is no response after further two weeks, the task will be automatically closed.
+
+We will not auto-close tasks with any other status
+and will not close tasks for the lack of maintainer activity!
+
.. _documentation: https://docs.vyos.io
.. _Slack: https://slack.vyos.io
.. _Forum: https://forum.vyos.io