Sunday, October 27, 2013

Sigil Issue Tracking Disabled Completely

I've disabled the issue tracker on both Google Code and GitHub. The issue tracker has become people posting the same few items which are not issues over and over again. I spend more time closing invalid issues than doing anything else with Sigil. If you're having a problem with Sigil of some sort try searching Google. FYI, if you're using OS X chances are either the version you're using isn't supported or isn't supported at this time due to components Sigil depends on being broken on that version.

6 comments:

  1. Not cool. Better approach would be to link to an FAQ with frequent errors from a highly visible place. You could use the github Wiki for hosting the FAQ.

    See this link to find out how to add a contribution guideline link for issues on github: https://github.com/blog/1184-contributing-guidelines

    ReplyDelete
    Replies
    1. > Not cool.

      I think it's better to have no way to report issues than to have all issues ignored. If no one wants to do issue management then it doesn't make sense to offer it. If you'd like to take over issue tracking be my guest and I'll reopen it but I'm not willing to waste the time dealing with the same few complaints being posted over and over again.

      > Better approach would be to link to an FAQ with frequent errors from a highly visible place. You could use the github Wiki for hosting the FAQ.

      You mean like the wiki, manual and FAQ on Sigil's front page (https://code.google.com/p/sigil/)? GitHub is only meant for code hosting. It is not used for anything else. Hence why the GitHub wiki is not used and why the readme that displays on the GitHub project page says, "It's website is located here: http://code.google.com/p/sigil/".

      > See this link to find out how to add a contribution guideline link for issues on github: https://github.com/blog/1184-contributing-guidelines

      Branch, make changes, and submit a pull request. I don't think a separate document is necessary to say that. If someone doesn't already know how that works then they a document stating that probably won't be helpful anyway.

      Delete
    2. One of the reasons I thinks it's a bad idea to not have an issue tracker is because it's also important for collaboration between developers. I often find myself opening an issue for an open source project on github and after some discussion I have the required knowledge to be able to propose a pull requests. If there is no issue tracker I'm never going to get to that point, unless I know exactly what to change to begin with.

      Regarding the contributing guidelines: My idea there was, that these are displayed when one creates a new issue on github, so it would be a way to point to eg. a FAQ for people creating issues.

      Given that I have no experience in C++ and only use Sigil a couple of times a year to fix an ePub, I'd be a bad choice as an issue maintainer. But maybe someone else from the community wants to step up? Worth making a blog post and linking to it from the homepage and github.

      Delete
    3. > One of the reasons I thinks it's a bad idea to not have an issue tracker is because it's also important for collaboration between developers.

      True. In Sigil's case development discussion has always happened via email. This isn't a hard and fast rule but a choice made by people who have contributed.

      I did have the GitHub issue tracker open in hopes that it would be used by developers for this very reason. It was not. Non-developer started opening invalid issues. So I closed it. Right now you'd have to do a pull request say one line that doesn't really do anything to start a discussion using GitHub.

      > Regarding the contributing guidelines: My idea there was, that these are displayed when one creates a new issue on github, so it would be a way to point to eg. a FAQ for people creating issues.

      There is an FAQ for reporting bugs. The default text when opening an issue was a link tot he FAQ. It was routinely ignored.

      So what it comes down to is contributors opted not to use the issue tracker. The issue tracker was being abused (best way I can describe the situation) by people who weren't reading the FAQs.

      > But maybe someone else from the community wants to step up? Worth making a blog post and linking to it from the homepage and github.

      That's kinda the point of this post.

      Delete
    4. > In Sigil's case development discussion has always happened via email.

      While email discussion might be the preferred way for your existing contributors it's also a barrier for newcomers. Maybe you should try moving your communication more towards github, it has some great features for discussing code, linking commits etc. and by having those discussions publicly it makes it easier to take part.

      > I did have the GitHub issue tracker open in hopes that it would be used by developers for this very reason. [...]

      While I understand it's annoying to have all those useless issues on the tracker, one month is hardly enough time to see if you gain more traction by moving to github. Also if there are issues that pop up again and again, it's worth looking into how to avoid them from the software side, maybe showing a helpful note with a link when an error message pops up or something like that.

      > Right now you'd have to do a pull request say one line that doesn't really do anything to start a discussion using GitHub.

      You can't open a pull request without having forked the repository and having commits.

      Oh and you might wanna go through the google issues and close them, because they are still reachable if you are watching a ticket or just get there through a search engine. Eg. there we're still people discussing how to get Sigil running on Mavericks today, when the new release has been out for a couple of days, because no one closed the issue (and I can't even though I'm the issue starter).

      Just go to https://code.google.com/p/sigil/issues/list to see the list.

      Delete
    5. > While email discussion might be the preferred way for your existing contributors it's also a barrier for newcomers...

      There are a lot of different ways that could be available for newcomers. That doesn't negate that every single contributor thus far as opted not to use the issue tracker for development discussion.

      > While I understand it's annoying to have all those useless issues on the tracker, one month is hardly enough time to see if you gain more traction by moving to github.

      When the same issues were being opened on GitHub I lost faith in it being just used for developer topics.

      What this really comes down to is I don't have nor want to take the time to deal with the non-issues that keep coming up. If I'm only able/willing to spend a small amount of time on Sigil. If that time is taken up dealing with responding and closing the same issues I can't use that time for something more impactful.

      > Also if there are issues that pop up again and again, it's worth looking into how to avoid them from the software side, maybe showing a helpful note with a link when an error message pops up or something like that.

      One issue that keeps coming up is OS X 10.6 support. Sigil does not support 10.6. The download page for OS X states what versions of OS X is supported. Yet people still open issues (some demanding) support for 10.6.

      The user guide and FAQ is a menu option in the help menu in the application. Instead of reading what's right in front of them people ignore the info. The majority of the non-issues that are opened could have been solved by googling first. The default text for opening an issue even asks people to read the linked FAQ first.

      I believe I've done plenty to provide answers and information for the common issues that keep being opened.

      > Oh and you might wanna go through the google issues and close them, because they are still reachable if you are watching a ticket or just get there through a search engine.

      All are closed. Unfortunately, the issues and the issue page for opening new issues will always be accessible. Google Code only lets you hide the link on the main page. You can't actually disable the issue tracker.

      Delete