Software Process
UVR software development follows an Agile Scrum methodology. This is to keep clear communication and to keep members motivated and on a timeline to finish their tasks. Development is broken up into 4-week long sprints, with stand-ups at the beginning of every subsystem or project meeting. During the stand-up, members will talk about what issues they’ve been working on and give an update on their progress. Leads will write everything in the meeting minutes and update OpenProject if the member hasn’t done so. After the stand-up, leads will show the sprint board and discuss the open issues and overall progress. After discussion ends, the software portion of the meeting is over.
For the first meeting of the sprint, there is about 30 minutes of discussion for new issue creation. Whenever a member takes on a a new task or issue, they will set a concrete goal and bring up anything that would block them from accomplishing it by the end of the sprint. If they think they can't complete the task with the 4 week window, the issue should be broken down more. For the last meeting, there is a retrospective. The retrospective includes member debriefs on the sprint and discuss issues that need to spill over into the next sprint.
During the sprint, each issue will go through the same process, as shown in the diagram below:
Yellow and light blue sections will be done by the leads while red and dark blue sections will be done by
members.
The red step (designing, developing and testing) is to be done by the member(s) assigned to the issue. Multiple people can collaborate in this step, and if members are stuck then they are encouraged to ask for help from the project lead, subsystem lead or other knowledgeable member on Discord. Once the issue has been tested, the assigned member can submit it by making a pull request. The issue can be moved to 'Developed' in the Github project board. Another member on the project will then review the issue and make suggestions. This review step is not necessary for small projects (less than 2 members). After all review suggestions are addressed, the reviewer can move the issue into 'Reviewed'. Finally, the leads can review the issue and merge the changes into main.
For software related tasks, everything will start in OpenProject and end in Github with a pull request. In this section, I will walk you through how to do these things for UVR. All tasks are first assigned in OpenProject so the lead can track your process at meetings. Once you have a task assigned to you, go to the Github and assign yourself to the same issue. After that, you can start committing. To do that, you will create a branch and start developing. Once you have finished that issue, you will create a pull request and fill out the devNote in the OpenProject.
The main things to look for are repositories, issues, and project boards. There is only 1 branch per issue.
The standards are similar to CAD naming. Rocket and non-rocket projects have one key difference: for non-rocket projects, the dash is missing between the subsystem and project name.
Rocket Issue:
Non-rocket Issue:
Branches are to be named almost exactly the same as issues, except branch names exclude the description at the end.
Example:
Issue name: X1-AV-1 Main loop error checking
→
Branch name: X1-AV-1
Pull requests are named exactly the same as the issue it originated from.
Sprint boards are to be maintained by project leads and subsystem leads.
The boards are broken down into 5 columns, which are shown in the
screenshot below:
- Todo → In Progress: If assigned member has created a branch for the issue
- In Progress → Developed: If the assigned member has created a pull request
- Developed → Reviewed: If the assigned member has addressed all of reviewer’s suggestions, then the reviewer should move issue to 'Reviewed’
- Reviewed → Done: If the lead has merged the change into the main branch (If it's an important feature, everyone should rebase after this step to get the change on their own branches.)
You can either read through this section or watch this video: Github Tutorial
Before starting to contribute, make sure you have a location to store all of your repositories on your local machine, in a place you will remember. Once you have created this folder, you can start contributing.
Start by going to
your terminal and navigating to the folder you use to store all your
UVR repositories. To do this, use the cd command. If you’re on
Windows, you can navigate to the folder in your file explorer and type
cmd (see figure below):
You can now clone the repository. To do this, you’ll need the url
which you can find on the repositories page by clicking on the green
button that says code.
Now in the terminal window you can run the command:
>git clone <repository url>
This will generate a local copy of the repository on your computer.
Now you can create your branch. Before you do, notice the name of the branch you're currently on. This is the master branch, and you will need to use this name in order to push your changes later.
Create Branch
> git checkout main> git pull> git checkout -b <branchname>
Committing
-
> git status(Tells you which files have been edited) -
> git add <filename>(You can add all files with a . instead of a filename) -
> git commit -m‘write your commit message’ -
> :wqto get out of vim mode
Creating a pull request
-
> git push -u origin <branchname>(Publish branch) - Go to Github and login to your profile
- Go to the repository you're committing to
- Click the green “Compare and pull request” button
Updating your branch
> git checkout main> git pull> git checkout <your branch name>-
> git pull origin main –-rebase(Always do this before you start working on a issue, or when your project lead tells you to.)