I use Jira from Atlassian, so your mileage may vary.

A feature is:

• something the product does
• think marketing brochure bullets or finding it in the User Manual
• It might get bugs.
• It might get improvements.
• It might even be dropped.

A task is

• something done one time
• Is often an implementation detail for creating features
  
• never appears on a marketing brochure or in a feature list
• Examples:
  • add users for beta;
  • get app stood up on PROD;
  • write a Flex UI training plan
  • Implement the persistence layer (tables, DAO)
    

A subtask is a small bit of effort that you might do to accomplish the parent issue. It is often useful to help you track your to-dos and to estimate a larger task b breaking it down.
A bug is something that is not working according to plan. Covered on Writing Good Bugs.

Tips

Issue Type
Summary (Title)	Make the title clear and concise. It should indicate something the user does or the system does. If it is a Group-type issue, preface with "Group: " just so that it stands out in the various views. "Agent can select COB easily" "Agent can view premium breakdowns and summary"
Description	NOTE: For lengthy descriptions that also serve as "corporate memory" of the major requirements, do the bulk of docs on the wiki, summarize in the issue and paste a URL. Be sure to describe the issue fully so that the "client-valued" aspects shine through. Here are some templates (search Google for more) to help you word the issues properly. One template "As a role, I should be able to feature, so that benefit" "As an Agent, I should be able to choose class of business easily (searching by name or SIC code), so that I can quickly and accurately prepare a quote for my client." FDD template Another template (from Feature-Driven Development) is: <action> <result> <object> "Display the detail & summary premium data (to the agent)." "Create a PDF of the detail & summary premium data (so the agent can send to client)." Scenario Template Be sure to also include how to know when an issue is complete and testable. Describe various scenarios if needed, when there are different conditions to consider. The point here is to make it clear to the developer and the tester what is expected. Title Clearly describe the context/what's different Given... Some context When... User does xyz Then... this happens Examples: Title Show Premium Details - Single Line Of Business Given... A Quote for Business Owners Insurance When... displays the premium after successfully rating Then... a clear breakdown of the premium details (from ART) will be displayed in a UI, see wiki. At the bottom of the columnar-based details, show a Premium Total. Title Show Premium Details - Multiple LOBs Given... An RQA with Business Owners + Workers Comp When... displays the premium after successfully rating Then... For each LOB, show a clear breakdown of the premium details. For each LOB, show the premium subtotal. At the bottom of the columnar-based details, show a Premium Total for all LOBs.
Component	Useful to link the issue to a specific area of the application or work efforts.
Version	a.k.a. "Iteration" -- implies when the feature is scheduled for completion
Assign	Set during issue handling process. Generally should be based on person's knowledge and skills in inverse proportion to the criticality and complexity and deadline. Should not simply be any warm body.
Priority	Often known in advance. Helps team understand relative importance of an issue. Macro priority is the Version. This priority can sometimes be used to help a developer sort their work tasks in proper order.
Estimate	Developer doing the task can enter their estimate (see process)
Due Date	Used when an issue needs to be done by a date other than end of milestone (used infrequently).
Attachment	Upload any useful attachments, or reference those that are on a wiki page!
Links	If there are related issues or dependencies, add them via link. For example see Linking Issues