Skip to content

Commit

Permalink
Initial commit
Browse files Browse the repository at this point in the history
  • Loading branch information
github-classroom[bot] authored Feb 27, 2024
0 parents commit a4ca407
Show file tree
Hide file tree
Showing 25 changed files with 679 additions and 0 deletions.
1 change: 1 addition & 0 deletions .github/CODEOWNERS
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
* @BrightCoders-Institute/playbook-admin @BrightCoders-Institute/mentores-rn @BrightCoders-Institute/mentores-ror
17 changes: 17 additions & 0 deletions .github/ISSUE_TEMPLATE/brightcoders-issue-template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
---
name: BrightCoders Issue Template
about: BrightCoders standard issue template
title: ''
labels: ''
assignees: ''

---

## REQUIREMENTS / DESCRIPTION

> Write a detailed description for this issue, provide all necessary information so any member of the project understands.
Yo could use the following template: As a `<type of user>`, I want `<some goal>` so that `<some reason>`
## DESIGN

> Provide references to images of the design, how it looks now, and how it should look like.
28 changes: 28 additions & 0 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
# Description

What did you implemented/Why did you implemented this:

- Explain the changes you’ve made.
- It doesn’t need to be fancy and you don’t have to get to technical, yet.
- Just explicit what you have implemented at a high level.
- Let the reviewer know the overall effect of the PR.
- Reference a ticket in your issue tracker. Explain what the change is and then and only then reference the ticket.
- The “why” is a chance to explain both the engineering goal, but also a some business objective that is satisfied or moved along.

Examples:

- What?: I've added support for authentication to implement Key Result 2 of OKR1. It includes
model, table, controller and test. For more background, see ticket #JIRA-123.
- Why?: These changes complete the user login and account creation experience. See #JIRA-123 for more information.

## Testing

Help me how can I test or look at the changes

Example:

- I've added coverage for testing all new methods. I used Faker for a few random user emails and names.

## Screenshots

If applicable, include screenshots of the results or screenshots that help to see changes
31 changes: 31 additions & 0 deletions .github/workflows/reek.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
name: Reek

on:
push:
branches: [main]
pull_request:
branches: [main]

jobs:
reek_analysis:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2

- name: Set up Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: 3.1

- name: Install dependencies
run: gem install reek

- name: Run Reek
run: |
set -e
reek
if [ $? -ne 0 ]; then
echo "Reek analysis failed"
exit 1
fi
25 changes: 25 additions & 0 deletions .github/workflows/rubocop.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
name: RuboCop

on:
push:
branches: [main]
pull_request:
branches: [main]

jobs:
rubocop:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2

- name: Set up Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: 3.1

- name: Install dependencies
run: gem install rubocop

- name: Run RuboCop
run: rubocop --format simple --fail-level error
31 changes: 31 additions & 0 deletions .github/workflows/rubycritic.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
name: RubyCritic

on:
push:
branches: [main]
pull_request:
branches: [main]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
rubycritic:
# The type of runner that the job will run on
runs-on: ubuntu-latest

# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- uses: docker://ruby:3.1-slim

- name: Install rubycritic
run: sudo gem install rubycritic

# Runs RubyCritic App
- name: RubyCritic App
run: mkdir -p tmp/rubycritic && rubycritic --no-browser -p tmp/rubycritic/rubycritic-app -s 90 app config lib

# Runs RubyCritic on Tests
- name: RubyCritic on Tests
run: mkdir -p tmp/rubycritic && rubycritic --no-browser -p tmp/rubycritic/rubycritic-app -s 65 spec test
17 changes: 17 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
![BrightCoders Logo](img/logo.png)

# Proyecto final

> [Ver instrucciones antes de iniciar](./instructions/instructions.md)
This README would normally document whatever steps are necessary to get the application up and running.

Things you may want to cover:

