2018-08-28 17:25:00 +00:00
|
|
|
#+Title: Git Project Management Issues
|
|
|
|
#+Author: Your Name <your email>
|
|
|
|
#+PROPERTY: Effort_ALL 0:10 0:20 0:30 1:00 2:00 4:00 6:00 8:00
|
2018-08-30 11:03:28 +00:00
|
|
|
#+TODO: TODO(t) STARTED(s) WAITING(w) | DONE(d) CANCELLED(c)
|
2018-08-28 17:25:00 +00:00
|
|
|
#+COLUMNS: %38ITEM(Details) %TAGS(Context) %7TODO(To Do) %8ASSIGNEE %5Effort(Time){:}
|
2018-08-30 11:03:28 +00:00
|
|
|
#+TAGS: bug(b) doc(d)
|
2018-08-29 15:32:10 +00:00
|
|
|
#+STARTUP: content
|
|
|
|
#+STARTUP: latexpreview
|
2018-08-28 17:25:00 +00:00
|
|
|
|
|
|
|
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
|
2018-08-28 20:52:30 +00:00
|
|
|
|
|
|
|
The basic usage is to simply create the todo list. The reviewers could simply
|
|
|
|
add sub items to provide remarks or even other todos.
|
|
|
|
|
2018-08-28 17:25:00 +00:00
|
|
|
** TODO Do thing 3
|
|
|
|
** STARTED Do thing 2
|
|
|
|
** DONE Do thing 1
|
|
|
|
|
2018-08-30 11:03:28 +00:00
|
|
|
* 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.
|
2018-08-28 20:52:30 +00:00
|
|
|
|
2018-08-30 11:03:28 +00:00
|
|
|
#+PROPERTY: ASSIGNEE
|
|
|
|
#+PROPERTY: REQUESTED_REVIEWERS
|
|
|
|
#+PROPERTY: REVIEWER
|
|
|
|
#+PROPERTY: BRANCH
|
2018-08-30 12:34:02 +00:00
|
|
|
#+TODO: REVIEW(i) | MERGED(m)
|
2018-08-30 11:03:28 +00:00
|
|
|
# for Reviews
|
|
|
|
#+TODO: ACCEPTED(a) CHANGE_REQUESTED(c) QUESTION(q) FEEDBACK(f) | REFUSED(r)
|
2018-08-28 20:52:30 +00:00
|
|
|
|
2018-08-30 12:34:02 +00:00
|
|
|
** REVIEW Basic review process
|
2018-08-28 20:52:30 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
:BRANCH: explain-review-process
|
|
|
|
:ASSIGNEE: yogsototh
|
2018-08-30 11:03:28 +00:00
|
|
|
:REQUESTED_REVIEWERS: shubby
|
2018-08-28 20:52:30 +00:00
|
|
|
:END:
|
|
|
|
|
|
|
|
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:
|
|
|
|
1. switch to the =gpm= branch
|
|
|
|
2. copy the review file into the =reviews/= directory
|
|
|
|
3. 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
|
|
|
|
:PROPERTIES:
|
|
|
|
:REVIEWER: shubby
|
|
|
|
:END:
|
|
|
|
|
|
|
|
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]
|
2018-08-28 17:25:00 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
:BRANCH: write-contributing
|
2018-08-28 20:52:30 +00:00
|
|
|
:ASSIGNEE: shubby
|
2018-08-30 11:03:28 +00:00
|
|
|
:REQUESTED_REVIEWERS: yogsototh
|
2018-08-28 17:25:00 +00:00
|
|
|
:END:
|
2018-08-28 20:52:30 +00:00
|
|
|
*** ACCEPTED Advanced review workflow explained!
|
2018-08-28 17:25:00 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
:REVIEWER: yogsototh
|
|
|
|
:END:
|
|
|
|
|
2018-08-28 20:52:30 +00:00
|
|
|
A simple way to write and read review is to use ~org-capture~.
|
2018-08-28 17:25:00 +00:00
|
|
|
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.
|
|
|
|
|
2018-08-28 20:52:30 +00:00
|
|
|
Mainly the reviewer only need to use ~org-capture~ and put the result
|
2018-08-28 17:25:00 +00:00
|
|
|
in =reviews=.
|
|
|
|
|
|
|
|
#+NAME: init-reviews
|
|
|
|
#+BEGIN_SRC emacs-lisp :results silent
|
2018-08-29 15:32:10 +00:00
|
|
|
;; (load "../gpm-review-0.0.1/gpm-review.el")
|
|
|
|
(require 'gpm-review)
|
2018-08-28 17:25:00 +00:00
|
|
|
#+END_SRC
|
|
|
|
|
2018-08-28 20:52:30 +00:00
|
|
|
1. Start by using =C-c C-c= here.
|
|
|
|
2. Switch to the issue branch.
|
|
|
|
3. If you just want to read the review open the =(gen-review-file-name)=
|
|
|
|
4. If you want to add a remark use =org-capture= to 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=.
|
|
|
|
|
|
|
|
|
|
|
|
#+BEGIN_SRC elisp
|
|
|
|
(concat "[[~/.reviews/" (gen-review-file-name) "]]")
|
|
|
|
#+END_SRC
|
|
|
|
|
|
|
|
#+RESULTS:
|
|
|
|
: [[~/.reviews/write-contributing-yogsototh.org]]
|
|
|
|
|
2018-08-28 17:25:00 +00:00
|
|
|
#+BEGIN_SRC elisp :results silent
|
|
|
|
(start-review)
|
|
|
|
#+END_SRC
|
|
|
|
|
2018-08-28 20:52:30 +00:00
|
|
|
#+BEGIN_SRC elisp :results silent
|
|
|
|
(end-review)
|
|
|
|
#+END_SRC
|
|
|
|
|
2018-08-28 17:25:00 +00:00
|
|
|
** TODO [#B] Write a tutorial :doc:
|
|
|
|
Should contains a complete tutorial
|
2018-08-30 11:03:28 +00:00
|
|
|
** WAITING [#A] Write Install section in README :doc:ops:
|
2018-08-28 17:25:00 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
:ASSIGNEE: yogsototh
|
|
|
|
:END:
|
|
|
|
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
|
|
|
|
|
2018-08-28 20:52:30 +00:00
|
|
|
Shubby: @Alex should I write a subtitle?
|
|
|
|
Alex: @Shubby I think you can"
|
2018-08-30 11:03:28 +00:00
|
|
|
* 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.
|
|
|
|
|
|
|
|
# for Epics and User Stories
|
|
|
|
#+TODO: TO_DESCRIBE(b) IN_PROGRESS(g) TEST(e) | DELIVERED(l)
|
|
|
|
#+TAGS: epic(e) user_story(u) task(t) qa(q) ops(o)
|
|
|
|
** 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.
|
2018-08-30 12:34:02 +00:00
|
|
|
**** REVIEW technical task 1 :task:
|
2018-08-30 11:03:28 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
:BRANCH: tech-task-1
|
|
|
|
:ASSIGNEE: yogsototh
|
|
|
|
:REQUESTED_REVIEWERS: shubby
|
|
|
|
:END:
|
|
|
|
Describe the technical task.
|
|
|
|
**** MERGED technical task 2 :task:
|
|
|
|
CLOSED: [2018-08-30 Thu 12:54]
|
|
|
|
:PROPERTIES:
|
|
|
|
:BRANCH: tech-task-1
|
|
|
|
:ASSIGNEE: yogsototh
|
|
|
|
:REQUESTED_REVIEWERS: shubby
|
|
|
|
:END:
|
|
|
|
***** ACCEPTED Review finished
|
|
|
|
:PROPERTIES:
|
|
|
|
:REVIEWER: shubby
|
|
|
|
:END:
|
|
|
|
|
|
|
|
**** 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...
|
|
|
|
**** TODO add a new configuration value :task:ops:
|