Change Details

It's important to keep task tracker entries actionable. There are two main ways people use the task tracker. For the maintainer team and community contributors, the main question is "what can I work on now?". For end users, it's usually either "does anyone have the same problem?" or "does anyone also want the feature I want?". **Feature request guidelines** 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 supposed 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. **Bug report guidelines** When you create a bug the most important thing is that it should be possible to tell for sure if it's fixed. 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, 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. **Task auto-closing** Recently we've added a new task status: "Needs reporter action". We will 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! **Conclusion** We hope that these guidelines help us all keep the task tracker clean and actionable. If you have any ideas how to improve them, tell us!

It's important to keep task tracker entries actionable. There are two main ways people use the task tracker. For the maintainer team and community contributors, the main question is "what can I work on now?". For end users, it's usually either "does anyone have the same problem?" or "does anyone also want the feature I want?". **Feature request guidelines** 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. **Bug report guidelines** When you create a bug the most important thing is that it should be possible to tell for sure if it's fixed. 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, 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. **Task auto-closing** Recently we've added a new task status: "Needs reporter action". We will 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! **Conclusion** We hope that these guidelines help us all keep the task tracker clean and actionable. If you have any ideas how to improve them, tell us!

It's important to keep task tracker entries actionable. There are two main ways people use the task tracker. For the maintainer team and community contributors, the main question is "what can I work on now?". For end users, it's usually either "does anyone have the same problem?" or "does anyone also want the feature I want?". **Feature request guidelines** 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 supposedrted 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. **Bug report guidelines** When you create a bug the most important thing is that it should be possible to tell for sure if it's fixed. 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, 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. **Task auto-closing** Recently we've added a new task status: "Needs reporter action". We will 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! **Conclusion** We hope that these guidelines help us all keep the task tracker clean and actionable. If you have any ideas how to improve them, tell us!