Submitting Issues

Submitting Issues

Please do not use the [Qucs issue tracker] (https://github.com/Qucs/qucs/issues) for personal support requests. The [qucs-help mailing list] (https://sourceforge.net/p/qucs/mailman/qucs-help/) and the #qucs IRC channel on chat.freenode.net are better places to get help.

Issues should be used mainly for reporting bugs, namely (reproducible) problems caused by the code in the repository.
If you would like to submit a Feature Request please [see below] (#feature-requests).
If you would like just to change the code formatting or the Qucs GUI appearance please [see below] (#cosmetic-changes).

A bug report should be clear, concise and reproducible:

• check if the issue or a related one is already reported in the [Qucs GitHub issue tracker] (https://github.com/Qucs/qucs/issues). In this case please comment on the relevant, already-open, issue.
• issues should preferably refer to code in the current master branch. If for some reason you are not able to use the current code, please state which version of Qucs you are using.
• an issue report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report:
  • What is your environment (Operating System, OS version, Linux distribution, Window Manager version, etc.)?
  • How can the issue be reproduced? Try to create a test case (schematic, sequence of actions in the GUI, etc.) to demonstrate your issue. You can provide a test schematic as a [Gist] (https://gist.github.com/) or you can directly paste the schematic file text in the issue, if short.
  • What would you expect to be the outcome and what did you get instead?
  • Any other information you want to share that is relevant to the issue being reported. This might include lines of code that you have already identified as causing the bug, and potential solutions (and your opinions on their merits). All these details will help people to fix any potential bugs.

Feature Requests

If you are considering submitting a new feature to Qucs, first take a moment to find out whether your idea fits with the scope and aims of the project. Then send a message to [qucs-devel mailing list] (https://sourceforge.net/p/qucs/mailman/qucs-devel/) and explain the feature you'd like to submit and why you think it would be useful. Please provide as much detail and context as possible.

Please do not use GitHub Issues for Feature Requests. If there's a new feature that you want to see added to Qucs, most likely you'll need to write the code yourself - or convince someone else to help you writing the code. If you enter a wish list item in the GitHub issues with no code, you can expect it to be closed without further actions.

Sometimes, the line between 'bug' and 'feature' is a hard one to draw. Generally, a feature is anything that adds new behavior, while a bug is anything that fixes already existing behavior that is misbehaving. Sometimes, the core team will have to make a judgement call.

Cosmetic changes

We would like to be straight about this: in general stand-alone cosmetic changes to the code are not accepted. Please check [here] (https://github.com/rails/rails/pull/13771#issuecomment-32746700) for some explanations about why these changes are usually not a good idea. Until we do not have fixed Coding Guidelines, it is ok to change the code formatting around changes related to a particular pull request.

Changes to the Qucs GUI which are not dictated by a functionality enhancement are usually not accepted. Qucs has been around for more than 10 years and its many users are accustomed to its typical GUI appearance, which has not drastically changed over the years. Changing colors around, shuffling menu items, resizing dialogs, etc., just because you like them differently is generally a bad idea. If you really think something need to be changed to improve the GUI usability, discuss it first on the [qucs-devel mailing list] (https://sourceforge.net/p/qucs/mailman/qucs-devel/).