Skip to content

Submitting Bug Reports

Bennett Blodinger edited this page Aug 11, 2013 · 1 revision

Quick Guidelines/Rules

  • Please only file bugs and feature requests.
  • Try searching for a couple of the keywords you would include in your bug report, to see if anybody else has already submitted a bug like yours.
    • If a bug already exists, add a comment! The more comments a bug gets, the more important it is in our eyes!
  • If you need to post a crash dump, patch, config file, etc., please do it as an attachment, and do not paste it into the submission box.
    • When attaching plain text files, attach them as such. Don't give us .doc, .rtf, etc.
    • A plain text, properly formatted crash report is automatically generated for you in: ~/Library/Logs/CrashReporter/ApplicationName_DateTime_Hostname.crash
  • When you think you're ready, head over to Issues and fill out the form. Don't forget to attach your files if necessary!
    Thanks for supporting CoRD!

Writing a good bug report or feature request

When you experience a bug or have a feature epiphany, we want your feedback! However, we need detailed feedback, in order for us to best use our time FIXING or ADDING your feature and not trying to work out what you want. Contrary to popular belief, this stuff isn't magic and we put a lot of thought into every change we make so that we can keep CoRD as light and fast as possible while making is as useful and feature-filled as we can.

Bug Reports

When we're looking at bug reports, it helps to have a crash report (if there was a crash) or a screenshot of the misbehaving (if possible). If neither of those are possible then a somewhat detailed (but concise, we know you don't want to write a lot, and we don't want to read a lot either) report. Please include the version and build number you experienced the issue on in your report! Regardless of whether you get a crash report or screenshot or nothing at all, we need steps to reproduce. We weren't there when the crash happened, so we need you guys to tell us what led up to it. How many sessions were open at the time, and what OSes were they connected to? What did you click on or what series of things did you do that lead up to the crash?
Any nugget of information (within reason) can help us narrow a crash down and get it resolved, so be thorough.

Feature Requests

When submitting feature requests, many of the rules of bug reports apply. We need details! If you have any talent with graphics tools and want to submit a mock-up that's fantastic. If not and you want to butcher something out in Word, as long as it conveys what you're trying to get across we'll take a look at it. We swing a pretty big ax with feature requests, so don't feel bad if your idea doesn't make the cut, and don't let it stop you from submitting ideas in the future. We want to include as much as possible, but we also want this to remain a true Cocoa app, remaining light and powerful by staying focused on its primary task, and not getting bogged down in the bloat that slowly kills apps (see: Firefox, Windows, etc).

Patches

Many hands make light work -- John Heywood

We love getting patches! If you have a great idea for a feature request, or a nagging bug that you want to get rid of, and you want to fix it yourself, we are more than happy to check out what you do and commit it to the trunk if its something we see as valuable. Efforts like that drive open source, so we're happy to have as many contributors as we can to carry the project forward.

FAQ

Why do I need to attach Crash reports?

Attaching them as a text file keeps them from getting stored in Trac and clogging up the database. It also makes them easier for us to move around and read when we have to.

Why do i need to be registered to submit a bug report?

Anonymous tickets are not fun because it is impossible to get follow-up information unless the person frequents their bug report waiting on questions. By logging in, we can follow up with you if we have questions about your situation, making our lives easier and hopefully leading towards making yours easier too!

Why did my bug report or feature request get marked as a duplicate of a ticket that isn't like it at all?!

We use GitHub's Issues to keep track of tasks for us to do in development, not to track individual problems people have. If you have Crash A, and report it, and it gets marked as duplicate of Crash B, even though Crash B was nothing like what you experienced, we have more than likely deduced that the two are related and plan on fixing them together. If NewFeature A is nothing like NewFeature B, but we said it was, it's probably because both features will fall under NewFeature C, which we already plan on implementing (like sending complex keys (ctrl-alt-del, insert, scroll lock, pause, print scrn, etc) to the remote machine via menu items. If you just asked for one of those, we're marking you as a duplicate and closing your ticket). This helps us manage what we need to do, and not get bogged down in managing a whole bunch of superfluous tickets.