Issues Notes - bounswe/bounswe2018group7 GitHub Wiki

Things to Remember While Opening an Issue

  • First of all, try to avoid opening duplicate Issues. There is a filter/search bar at the top of Issues section.
  • Write a clear and short title. Give details (if any) in the description.
  • Add labels (details below).
  • Add assignees. (NOTE: The teacher and the assistants are also shown in the assignee list. So, do NOT blindly select everyone in that list while opening an Issue which is related to every group member.)

Detailed information about Issues can be found here.

Labels and Their Intended Meanings

Here are the labels we are currently using and we are planning to use in the future:

Priority Labels

There should NOT be more than one priority label at any time on an Issue.

  • priortiy:urgent
  • priortiy:high
  • priortiy:medium
  • priortiy:low

Relation Labels

There can be more than one relation labels on an Issue if it makes sense.

  • relation:android The Issue is related to the Android platform.
  • relation:backend The Issue is related to the back-end parts of the project.
  • relation:frontend The Issue is related to the front-end parts of the project.
  • relation:test The Issue is related to the test parts of the project.
  • relation:documentation The Issue is related to the documentation parts of the project. (README files and code comments only)
  • relation:wiki The Issue involves some tasks about the Wiki section of the repository.

Status Labels

There should NOT be more than one status label at any time on an Issue.

  • status:in-progress Assignees of the Issue started to work on it.
  • status:needs-review Assignees of the Issue need a review for the Issue.
  • status:completed The Issue is done. This is generally shows that the Issue should be closed.
  • status:invalid The Issue is not related to anyting about the project or the repository. (e.g. It was opened as a mistake.)
  • status:duplicate Another Issue for the purpose of this one has already been opened (and maybe has been closed).
  • status:wontfix The assignee of the Issue refuses to fix the specified bug/error.

Lifecycle of an Issue

  • When a new Issue is opened, it should be given status:in-progress label.
  • An assignee of the Issue should change status:in-progress to status:needs-review to state that (s)he needs some feedbacks from the other teammates. (Note that updating the label does not notify group members. It is a good practice to write a comment and tag usernames of other group members to notify them.)
  • When an Issue is closed, it should be updated with one of status:completed, status:invalid, status:duplicate or status:wontfix.

Closing Issues via a Commit Message

Try to avoid closing a code-related Issue by hand, unless it is one of invalid, duplicate and wontfix. Instead, refer to the Issue in your commit message with the keyword Fix. (See Closing Issues via Commit Messages) Doing so will automatically close the Issue when your commit is merged into master branch. After you solved the Issue on a separate branch, don't forget to update the Issue with label status:completed.

Type Labels

There can be more than one type labels on an Issue if it makes sense.

  • type:project-task Stuff that is related to the project but is not related to the code/implementation. (e.g. Project Plan)
  • type:non-project-task Stuff that is not related to the project. (e.g. Writing meeting notes on Wiki)
  • type:enhancement Some enhancements need to be (or will be) done to the specified part(s) of the project or the repository.
  • type:question A question about the project or the repository related part(s).
  • type:suggestion A suggestion about the project or the repository related part(s).

Code/Implementation Specific Labels

  • type:new-feature A new feature needs to be (or will be) designed/implemented in the project.
  • type:bug There is a bug in the specified part(s) of the project.