I'd appreciate you to take a moment a look over this document before submitting an issue to one of my projects. It really helps me out. It signals to me that you respect my time. In turn, I'll show the same respect in addressing your issue.
Afterwards, maybe we can go to the movies and share a tub of popcorn.
As @fat discusses, an issue is typically one of the following:
- Bugs — when a feature of the project has been identified as broken
- Feature requests — when you ask for a new feature to be added to a project
- Personal support requests — when you are having trouble setting up a working instance of the project
Hey, I'm just one guy. As such, I simply do not have the bandwidth to provide personal support for everyone's implementation issues. The issue tracker is best used for bugs and feature requests.
But I don't want to leave you high and dry. If you can follow the steps below, I'll be best-suited to possibly provide a solution.
I reserve the right to close any issue I deem as an implementation issue, general development question, or personal support request.
- Identify the conditions for the issue. When and how does it occur?
- Remove the resource from the project — does the issue still occur?
- Recreate the issue in an isolated example. Try creating a simplified version of your page where it only deals with re-creating the issue. jsFiddle is perfect for this.
fat:
[T]he first and single most import thing for you to do when filing an issue is concentrate on isolating a demonstrable problem. The goal here is to be able to provide the most mind numbingly simple and easy to reproduce problem as possible.
A live URL is required. An isolated example in jsFiddle is ideal. Otherwise, if you have a live site, add the link. Without seeing it in the browser, I don't have a good idea of what you're trying to achieve.
Pasting code does not help as much as a live URL.
Describing a dev problem is like showing a picture of your car to a mechanic. If you want me to fix it, I need to put my own hands on it.
