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.
Type
- enhancement
- defect
- discussion
Status
- waiting?input
- confirmed
- detailed
- waiting?validation
- blocked
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