6.5 KiB
Git Project Management Issues
This is an example on how to organize the issues. The basic usage is quite simple, only use 3 status (todo, started, done)
The second section "Issues" show a more advanced usage which once you're used to org-mode shouldn't be too hard to follow. Mainly the idea is simply to add tags and properties. You can use tags as github labels. And think about properties to manages meta datas such as:
- Assignee (who is assignee to an issue)
- Reviewers (who is asked for review)
- branch (the branch asked for a review before merge)
Basic Usages
The basic usage is to simply create the todo list. The reviewers could simply add sub items to provide remarks or even other todos.
TODO Do thing 3
STARTED Do thing 2
DONE Do thing 1
Complex Usage with Review
We will also use the basic but we also consider PR and their review. So we add a few informatiosn for org-mode typically we decalre common properties to be used.
REVIEW Basic review process
So basically the reviewer should write his review here. As the reviewer should
switch branch to the working branch the issues.org file won't be easy to
reach.
So it is up to the user to create a file ~/.reviews/<branch-name>-<reviewer>.org
The reviewer then will only need to write down its remarks.
To make things easy you can link the files with their lines using
file:path/to/file:::NNN.
Once the review is finished. The reviewer simply need to:
- switch to the
gpmbranch - copy the review file into the
reviews/directory - make a commit aboute the finished review.
The contributor will then be able to copy the content of reviews/ into
~/.reviews/, switch to the branch to be merged, read the review, make fixes,
add comment to the review files, etc…
ACCEPTED Review finished
Please change something
edit: switched from CHANGE_REQUESTED to ACCEPTED!
FEEDBACK Changed!
MERGED Write a CONTRIBUTING file doc
CLOSED: [2018-08-28 Tue 22:51]
ACCEPTED Advanced review workflow explained!
A simple way to write and read review is to use org-capture.
It will create a file with links to the file your are inspecting in emacs
without modifying the file.
A simple way to achieve this would be to create a reviews directory:
mkdir ~/.reviews
Then in the next section
Use C-c C-c to execute that and so you'll see all annotations.
Mainly the reviewer only need to use org-capture and put the result
in reviews.
;; (load "../gpm-review-0.0.1/gpm-review.el")
(require 'gpm-review)- Start by using
C-c C-chere. - Switch to the issue branch.
- If you just want to read the review open the
(gen-review-file-name) - If you want to add a remark use
org-captureto open the org file that will contain your remarks with a link to the line and file. I think to make it easier all member of the team should put their projects in the same place. Typically~/dev/project-name.
(concat "[[~/.reviews/" (gen-review-file-name) "]]")[[~/.reviews/write-contributing-yogsototh.org]]
(start-review)(end-review)TODO [B] Write a tutorial doc
Should contains a complete tutorial
WAITING [A] Write Install section in README doc ops
Explain how to install the project
DONE Write README file doc
The goal is to write a text file with all informations about the project
Shubby: @Alex should I write a subtitle? Alex: @Shubby I think you can"
Full Professional Usage
Mainly think agile kanban/scrum with QA and Ops team So we need to think about 3 kind of issues. Epic, user story and task.
if you are fan of scrum / kanban methodology epic
Write the detail of the epic. If you are working on writing the epic you might put a TODO or WAITING or create
Subtask 1 user_story
Describe the feature the user want and create all subtasks as well as a list of tests tasks for QA team. If needed add some informations for the ops team if they need to change something to deploy it correctly.
REVIEW technical task 1 task
Describe the technical task.
MERGED technical task 2 task
CLOSED: [2018-08-30 Thu 12:54]
ACCEPTED Review finished
REFUSED test by QA task qa
CLOSED: [2018-08-30 Thu 13:02] Describe how to test. If something fail, describe which test is failing, etc…
I can't make it work! Please fix it please.
TODO deploy a redis instance task ops
Subtask 2 user_story
TODO technical sub task 1 task
TODO technical sub task 2 task
TODO test by QA task qa
Describe how to test. If something fail, describe which test is failing, etc…