Deciphering the Issue Queue - Southbacon/the-crispy GitHub Wiki

  • Issues should be labeled with one of the existing projects or with the feature request label. They may or may not have another label.

  • Issues are assigned to a milestone depending on their urgency and/or if functionality related to the issue is being released in the same milestone.

  • Milestones are versioned using Semantic Versioning.

  • Team members may make their vote on a feature request by responding to the original issue description with either a thumbs up :+1: or thumbs down :-1:.

    The main issue description.

    React to the main issue description.

    The resulting reaction.

    All issues are open for discussion in either Github issues or in the #the-crispy Slack channel.

  • Once feature requests are discussed and decided on, the following actions should be taken:

    • If the team decides that the feature request will be useful and should be integrated, we can change the issue to an enhancement and create a separate new tag to categorize all new issues for the new feature.
    • If the team decides that the feature will not be useful, we can close the feature request issue.

  • New issue descriptions should use this markdown as a template:

    **The bot should:**
- Bullet point describing a requirement, and
- another bullet point describing another requirement or that depends on the prior requirements.

**Open question(s):**
- [ ] Should we...?

    That said, not all discovery tickets will have the first section because logic is still being hashed out, and not all non-discovery tickets will have the second section because the logic might have already been decided on.

  • Answered questions are checked on and should have a comment on the same issue about its resolution.