Nogo apps workflow documentation.
We use a method similar to kanban with consists in 3 standarts:
- Comunication.
- Organization.
- Version control.
- brainstorm_10min: Weekly meeting with github projects, github issues and codacy in 10min.
- Issues with label "stuck"
- Sprints
- Next features
- change_request: If you want ask for a change in the project about something in progress.
- general: general subjects.
- github: Integration with github.
- reviews_codacy: New reviews from codacy.
- visitors_slaask: Chat room to visitors of our website.
- Cards
- You can use projects to create a workflow and organize the tasks and the team in notes.
- Every task have to be possible done in more of 2 hours and less the 6 hours if not, split or paste some tasks in one task.
- Can go just forward(pulled to next column) and all the columns can have just 6 tasks at once.
- Every card title needs to have the current date.
- We goal is min of 6 tasks weekly.
- Every friday we clean the column done.
- Every time i change a card of column to another column i have to change the date to the current.
- Issues
- Every note you create have to be convert in an issue when you put in the column "To do" and completed the data.
- The issue data is assign(person responsible), milestone(stage of the project), label(type) and description.
- Stuck label is some task is static more than 3 days in the same column or something was not approved in the review, what gets priority and the team discuss in slack. When you solve the issue stucked change label stuck to priority.
- New, replace, bug and priority are the others types.
- Every issue have to become a commit in your branch.
- We can see in pulse and graphs informations about our issues and pulls.
- When you make a review in an issue you can use the emoji "like" or "dislike"(this needs a comment) to symbolize what you think and can comment along the updates of the issue.
- When we delete issues on friday from the column "done", we need to close them.
- Backlog: Here we discussed our ideas, difficulties and plans. One times a week we make the brainstorm meeting.
- To do: Here we have all the approved tasks(issues) to do with descriptions, labels, assigns and milestone.
- Doing(testing): Here shows what is in progress.
- Done: The task is finished and now can wait for review.
- Review(testing): Here analyze the code when receive a pull request and make coments at lines, create a review and discuss about changes, request changes or approve with a like icon. When the review is complete close the issue and erase the issue of the column.
Work in your branch and just when your work is done try a pull request, every pull request needs a description explain whats change and why.
Ex:
- What is changed?
Text example, text example, Text example, text example, Text example, text example, Text example, text example, Text example, text example.
- Why?
Text example, text example, Text example, text example, Text example, text example, Text example, text example, Text example, text example.
The review needs to be done at 3 levels:
- Receive a pull request.
- Codacy test.
- Build test and UI test.
- Comparation test with git or github.
- To approve(change to column done) or disapprove(add label "stuck").
More details:
- Column "doing" and "review" need make these tests.
- The person who make the review can't be the same who did the code.
- The code works?
- The code is clean?
- The the code is encapsuled and OO?
- The code respect design patterns, material design and android conventions?
- There is something redundant or unnecessary?
- The project is modulate with loose coupling?
- All the methods and variables are commented or with explicit scope.
- Some log or debug is unnecessary?
- If the project needs some import in gradle, virtual machine and etc... the whole team needs be informed and create a documentation.
- The code comented was removed?
- The build works?
- The UI is working in all devices that should?
- The codacy see some problem in your code that needs to be fixed?
The codacy make some automatic reviews and give us a better look in the code and Travis integration make the build online.
You can to analyze in local git the diferences with the cheats below this topic and on github(priority) when create a pull request. Make the review on github is the best way to create a public review. You can make comments at lines of the code, only use git if you need an analyzes deeper. Don't forget make always a pull to local repository after the push. To you update the remote master before you update the local master.
- git diff (show the changes)
- git diff HEAD
- git diff --word-diff(show just the changes and not the all line)
- git diff --staged(show the changes in stage area)
- git --stat(show just the files changed)
- git checkout(change branchs)
- git log(show commits from autors with dates)
- git log --oneline(show just the descriptions of commits)
- git log --stat(see the files that changes too)
- If you have a repository inside your repository.
- If you don't have access to the key of the repository.
- If the remote repository have changes to pull.
- If you are try to push to master instead your branch.