First!

Read the FAQ and Sigil's User Guide

Really, check the FAQ first. See if your bug or feature request is mentioned - it may already be considered or rejected.

Check your Sigil version is official and current

If you are using an older version of Sigil, upgrade to the latest version and confirm your issue still exists before submitting a report.

If you are using a version of Sigil not downloaded from this site, or you are running from Source, you should not submit a bug report. If you can demonstrate the issue on an official version of Sigil or are certain that you know exactly what the issue and fix is, then feel free to submit the report.

Check if your EPUB file is valid

Sigil cannot open a corrupted or invalid EPUB file.

Check your EPUB using the online epubcheck at The IDPF EPUB Validator or downloading and running epubcheck directly.

Check for an open issue

But are you sure this bug/feature request hasn’t already been reported? If it has, reporting it again does no good. You are better off starring the original report.

To check whether an issue for your problem has been created, go to the issue tracker.

Read through the list of open issues. See anything that could be related? If you do, click on the issue report and examine its details. If this looks like your problem, please star it. “Starring” means clicking on the star icon with the blue outline until you see it filled in with yellow. Issues with more stars are more visible and that may help them get addressed sooner.

Check for a closed issue

If you can’t find anything related in the open issues, then change “Search: Open Issues” to “Search: All Issues” and now type in a few keywords that could locate the issue. It could already be closed with a fix awaiting release or with a comment saying it won't or can't be fixed.

Nothing found? Well then you need to make a new issue.

Submit a Bug Report

Include your OS Name and Version

Always include your OS Name version. (MAC 10.6, Windows Vista 64bit, Ubuntu 11.10, etc.)

Include your Sigil Version

And definitely include your Sigil version, and preferably your Qt version. Use Help->About to confirm the version of Sigil using, and also the version of Qt that is being used.

Include a step-by-step description

You need to write a step-by-step procedure that can repeatedly replicate the problem. “Replicates” means that a developer can read your issue, perform the steps you listed and see the bug immediately. “Repeatedly” means that the developer can perform this sequence as many times as necessary and the bug will always show up.

Generic descriptions like “I was doing X and then Sigil crashed” are of no use. The developer needs to be able to see and experience the problem first-hand. There is no such thing as an issue report that is too detailed. The more information you provide, the better your issue report will be.

Attach example files

If the developer would need access to the file you were editing when the problem occurred to fully understand what happened (this is practically always), then attach that file to the issue. Try to make the file as small as possible. Usually the bug is triggered by just a section of your file, so try to remove everything except that section. Then try to replicate the problem with just this smaller file. If it still shows up, then try to make it even smaller until you are unable to replicate it. Then attach the smallest possible file that still replicates the problem.

If your file is under copyright (say, an e-book novel), use the "Private Issue" template on the "New Issue" form. This will mark the issue as Private and only you and the Sigil developers will be able to see it. Other people (and search engines) will not be. Let me say that again: the only people that will be able to see the issue (and thus access the attached file) are the Sigil developers and you. It will not be publicly accessible in any way, shape or form.

After you have written your step-by-step procedure and attached the file (if any), don’t submit the issue yet. Read the description and procedure one more time. Pretend you don’t know anything about the problem you are reporting and try to replicate it using the procedure and file you are about to post. If you can’t, then you need to change something.

Submit the report

Submit Your Sigil Bug Report Here.

Here are a few examples of good issue reports: example 1, example 2, example 3, example 4.

Wait

After you submit the issue, it will be either “Accepted” or rejected. If it’s accepted, a fix for it may eventually be developed. This may take anywhere from a few days to months.

When your issue is marked as “Fixed”, please understand that the problem will be fixed in the next version of Sigil. You cannot just download the current version right after the issue is marked as “Fixed” and expect that the problem will now be gone. The next version of Sigil will have this fix, and the amount of time from the moment a fix is created to the moment a new version is released may be considerable! Have patience.

Submit a Feature Request

First of all, switch the issue template to “Enhancement report from user”.

Now ask yourself, would this feature be helpful to others? Not just a few people, but a lot of Sigil’s users? See, good features are useful to many. If your feature is only useful to you and maybe a couple of others, then that’s not a good feature. There is such a thing as “feature overload”. When software accumulates so many features of which most are only useful to a handful, then that software has become “bloated”. We don’t want that.

Requests for features that are obscure or are helpful to but a few, or not part of Sigil's vision will be rejected. Yes, even if you provide a patch that completely implements it.

Please include details on exactly what you would like to see, and why. Sometimes what you want can be done in a different way if the reason for the change is known.

Submit Your Sigil Feature Request Here

Posting Comments/Questions

Please use the Sigil Forum at MobileRead for all questions/comments. Comments on this wiki will be removed.