-
Notifications
You must be signed in to change notification settings - Fork 6
Creating Issues
Our approach to creating this package is to operate completely within the GitHub sphere -- using those tools provided for creating issues, managing sprints, recording and developing against business requires, etc. All cards are created and managed within the GitHub Issues collection. With that in mind, we are currently following the following conventions:
We organize our cards using labels to designate these categories:
- Epics (Large areas of concern, closely related to bounded contexts)
- Features (Significant features grouped together under Epics)
- User Stories (Individual tasks/deliverables that can be implemented in a sort time. Grouped under Features.)
- Bugs (Errors/omissions discovered against the existing code base)
- Enhancement (Requests for new features)
- Priority (High, Medium, and Low priorities related to the order in which we'd like to implement things.)
- Help Wanted (general request for a developer to participate with a specific card)
Epics, in this system, represent our broadest categories of use. Things like Intake, Party Management, and Medical care for the animals are covered under this category.
Features are held to be much more specific. As an example, some of the features under Intake include things like taking and storing a photograph of the animal, gathering pet information, or gathering general intake information.
User Stories are the actual work items in our approach. For example, during Intake we will have User Stories around behaviors such as collecting the surrendering party name, address, or other contact information. Each of these items represent a specific piece of value used to fulfill the Feature.
Bugs are obvious. We capture one whenever a defect is detected in our software.
Enhancements may take the form of Epics, Features, or User Stories -- depending on the size of the Enhancement being requested.
Priority is set by the development team based on user urgency to complete the card.
When a card exists that may reasonably be accomplished by someone other than the core contributors, it will be flagged with a Help Wanted label to allow interested collaborators to complete it and submit a pull request.
Cards are created with a specific set of attributes in order to make it easier to understand and complete them. These are the things we look for in a card:
- If the card is part of a larger scope, we put the Parent card, by name and number, at the top of the card. We follow that with enough descriptive text to allow anyone to pick up and understand the purpose of the card. Epics are quite general. Features are a bit more specific and may contain actual implementation details or sequence. User Stores must be sufficiently detailed to allow any contributor to pick it up and work it with little or no additional discussion.
- Any specific Claims are specified where authorization for the behavior described in the card is necessary.
- UAC (User Acceptance Criteria) is specified to allow integration tests to be created and prove, in an automated manner, that the story has been correctly implemented.
- User stories are created using either a Given/When/Then or As/When/Then structure. This facilitates both understanding initial criteria as well as simplifying the creation of integration tests.