Docs: refresh the issue/features page guidelines

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
+You should include the following information:
-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
+* A sequence of configuration commands or a complete configuration file
-reproduce the issue is beneficial to everyone. Be sure to include information
+  required to recreate a setup where the bug occurs.
-about the hardware you are using, commands that you were running, any other
+  Please avoid partial configs: a sequence of commands is easy to paste into the console,
-activities that you may have been doing at the time. This additional
+  a complete config is easy to load in a VM, but a partial config is neither!
-information can be very useful.
+  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.
 
-* What were you attempting to achieve?
+If you aren't certain what the correct behavior is and if what you see is really a bug,
-* What was the configuration prior to the change?
+or if you don't have a reproducing procedure that reliably triggers it,
-* What commands did you use? Use e.g. ``run show configuration commands``
+please create a post on the forum or ask in the chat first —
-
+or, if you have a subscription, create a support ticket.
-Include output
+Our team and community members can help you identify the bug and work around it,
---------------
+then create an actionable and testable bug report.
-
-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.
 
 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