For help getting started, or basic use of Deduced, refer to the documentation that can be found from the left navigation of this site.
If these documents, and the other questions in this FAQ don't help you with your problem, the Deduced User List is a good source for help. Lots of problems have already been discussed there, so please search the mailing list archive before posting a question or a new idea. Most of the Deduced developers are subscribed to the Deduced User List, so there is no need to post to the Deduced Developers list unless you want to discuss making a change to Deduced itself.
You should not mail developers directly for Deduced related issues, for 2 reasons. The most important is that the project operates in the public, so all discussions should be kept on the list (for the same reasons as given above). Secondly, they are busy and in various timezones, so mailing to the list ensures you get the most prompt response from someone available and able to commit their time at the moment. Direct questions to developers will rarely be answered.
| [top] |
First, we'd appreciate if you search the Mailing List Archives to see if anyone else has encountered it and found a resolution or a workaround.
If you are not using the current release of Deduced, it is also worth trying that, and specifically checking the release notes to see if that bug might have already been addressed.
If you are sure it is a bug, then it should go into the sourceforge bug tracking system for the deduced project. First, search the Deduced project to see if the bug has already been reported. If not, create a new issue. You must be registered and logged in to do so. This enables you to be contacted if the bug is fixed or more information is required.
The location of Deduced Framework issue tracker is listed on the Issue Tracking page.
Please be patient. While the issue will usually be reviewed immediately, bugs do not always get fixed as quickly. However, if you are able to submit your own fix, it will usually be applied for the next release. See Submitting Patches for more information.
| [top] |
Great! The process is very similar as for Filing a Bug Report.
Firstly - are you sure its a new idea? Try searching the Mailing List Archives for both the user and developer lists to see if a similar idea has already been discussed.
Likewise, you should also search the Deduced Framework issue tracker to see if someone has proposed it as a feature request already.
If not, there are two ways to proceed. If you have a rough idea but think it needs some discussion with the developers, try posting to the developers mailing list. So that they know initially that you have already thought this through, briefly detail what you did or didn't find when searching the mail archives.
Once you are confident that the idea is solid and fits the current direction of the project, submit it to Deduced Project as a feature request.
Please be patient. While the issue will usually be reviewed immediately, features are usually not implemented until the start of the next major development cycle. However, if you are able to submit your own implementation, it will usually be applied for the next release. See Submitting Patches for more information.
| [top] |
Bug fixes and features submitted by non-committers of the project take the form of a patch. Submitting your own patch will ensure that the bug or feature gets addressed sooner, and gives the submitter the warm fuzzy feeling from helping out!
Before working on a patch for a bug fix or new feature, it is essential that the steps above are followed to ensure that there isn't already a patch, or that a new feature has been previously decided against because it does not match the direction of the project. You don't want to waste time preparing a patch if it won't be used, so please take the time to consult the current developers list in advance.
When preparing the patch, make sure it is against the latest code in version control by doing a full update and testing it again.
If you are fixing a bug, make sure you submit a test case that fails without the patch, but succeeds with the patch applied, proving that it works.
If you are submitting a new feature, it is important that you include test cases to verify the feature works, and documentation for users on how it works.
It is important that you don't submit whole replacement files instead of differences or differences where unrelated code is changed - such as changing formatting or spacing. Patches that violate these rules will often not be applied.
Finally, adhere to the coding standards of the project, respecting the settings of the code surrounding that of the change. This includes whitespace, and ensuring that spaces are used instead of tab characters.
If these rules are followed, you will usually find that developers will joyfully and quickly apply the patch, and be appreciative of the efforts put in to help out.
| [top] |