Since we'll be using issue and pull request systems a lot, we should try to be efficient and consistent while using them. This document explains the format and content of an issue, as well as pre and post processes of creating an issue.

Before Creating an Issue

• Check if the issue you're going to open is opened before. You can use the filter box in the Issues page to search for related keywords.
  
  (To search for closed issues, change is:open to is:closed)
  • If you find a related issue that is an exact copy of what you're going to open, don't open a new issue. You can reopen the old issue if you want reconsideration, or just add a comment.
  • If you find some issues related to what you're going to open, and if there is no exact copy, note their URLs down to refer them later while creating your issue.

Creating an Issue

• Pick a good issue name that is clear, compact and expressive.
  • Make sure that the issue name starts with a verb.
• Be consistent with our issue template while creating your issue.
  
  • Fill in as much of our issue template as you can.
    • You must give a brief explanation of your issue in the About part and you can't remove that block.
    • Don't forget to add all the related issues you've found and all the related links to your issue.
      
  • Remove the parts that are not related to your issue. For example; if there is no visuality related to your issue, remove the ## Visuals block completely.
• If it is not a backlog issue (the ones we need to discuss before start doing), assign the issue to the related person or persons immediately.
• Your issue must have one and only one status label at all times while the issue is open. Track the status of your issue and tag it with the relevant status label. When your issue is closed, remove the status label only if it's not status: late.
• You must tag the issue with at least one non-status label and you must add all the relevant labels to your issue. To find out which labels are suitable, you can use the Choosing the Right Labels part.

After Creating an Issue

• Add the issue to the relevant column in our Kanban board.
  (To open our board: Go to Projects tab in GitHub and choose the Interest Based Communities project)
  • To add your issue to the board: In the upper right part of our board, click on the Add cards button and drag your issue to the column that matches its status label.
    
  • Whenever your issue status changes, don't forget to change the place of your issue in the Kanban board.
• After the issue is complete - complete means the task is finished or it's not relevant anymore, you must tag the issue with status: review label and let at least one person review it before closing it.
  • If it does not pass the review, you cannot close the issue.

Choosing the Right Labels

backend: Backend related issue: API, database, server etc.
design: Design or sketch related issue: Mockups, diagrams, UI designs etc.
frontend: Frontend related issue: UI design implementations etc.
help wanted: Issue that needs help from others to complete.
meeting: Meeting related issue: Meeting notes, meeting plannings, meeting outcomes etc.
planning: Planning related issue: Changes in the project plan, meeting planning, planning a new feature etc.
question: Issue that asks a question or starts a discussion.
research: Research related issue.
status: backlog: Issue that is currently in the backlog and needs discussion before we start doing it.
status: in progress: Issue that is currently being done.
status: late: Issue that is overdue.
status: ready to do: Issue that has clear specifications and is ready to do.
status: review: Issue that is complete and under review.
type: bug: Bug related issue: Browser-specific bugs in UIs, backend bugs etc.
type: enhancement: Enhancement related issue: Enhancing the requirements, enhancing an old feature etc.
type: feature: Feature related issue: Creating something new, adding a new feature etc.
wiki: Wiki related issue.