---
# System prepended metadata

title: Sprint 1

---

# Sprint 1

**Structure for standard commits** - Defining the structure of our commits for this project.

**Structure for standard branches** - Defining the structure of our branches for this project.

**Structure for standard Merge Requests** - Defining the structure of our merge requests fot this project.

**Git Flow and Procedure (step by step)** - Example on how we will organize branches and merges. And how to aply these structures.

**Structure for the changelog** - ...

**What is New** - Project new features and updates.

**Sprint Restrospective** - Action points and what the team should keep, start and stop doing.



## Structure for standard commits
**Summary:**

**[Type] Title
Description (When applicable)**



**Type**:
- *feat*: a new feature
- *fix*: a bug fix
- *docs*: changes to documentation
- *style*: formatting, missing semi colons, etc; no code change
- *refactor*: refactoring production code
- *test*: adding tests, refactoring test; no production code change
- *devops*: updating build tasks, package manager configs, etc; no production code change

**Title**: Small description of the commit, be as concise as possible.

**Description**: 
1. *First paragraph*: Explain what this commit solves
2. *<break line>*
3. *Second Paragraph*: Explain How it accomplishes it. Use bullet points if it becomes to bulky. ++Don’t forget++ to add the issue number at the bottom if need be.

**Example**

**Summary:** [fix] Scrapper getting images url
**Description:** The scrapper was not getting the url of the image it was fetching.

Fixed the image url by adding the correct html tag, which is &lt;img&gt; and doing
the necessary for loop to loop through all &lt;img&gt; tags.
Solves: #29




## Structure for standard branches

**Name:** 

**TYPE/Title**

Depending on what the created branch will do, the **[TYPE]** can be:
- *US#00*: a new US will be implemented.
- *Fix*: a bug fix.
- *Docs*: changes to documentation.
- *Refactor*: formatting, missing semi colons, etc; no code change. Or refactoring production code.
- *Test*: adding tests, refactoring test; no production code change.
- *Devops*: updating build tasks, package manager configs, etc; no production code change.

The **Title** must be a compact summary of the implementation.

**Examples**
1. US#99/Add_animation_to_CO2_card
2. FIX/Animation_water_buggy
3. DOCS/Updating_readme_and_changelog
4. TEST/Increasing_coverage_backend



## Structure for standard Merge Requests

**Name:** 

**[TYPE] Title**
The merge request **[TYPE]** can be:
- *US#00*: The US was implemented.
- *Fix*: a bug was fixed.
- *Docs*: changed the documentation.
- *Refactor*: formatted, corrected missing semi colons, etc; no code change. Or refactored production code.
- *Test*: added tests, refactored tests; no production code change.
- *Devops*: updated build tasks, package manager configs, etc; no production code change.


**Description:**
A compact summary of the what was implemented.

**Checklist**

- [ ] I have written test for my code and it has been tested
- [ ] All existing tests have been passed
- [ ] I have attached a screenshot/video to visualize my change if possible
- [ ] My code follows the project code style

**Example**
1. [US#99] Add animation to CO2 card.

- [x] I have written test for my code and it has been tested
- [x] All existing tests have been passed
- [ ] I have attached a screenshot/video to visualize my change if possible
- [ ] My code follows the project code style


## Git Flow and Procedure (step by step)

![](https://i.imgur.com/WOEfInP.png)

**Step By Step**

1. Move card from board “Sprint” to board “Doing”;
2. Assign cards to respective group member that will implement it;
3. Create new branch from up-to-date master branch;
4. Constantly make commits, don't accumulate too much code for each commit; (If pair programming is implemented, add the contributor);
5. Until the merge request, keep merging with the up-to-date master, by doing this it will have less conflicts in the end;
6. Before the merge request to the master branch confirm that the current branch is ready for production;
7. Merge feature master (Gitlab);
8. Change card from doing to "In review";
9. Describe Merge Request;
10. Wait for at least two people to approve the merge request;
11. Change from "In review" to "Done";
12. Update "changelog.md" and "what’s new".

## Structure for the changelog
**Summary:**

**[Type] Description**

**Type**:
- *added*: added a new feature
- *fixed*: a bug fix
- *removed*: removed a feature
- *changed*: changed a feature

**Description**: Very short description on what was changed

## What is New

In this section you will find the project new features and updates. Some of the key highlights include:

- [**Interactive Navbar**](#Interactive-Navbar) - Navbar dropdown and it is now possible to go back once interacting with cards.

- [**CO2 Card**](#CO2-Card) - Static animation in home-page for the CO2 metric.

- [**CO2 Page**](#CO2-Page) - Specific page for CO2 metric, including a graph.

- [**Footer**](#Footer) - Added a footer.

### Interactive Navbar

The navbar has been updated, now it displays several years that we will take into account in the future. Also, it has a fully working home button.

![](https://i.imgur.com/g7GoZMN.png)

It was added a dropdown which shows various options to filter the homepage in future updates.


![](https://i.imgur.com/HFVsHNB.png)

This will be usefull to filter the homepage and card pages to give information about a specific country.

### CO2 Card

We implemented the first metric card, CO2. Now it is possible to see information about the present worldwide levels of CO2 in the home-page.

![](https://i.imgur.com/aTr1zgd.png)

As you can see there is a ball of "smoke" that represents the CO2 emissions, it gets bigger when the concentration increases.

### CO2 Page

The specific page for CO2 is now available, once the CO2 card is clicked the page is rerendered and expanded to show only information about the metric.

![](https://i.imgur.com/yejEuZN.png)

In this page it is also possible to see a graph that represents the evolution of the concentration over the years.

![](https://i.imgur.com/T9epWqb.png)

### Footer

A footer was added with the name of the project.

![](https://i.imgur.com/F3gVrck.png)

## Sprint Retrospective

### Keep
- Communicating as a team to help each other;
- The "small teams" and the organizers for each one of them;
- Working as teams focused on each of the architecture layers of this project;
- Being proactive on new ideas;

### Start
- Better communication between backend and frontend;
- Notifying the team each time a push is made;
- Organize better the branches;
- Commenting more the code (not useless comments);
- Following the features and designs even more specified at the begging of the sprint;
- Communicating and working even more as a team;
- Communicating more between workgroups;
- Following the git flow more strictly;

### Stop
- Developing code that s not within the React.js structure;
- Wating time with features that aren't specified for the current spring;
- Only working in one end of the project;

### Action Points
- Prepare, plan well and attend;
- It may not always happen but get the correct people in the meetings;
- Talk about what you did. And in the case you didn't do anything ask for help in the next sprint;
- Always have an opinion;
- Think and act like a team;
- Work effectively;