Ticket handling

<Tickets

This document outlines the best practices for handling tickets in a medium/big size Open Source Project. As CocoaPods is developed on GitHub and thus is based on GitHub features, except this point all the concepts are applicable to other Open Source Project.

The following guidelines are indicative and any step can be skipped when reasonably useless.

CocoaPods' ticket handling and development is an open process where actors use their own judgement to decide whether they are comfortable undertaking an action. If for any reason there is no enough confidence for an action the rest of the team can be called.

<Labels

Tickets are classified along 4 axis: type, status, difficulty and priority. Every time a label is applied or changed a comment should be posted including any relevant information.

<Steps to resolve a ticket

• Type identification
• Clarification
• Confirmation
• Identification of the actions
• Implementation
• Validation

<Type Identification

The ticket type should be set to either: enhancement defect discussion

If the ticket duplicates another one it should be closed as duplicated indicating a comment.

<Clarification

The ticket status should be changed to waiting input

If the ticket description is incomplete or unclear further information should requested to the submitter. This information might include a reproducible test case for defects.

<Confirmation

Either ticket should either to closed or its status should be changed to confirmed

If the ticket is considered highly desirable it can be prioritised setting the priority to ★

Defects

A defect can be confirmed by reproducing the test case reported by the user. The confirmation comment should report the version of CocoaPods used and should be considered valid for 2 minor versions. Moreover it should include a report of the output generated by the tool and the contents of any generated artefact if relevant.

Features

Minor enhancements can be confirmed by any contributor, major ones instead require the opinion of a member of the Core team as their judgement might require architectural and philosophical implications.

<Identification of the actions

The ticket status should be changed to detailed

If there is another ticket which should be resolved before implementing this ticket the blocked label should be applied and a comment indicating the dependency should be posted.

In this step, according to the breath of the change and the technical difficulty involved with it, the difficulty of the ticket should be set to either easy moderate hard

Consists in the description of the changes which should be performed to the output of CocoaPods indicating the command (or the context where they should happen) if relevant.

Moreover the comment should include a description of the programmatic changes required to implement the ticket.

<Implementation

After the ticket has been implemented via a pull request it can be marked as waiting validation

<Validation

Once a ticket has been implemented it should be validated, merged and finally closed.

To validate the implementation of a major ticket a member of the Core team is required.

Unless for trivial changes every pull request should include:

• Tests to prevent a regression
• A note in the CHANGELOG