Development Guidelines

About

This page covers a set of guidelines and conventions for the development process and may be subject to changes.

Navigation:

• Development Process
• Conventions
• Github Guidelines

Development Process

Meetings

A stand-up meeting is held every week, along with the participation of our assigned TA. Each member has to state what they have done in the past week, and what issues they are facing. Moreover, the work plan for the next week will also be discussed in every lab meeting. At the end of the meeting, meaningful questions about the project are given to the TA.

In some circumstances, a member may require support for an issue they cannot resolve. If that is the case, some other members will be assigned to a work session and together help that member until the issue is resolved. If the issue is still not fixed, then all the members will work on it and consult the TA if needed. The meeting attendance will not be applied to the small work session.

Conventions of Git/GitHub Work Process

The development process will follow these steps:

1. Obtain the issue number from the project page.
2. From the develop branch, check out to the new branch with the naming convention issues/<your issue number>. For example, if your issue number is 25, then you need to check out a new branch named issues/25 from develop using git checkout -b issues/25.
3. While working on your issues branch, please make sure that you commit often using git pull and provide a concise commit message. Preferably, address your commit message using this format Added/Modified/Fixed <functionality, bugs> to <file name(s)> and describe more in the commit message.
4. Once the implementation is settled, push your work onto a new branch on Github, using git push origin <your branch name>.
5. Create a pull request to the remote develop with the name of the pull request that matches the issue title.
6. Give a brief description of the pull request (the template is right below).
7. Tag someone to review your code.
8. The reviewer will have to pull the branch, run and test the code, then request changes if problems are detected or approve it by commenting "Valid" to the pull request.
9. Merge and close your pull request. Don't forget to notify the team about the merge.
10. To the next issue we go!

Pull Request Template:

In this pull request, I have:

• Done
• Finished
• Fixed

Note:

• B is implemented using technology D.

Conventions

To ensure development process consolidation, some code conventions are adopted. These conventions may be subject to changes.

1. Order of declarations in a class.

• Documentation comment (Javadoc)
• Class statement
• Class variables. Order: public, protected, no access modifier, private
• Instance variable. Order: public, protected, no access modifier, private
• Constructors
• Methods

2. Avoid the use of deprecated features.

3. Avoid long lines of code that exceed the constraint line on the right. Don't be afraid to use newline if needed.

Javadoc

All the javadocs should be written right above the class/method implementation When documenting class, only @author should be used.

// Class documentation
/**
* "Class description"
* @author "name of the author - use the real name"
*/

When documenting methods, @param, @return, and @throws should be used.

// Class documentation
/**
* "Method description"
* @param x1 "description for x1"
* @param x2 "description for x2"
* @return res "description of res"
* @throws "under which circumstances that the exception is thrown" 
*/

Github guidelines

For each issue, there are status, type, label and milestones that we need to take into account.

Status

There are 5 types of status:

• Todo
• In progress
• Review Pending
• Under Review
• Done

Type

There are 2 types of issues:

• User story: The requirements are given out by users/owners
• Technical issues: All problems related to coding

Labels

By heading to the issues tab and clicking on the labels, the description of basic labels will be written right next to the labels. Some additional labels:

• Risk level: Indicate the number of activities, and other issues that will be related to this issue. The more activities related to it, the higher its risk level is. There are three risk levels: low, medium and high
• Size: Indicate the number of hours we need to spend to solve the issue. The harder an issue is to solve, the bigger the size is. There are 4 levels of size: 1, 3, 5, 8

Milestones

There are two milestones that we need to take into consideration in terms of completing issues of the project:

• Project Part 3: Half-way Checkpoint
• Project Part 4: Final Checkpoint