| Version 18 (modified by guinness, 9 years ago) (diff) |
|---|
Welcome to the AutoIt issue tracker
The AutoIt issue tracker is the new system for placing bug reports and feature requests for AutoIt. Please take a few moment to read over this page to get an understanding of what you need to do in order to help the developers improve the AutoIt language. Below are guidelines, tips and expectations for using this service.
General Guidelines
These guidelines should be taken into consideration when posting to the issue tracker.
- Search the issue tracker to see if the ticket has already been discussed.
- Search the forum to see if the issue has been discussed there.
- Do not create a new ticket because an old ticket was closed. Reply to the old ticket if you have additional information and the developers will make the determination if the ticket should be re-opened.
- Please use the following syntax when inserting code. It helps the code stand out making it easier to read.
{{{ MsgBox(4096, "", "This is source code") }}} - If you must post a large piece of code then please attach the file instead of posting it in-line.
- Do not demand priority for your issue. People always suggest their issue should receive priority because it's important to them. It's a waste of time to suggest priority and will just lead to your ticket being ignored for longer than it would have otherwise been. It is up to the developers to choose what they want to work on and when it gets worked on.
- Do not argue about the resolution a ticket is given unless you can prove that closing the ticket was a mistake.
- Do not ask for support. This is for bug reports and feature requests only. See the AutoIt forum to ask for support.
- Tickets should be stand-alone. They should contain all the information necessary to reproduce the issue without the need for links to the forum. It is acceptable to link to the forum so the developers may see the discussion that lead to the discovery of the bug. However, linking to the forum without extricating the pertinent information and using that to create the ticket will result in the ticket being ignored and closed.
- Each ticket should cover one issue. Tickets that cover multiple issues are confusing and hard to resolve since some parts may not be completed in a way that matches the ticket's resolution. If you think you've found multiple related issues, post on the forum first. Chances are, fixing one issue will resolve the related issues, otherwise they should be separate tickets anyway.
- Avoid using includes in reproducers scripts, if the issue is not UDF related, but AutoIt only.
Bug Report Guidelines
These guidelines should be taken into consideration when creating a bug report.
- If you are asking a question you do not have a bug to report, use the forum to ask questions.
- You must provide a short test script that reproduces the problem. The script should be no more than the bare minimum code necessary to reproduce the problem.
- Test the reproduction script with both the latest stable and latest beta versions of AutoIt. Check the links to ensure you have the latest versions, AutoIt is updated frequently.
- Please choose the correct version and component for the ticket.
Feature Request Guidelines
These guidelines should be taken into consideration when creating a feature request.
- Ensure the idea isn't on the list of things we won't do.
- Seriously, go and read this page again. Do not ask for these things.
- When creating a feature request, please unset the version field. The version field is not used with feature requests. In addition the blocking and milestone fields should be left empty as well.
- Think about your feature request. If you can do it via UDFs, then don't ask for it to be built in. There's a reason you can create your own functions.
- Don't ask the developers to write UDFs. If you want to see UDFs added then you'll need to write it or get someone else to write it and submit it with the proper documentation.
- Don't assume that just because you need a feature that the majority of people will use the feature. In other words don't ask for very niche things. This is doubly true if you can do what you need via a UDF. Things added to the language are intentionally very broad to reduce bloat.
Commenting Guidelines
These guidelines should be taken into consideration when replying to a ticket.
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
Description of Ticket Fields
- Type - The type of ticket, either a bug report or a feature request.
- Component - The tool that the problem or request affects. For example, if you have a problem with one of the UDF's then set the component to "Standard UDFs" instead of leaving it set to AutoIt.
- Severity - The developers use this field to highlight tickets that are important and need fixed before a specific release. Only developers may set this field.
- Cc - Specify an email address here to receive an email notification when the ticket is modified.
- Milestone - This field is set to the version of AutoIt a change appears in. For example, if the milestone is set to 3.3.9.0 for a bug report then that bug will be fixed in AutoIt 3.3.9.0. A bug may be fixed in a version of AutoIt that has not come out yet. Only developers may set this field.
- Version - When creating a bug report, specify the version the bug appears. When creating a feature request please unset this field, it is not used.
- Keywords - Keywords can be specified here that will help in searching for the ticket. This field is seldom used.
Useful Reports
Here are some useful reports to take you to various types of tickets. Unless otherwise specified these reports are sorted by the last modification date.
