From Zenoss Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Steps for Filing a Successful Bug

Zenoss uses JIRA to process and manage bugs. First create an account in Jira. (For more information about creating an account in Jira, see <insert link>.)

Then complete the following steps to file a bug.

Head over to Zenoss's JIRA and create an account.

  1. Log in to Jira.
  2. Click the Create Issue link (top right) to submit a ticket. Ensure you include the following information:
    • Log files
    • Pictures or video that illustrate the issue
    • Detailed reproduction steps (Zenoss Engineering will use these steps to try and reproduce the issue, and will also use these steps to verify the fix)
    • Frequency of occurrence (Did you only see it once, or does it happen every time, even after restart?)
    • Impact - How does this issue affect your Zenoss deployment (data loss, poor user experience, etc.
  3. Email the Zenoss Community Manager with a link to the bug in the email. The Community Manager attends the Defect Review meetings and will be your advocate.
  4. If you have questions, concerns, need an update, or have a reason to escalate a bug you've posted, please post an update in the bug, and then contact the Community Manager and ask for a second defect review.
  5. Keep up on feedback on your bugs. Often during the process of triaging or resolving your bugs, one of our engineers will have a question about your bug. Please respond in a timely manner to ensure your bug is resolved quickly. If you run into problems or need someone to advocate on your behalf, do not hesitate to contact the Community Manager.

Defect Lifecycle

Defect Review

Stakeholders from Dev, QA, Support, Services, Community, and Product Management meet every two weeks to do a defect review. During this meeting the defects are prioritized and are escalated to a higher priority via a committee.

Defect CleanUp

Unfortunately, our engineering team doesn’t the resources to address every incoming defect. However, as pieces of our product are rewritten or updated, existing defects get fixed as a side effect of some other fix or code refactor. While the Zenoss QA and Dev teams attempt to look for overlapping defects, it is often difficult to determine if the bug they found is exactly the same as the bug you experienced. This means that it is important to keep the list of open bugs current and valid by closing older defects we don’t have the engineering resources to fix.

How Defect Cleanup Works

  • We will now close bugs that are obviously not going to get fixed at Defect Review based on low prioritization
  • Each quarter, we will review P1 bugs that are 90 to 180 days old days old to ensure they are being addressed. Unresolved P2, P3, and P4 bugs will be closed with a message requesting additional information/justification for a fix.
  • If a P2, P3, or P4 bug is re-opened, it will be addressed again at Defect Review. If the bug is retained, it will be assigned, and reviewed again in 90 days. If it still has not been fixed it will be closed.

What does this mean for you?

  • Faster, more accurate communication about the status of your bug
  • Fewer defects in the system will mean slightly more fixed bugs due to decreased overhead

Defect Closure Perceptions

Perception 1: P3 and P4 defects rarely get fixed.

Internally, we prioritize bugs and work on bugs in priority order, with P1 defects being addressed first. It may seem that lower-priority P3 and P4 defects rarely get fixed. However, we are making progress. In the past 10 months (as of Feb 2013), Engineering closed approximately 170 P3/P4 defects. Incidentally, this is not an accurate count since many P3/P4 defects by definition are moved to a P1 state by the defect review to ensure inclusion in a specific release. The real number of P3/P4 defects closed is actually significantly higher.

Perception 2: My defects never get fixed.

In the past 10 months (as of Feb 2013), Engineering has closed 1500-2000 defects and processed approximately 5000 issues in the defect tracking system. If your reported defect has not yet been fixed, we sincerely apologize -- we are getting to it as fast as we can! You can help us to make the process go more smoothly by ensuring that you reply promptly to any of our comments, and if you feel that a defect has been handled improperly or deserves higher prioritization, let us know in the defect comments and we'll do our best to address it.

Perception 3: Once my defect has been closed by the 18 month rule, there is no recourse.

While it may feel like we just zapped your carefully-reported bug -- sending it into oblivion forever -- that is only true if you let us get away with it. :) If you feel that your reported issue should remain in the purview of the engineering team, the best option is to first confirm the defect still exists in the latest released version of Zenoss, and open a new defect with the newest information, reproduction steps and justification for higher prioritization. This will trigger the defect review committee to reevaluate the issue in the latest release context, possibly promoting the defect to a higher priority/severity. This is a great help to us and we will do our best to try to minimize the inconvenience of doing this as much as possible.