Tagging allows the team to keep tickets organized. It also helps communicate where a ticket is in the pipeline (see the ticket lifecycle section in Creating a Bug Ticket .)

Status Tags

Status tags communicate what the status of a ticket should be so that the devs can appropriately move, manage and work on tickets. Updating ticket status is a quick, easy and painless way to help filter tickets for the devs so more time is spent on real issues and less is spent on noise.

  • dropped — The issue is not a valid bug ticket and is being dropped. The ticket will be closed.
  • duplicate — The issue is same as an issue reported in another ticket (include the other ticket number in the comments for tracking). The ticket will be closed.
  • not an issue — The issue described in the ticket is not really an issue because it is working as designed (the submitter misunderstood how something works), or is a result of a specific configuration (supported or unsupported).
  • will not fix — Core developers will tag a ticket will not fix to indicate that the current behavior is intended.
  • maybe later — The bug or feature request isn't planned on being added to the Shopp core at this time, but the developers might reconsider in the future.
  • works for me — The issue cannot be reproduced or confirmed with the amount of information provided. The ticket may be tagged with feedback to ask for more feedback from the reporter, otherwise it is closed.
  • confirmed — Tagged to new/incoming tickets when the issue reported can be reproduced using the steps and information provided indicating the ticket is ready for scheduling.
  • patch — Tagged to confirmed tickets. A call for someone to submit one or more patch files for the confirmed problem, or if the currently submitted patch does not appear fix the issue.
  • patched — Tagged to indicate that one or more patch file has been attached to the ticket. Please make use of standard diff (svn diff if applicable) tools to create patches. Code can be added to the text of the ticket, but this should be used as an aid for discussion. Include details about the version of the file that your diff was created from.
  • screenshot — A screenshot showing the problem is attached. This should be used for cosmetic problems, not for error messages.
  • stale — Tagged to indicate that the provided patch or screenshot is unusable due to it's age, or the version the patch file was created from.
  • verify — Tagged to an open ticket when a patch needs to be verified before it can be committed.
  • fixed — Tagged to tickets with a status or tag of review to signify when an issue has been fixed by code updates.
  • not fixed — Tagged to tickets with a status or tag of review to signify when an issue has not been fixed by code updates.
  • reopen — request a review of a ticket that was in review or closed that may need reopened.
  • feedback — A response is needed from the person(s) reporting the issue.
  • discussion — A ticket requires discussion to address. Larger issues are at hand than what the ticket describes.
  • 2nd opinion — Another person is needed to report an opinion about the ticket (problem or solution).
  • need dev — A developer response is requested on the ticket.
  • close — the ticket is a candidate for being closed.

Issue Type Tags

Issue type tags classify the tickets describing their purpose. Tagging appropriately helps devs prioritize them.

  • legacy — Ticket occurs in a previous release of Shopp prior to the current development milestone.
  • bug — Expected behavior isn't happening
  • issue — The ticket relates to a specific environment or edge case.
  • ui — The ticket relates to a display problem in the interface or in language.
  • enhancement — The nature of the ticket is primarily to enhance an existing feature or functionality.
  • feature — The nature of the ticket is primarily to enhance an existing feature or functionality.

Functional System Tags

  • activation — Tagged to tickets related to activating Shopp.
  • account — Tagged to tickets related to shopping cart functionality.
  • catalog — Tagged to tickets related to storefront catalog functionality.
  • cart — Tagged to tickets related to shopping cart functionality.
  • checkout — Tagged to tickets related to the checkout process functionality.
  • downloads — For product download functionality.
  • discounts — For promotions and discount issues.
  • taxes — For tax calculation problems.
  • install — For tickets related to installing, upgrading Shopp.
  • images — For issues related to images.
  • search — For issues related to search.
  • smart — For issues related to search.
  • shortcodes — For Shopp shortcode issues.
  • widgets — Shopp theme widget issues.
  • plugin api — For Plugin API functions.
  • theme api — For Theme API shopp() functionality.
  • payment gateway — Tagged to tickets related to a payment gateway module.
  • shipping module — Tagged to tickets related to a shipping module.
  • storage engine — Tagged to tickets related to a storage engine module.
  • documentation — The ticket relates to functionality that needs added to the documentation.

Tagging Style Guide

  • Software Versions
    When tagging software use an abbreviated form with major version numbers combined and point releases spaced for clarity.
    Examples: Firefox 4: ff4, WordPress 3: wp3, WordPress 3.2: wp 3.2
  • Shopp Versions
    When tagging shopp version numbers, just enter the version number.
    Examples: Shopp 1.1: 1.1, Shopp 1.1.9: 1.1.9, Shopp 1.2 Beta 1: 1.1b1
  • Addons vs Add-ons
    Use addons to refer to product add-on functionality. The commercial plugin add-ons released by Ingenesis should be tagged according to their functional class.
    Examples: PayPal Pro: payment gateway, Amazon S3: storage engine, Canada Post: shipping module
New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Plugin e-commerce for WordPress

Shared Ticket Bins

1.3 Development23% complete

 

Completed 23 of 102 tickets