History

Triage-a-thon

Welcome to the Puppet Labs first Triage-a-thon! Thanks for helping out!

If you have any questions:

Objective


  • Refresh and update open tickets to ensure they are current and accurate
  • Ensure current open tickets are properly categorized and assigned to the right status
  • Close any tickets that are invalid, no longer required or already fixed.
  • Contribute code and tests to fix tickets.

How it will work


You will get assigned a block of ticket numbers and you should work though all the open tickets in that range.

The ticket ranges are detailed in this document.

The top people who achieves the highest number of ticket updates will win prizes. You can see the tally of who has updated the most tickets here. Everyone involved will get a reward for contributing. To register for your reward could you please sign up here.

Puppet Labs people will also be on hand and available to provide advice and answer questions.

Prerequisites


  1. You’ll need a Redmine account – you can sign up here
  2. Join the Puppet project – click the Join button/link here
  3. If you intend to contribute a patch or code during the Triage-a-thon could you please sign a Contributor License Agreement here

Triage instructions


So what should you do?

  1. Check the ticket makes sense – is it clear what the requester wants?
    a. Is the problem description detailed enough?
    b. Is there a description of what is broken and how to replicate the problem?
    c. Is it clear what the affected version(s)/platform/feature this affects?
    d. Is it assigned to the right category? e. Is the output/code/log data clear and structured (you can edit this by updating the ticket and clicking the “More” button next to the “Change properties” line)
  2. Is it assigned to the right tracker – is this a Bug or a Feature?
  3. Can you replicate the problem?
  4. Can you fix the problem? Patches and tests are very welcome see our Development_Lifecycle

Ticket Workflow


  • If you work on a ticket assign it to yourself.
  • When you finish with a ticket report the final state you left it in and ensure the current status, category, target release, etc is correct.
    • if the code is not merged, use the “generic branch” target release, like 2.7.x, and not the specific versions like 2.7.11.
  • When you merge a ticket always specify the Target Release it will be released in and change the status to Merged – Pending Release.
    • this is a release number like 2.7.11; you should use the next number after the current public release.
    • if this is for telly, the next major release after the 2.7 series, assign to telly

What Ticket Statuses Mean


  • Unreviewed – No one has looked at this ticket
  • Investigating – I am looking at this ticket
  • Accepted – This ticket is accepted and will be addressed at some point
  • Needs More Information – This ticket needs more information from the current assignee. Please remember to assign the ticket to whomever you wish to get information from.
  • Needs Decision – This ticket is pending a decision from someone. Please remember to assign the ticket to whomever you wish to get a decision from.
  • Code Insufficient – The code in this ticket doesn’t address the problem or feature described in the ticket.
  • Tests Insufficient – The tests in this ticket don’t address the problem or feature in the ticket or no tests are present.
  • Requires CLA to be Signed – A CLA needs to be signed before this code can be reviewed and merged.
  • In Topic Branch Pending Review – This code is ready for review and merging.
  • Merged – Pending Release – This code has been Merged. Please remember to specify the Target Release of this ticket.
    • This is the only state where a ticket should have a specific minor release number (eg: 2.7.11) associated with it.
  • Closed – The ticket is closed and complete. Tickets should be placed in this state when they are complete and released.
  • Duplicate – This is a duplicate of another ticket. Please add a reference to the duplicate ticket in the Relationships drop-down.
  • Rejected – This ticket is not an issue, is a user error or is a bug or feature we’re not going to address.
  • Re-opened – Someone disputes the Closed state of a ticket. Should be assigned to the person who originally closed the ticket.

Problems/Issues/FAQ


Q. I need help working out if this is a real bug or a feature.
A. Talk to a Puppet Labs employee on the IRC channel – #puppethack or email the user list.


Q. What if I don’t have permission to change a ticket?
A. Ask in the #puppethack for help – IRC handle jamesturnbull – or email james@puppetlabs.com


Q. If the bug or feature in a ticket applies to multiple releases which Affected Release should you assign it to?
A. The earliest version affected.


Q. If a ticket is targeted for multiple versions which version do I put into Target Release?
A. The earliest version the ticket is merged into.


Q. I need someone to make a product decision about whether a feature gets accepted.
A. Talk to a Puppet Labs employee, try nigelk first.


Puppet Labs employees on #puppethack

haus
jamesturnbull
kelseyhightower
nigelk
ryancoleman
joshcooper
grim_radical
djsauble_