Home
A Uber é uma empresa Multinacional que apresenta serviços de transporte privado através de um aplicativo que permite a busca por motoristas baseada na localização, oferecendo um serviço semelhante ao tradicional táxi.
Travis Kalanick e Garrett Camp são os empreendedores e fundadores da Uber criada em 2009 com a ideia de um serviço semelhante a um táxi de luxo, oferecendo carros como Mercedes S550 e Escalade pela cidade de São Francisco na Califórnia Americana. O aplicativo foi lançado em 2010 para Android e iPhone.
A escolha do tema veio a torna por votação entre outros aplicativos e programas que eram o Discord, Steam e Google Agenda.
O grupo Uber é composto por 8 alunos da disciplina de Requisitos de Software do 2º Semestre de 2018. Sendo eles:
| Nome | Matrícula | GitHub |
|---|---|---|
| Davi Alves | 15/0122837 | @davialvb |
| João Lucas | 16/0009758 | @jlucassr |
| João Pedro | 16/0046602 | @jpmartins201 |
| João Vítor | 16/0010195 | @joaovitorml |
| Luciano Santos | 16/0013321 | @lucianosz7 |
| Renan Schadt | 16/0143403 | @renan601 |
| Rômulo Souza | 15/0147601 | @RomuloSouza |
| Victor Hugo | 16/0019401 | @victorhdcoelho |
Telegram foi o principal meio de contato dos membros do grupo, pelo aplicativo eram definidas separação de conteúdo de cada dinâmica, marcação de encontros presenciais e demais discussões envolvendo a disciplina.
Após o fim de cada aula, o grupo dividia o que fazer para a seguinte aula que era de dinâmica. Antes de cada dinâmica, o grupo se encontrava por volta das 12:00 no 2º do UED, para debater qual os melhores resultados que obtiveram com as práticas feitas antes em casa e apresenta-las.
Para contribuir com esse repositório deve-se seguir as seguinte regras:
- As issues tem que ser escritas no infinitivo em português claro. Exemplo:
- Fazer Richpicture de avaliação de Usuário.
- Toda issue tem que ter uma descrição clara do que tem que ser feito. Exemplo:
- Richpicture de Usuário terá as como finalizade estabelecer uma conexão do uber com o ...
- Toda dúvida, dificuldade e observação terão que ser feitas nas descrições da própria issue.
- Toda issue tem que ter uma label relacionada a o status da atividade.
- labels: A fazer | Fazendo | Feito.
- Toda issue tem que ser assinada por alguém ou ter alguma observação que ela estará no backlog para utilização futura.
- Toda issue terá que passar por revisão antes de ser aceita na master sendo que está será feito na branch desenvolvimento.
- Os commits devem ser feitos de forma sucinta descrevendo o que foi feito, portanto o commit deve ser atômico descrevendo a funcionalidade que foi implementada. Cada commit deve ser ligado a alguma issue aberta no repositório do projeto, logo é necessário iniciar o commit com uma hash indicando qual a issue que o commit está relacionada. mensagem deve seguir o seguinte padrão:
- Exemplo: "Criar argumentação do dia 28/07/2018".
- Para sua branch ser aceita terá que ter sido feita a revisão do português e do conteúdo, bem como a relevância do que está sendo aceito. Métricas como qualidade do conteúdo serão analisadas pela noção indivídual de quem for revisar. Analises como consistência do que está sendo escrito também será levado em conta, ou seja, não será aceito conteúdo que está com padrões dentro dele mesmo.
- Para que uma branch seja considerada válida terá que ter a seguinte estrutura < número_da_issue-nome-da-issue > sendo que o nome da issue será feita com o nome me minúsculo sendo que os espaços são substituídos por hífen.
- Exemplo: 22-fazer-rich-picture-usuario.