- Title or Project Name
- Table of contents
- Description. A brief description of what the project is about
- How to Install and Run the Project.
- How to Use the Project.
- Credits
- Badges
Binary file added img/logo.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
94 changes: 94 additions & 0 deletions instructions/agile.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
![BrightCoders Logo](../img/logo.png)

- [01 Creación del proyecto](#01-creación-del-proyecto)
- [02 Ceremonia de planeación del sprint](#02-ceremonia-de-planeación-del-sprint)
- [Definición del líder](#definición-del-líder)
- [Definición de los objetivos del sprint](#definición-de-los-objetivos-del-sprint)
- [Creación de las issues](#creación-de-las-issues)
- [Organización de las tareas del sprint](#organización-de-las-tareas-del-sprint)
- [Definición de Milestone y Sprint](#definición-de-milestone-y-sprint)
- [03 Flujo de trabajo](#03-flujo-de-trabajo)
- [Asignación de tareas](#asignación-de-tareas)
- [Desarrollo de tareas](#desarrollo-de-tareas)
- [Revisión de código](#revisión-de-código)
- [Administración del Planner](#administración-del-planner)
- [04 Demo o presentación de avances](#04-demo-o-presentación-de-avances)

# Desarrollo ágil

En este proyecto vamos a utilizar un flujo de trabajo ágil basado en Scrum. Para ello vamos a utilizar la herramienta GitHub Projects.

# 01 Creación del proyecto

Antes de iniciar es necesario que cada equipo cree un proyecto en GitHub y lo configure para que funcione como un tablero Kanban como se explica en esta [guía](project-planner.md).

# 02 Ceremonia de planeación del sprint

## Definición del líder

1. Todos los lunes al inicio de la sesión de trabajo los equipos se reunirán para planear el sprint de la semana.
2. Al inicio de la reunión, cada equipo nombrará a un `líder del sprint`, cada sprint ser nombrará un líder diferente, de tal forma que a todos en algún momento les toque ser líderes.
3. El líder del sprint será el encargado de dirigir la reunión y de asegurarse que se cumplan los tiempos.

## Definición de los objetivos del sprint

1. La primer tarea del equipo consiste en definir el o los objetivos del sprint, estos objetivos deben ser claros y medibles.Por ejemplo, si el objetivo es desarrollar la funcionalidad de registro de usuarios, entonces el objetivo debe ser algo como: `Al finalizar el sprint el usuario debe poder registrarse en la aplicación utilizando su correo y una contraseña.`
2. Los objetivos del sprint se deben registrar como `milestones` en GitHub, como se explica en [esta guía.](milestones.md)

## Creación de las issues

1. Una vez que se definieron los objetivos del sprint, las `issues ó tareas` que sean necesarias para lograr los objetivos del sprint. Por ejemplo, si el objetivo es desarrollar la funcionalidad de registro de usuarios, entonces las issues podrían ser: `Crear pantalla de registro`, `Crear formulario de registro`, `Crear validaciones de formulario`, etc.
2. Para registrar las tareas sigan las instrucciones de [esta guía.](issues.md)
3. No es necesario crear demasiadas tareas, lo ideal es tener las suficientes para trabajar durante el sprint.

## Organización de las tareas del sprint

1. Una vez que se han creado las issues, es necesario organizarlas en el tablero Kanban, para ello es necesario ir a la pestaña `Projects` del repositorio y seleccionar el proyecto que se creó en el paso 1.
2. Una vez en el planner seleccionar la pestaña `Planning`
3. Todas las tareas `nuevas` que se acaban de generar deberán estar con el status `Backlog`
4. Las primeras tareas que se como parte del trabajo del nuevo sprint son las que se encuentren en las columnas `In Progress` y `In Review`. Es decir, las tareas que no se terminaron en el sprint anterior. Para esto,
5. Dependiendo su capacidad, el equipo decidirá si toma tareas del `backlog` y las agrega a la columna `Planned` para ser consideradas en el sprint actual.

## Definición de Milestone y Sprint

1. Todas las tareas que están consideradas para el sprint actual deben actualizarse los campos `Milestone` y `Sprint` con el nombre del milestone y el sprint actual.

Una vez concluido esto, la planeación de tareas para el siguiente sprint ha concluido y el equipo puede iniciar a trabajar en las tareas del sprint actual.

# 03 Flujo de trabajo

## Asignación de tareas

1. Las primeras tareas que se empezarán a trabajar son aquellas que ya se encuentran en las columnas `In Progress` y `In Review`. Es decir, las tareas que no se terminaron en el sprint anterior.
2. **Por ningún motivo un integrante del equipo puede tener en un mismo tiempo 2 o más tareas en la columna `In Progress`**. Aunque si puede tener una o más en `In Review`.
3. **Las tareas que están en la columna `Planned` NO DEBEN ESTAR ASIGNADAS**
4. Para iniciar una nueva tarea el o los integrantes que la van a trabajar la tomarán de la columna `Planned` y la arrastrarán a la columna `In Progress` y se asignarán a la tarea. Es decir, en el campo assignees deberá aparecer su nombre.

## Desarrollo de tareas

1. Antes de iniciar a codificar la tarea, se deberá a crear la rama en donde se estará trabajando.
2. Cada tarea deberá tener su propia rama 1 rama por tarea y 1 tarea por rama.
3. Todas las ramas deberán de originarse desde la rama principal `main`.
4. El nombre de las ramas deberá seguir la siguiente estructura: `sprint-<numero_sprint>/issue-<numero_issue>#<Titulo>`. Por ejemplo, si la tarea es la número 1 del sprint 1 y el título es `Crear pantalla de registro`, entonces el nombre de la rama sería: `sprint-1/issue-1#Crear pantalla de registro`. **El `número del issue` es el que aparece en la parte superior izquierda de la pantalla de la issue y que Github genera automáticamente.**
5. Una vez que se ha creado la rama, se moverán a ella y comenzarán a trabajar en la tarea haciendo commits significativos.

## Revisión de código

1. Una vez que se termina de codificar la tarea se realizará un `pull request` a la rama `main`.
2. El pull request deberá tener el nombre de la tarea y el número de la issue. Por ejemplo: `Crear pantalla de registro #1` y deberá tener una descripción que explique que es lo que se hizo. En el caso de que se hubiera desarrollado parte de la interfaz, se deberá agregar una captura de pantalla de la interfaz.
3. Se copiará la URL del pull request y se pegará en el canal #ruby-pr ó #react-pr del Slack.
4. En el canal del Slack se deberá pedir que revisen el código y que dejen sus comentarios en el pull request.
5. En el `Project Planner` se deberá mover la tarea a la columna `In Review` y si se quiere solicitar la revisión de alguien en particular se puede indicar en el campo `Requested Reviewers`.
6. Cualquier participante que no sea autor de la tarea puede revisar el código y dejar sus comentarios en el pull request. Puede ser de cualquier equipo.
7. Para que puedan avanzar en el proyecto es muy importante que todos participen en la revisión de código de sus compañeros pues para que se considere como concluida una tarea es necesario que al menos 2 personas hayan revisado el código y hayan dejado sus comentarios.
8. Mientras la tarea se encuentre en revisión, el autor de la tarea puede continuar trabajando en otra tarea.

## Administración del Planner

1. El `Líder del Sprint` será el responsable de asegurar que el planner se encuentre actualizado.
2. Todos los días deberá revisar el planner y asegurarse que las tareas se encuentren en la columna correcta y que cumplen con los campos y criterios antes señalados.

# 04 Demo o presentación de avances

1. Dependiendo de lo acordado con cada mentor o instructor, se deberá realizar una demo o presentación de avances al final de cada sprint.
2. La presentación podría ser el viernes de cada semana o el lunes de la siguiente semana.
Binary file added instructions/img/01.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/02.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/03.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/04.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/05.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/06.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/07.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/08.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/09.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/10.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added instructions/img/11.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading

0 comments on commit a4ca407

Please sign in to comment.