# 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)


**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.


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


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.


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.


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


### Footer

A footer was added with the name of the project.


## 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;