PtBRGetting Started » History » Version 2
Antonio Albuquerque, 2025-02-24 23:15
| 1 | 1 | Antonio Albuquerque | h1. Primeiros passos |
|---|---|---|---|
| 2 | |||
| 3 | Este é um guia para os conceitos básicos do Redmine, escrito da perspectiva de um novo usuário. Vamos evitar as coisas sofisticadas por enquanto e apenas abordar a *criação de um projeto, trabalhar com Tarefas e o fluxo de trabalho básico*. |
||
| 4 | |||
| 5 | h2. Etapa um — Criando um projeto |
||
| 6 | |||
| 7 | 2 | Antonio Albuquerque | Antes de liberar sua equipe de desenvolvimento, você vai querer configurar um projeto para eles trabalharem. Isso pode ser feito como o usuário Admin (nome de usuário e senha são ambos "admin"). Clique em Projetos (canto superior esquerdo) e depois em Novo projeto (canto superior direito). Preencha todos os dados. Uma descrição de alguns dos campos pode ser encontrada "aqui":https://www.redmine.org/projects/redmine/wiki/RedmineProjectSettings. A única caixa que pode ser confusa é o Identificador do projeto — ele é usado internamente pelo Redmine (para URLs e outras coisas). |
| 8 | 1 | Antonio Albuquerque | |
| 9 | h2. Etapa dois — Obtenha alguns usuários |
||
| 10 | |||
| 11 | Você vai querer registrar alguns usuários, para que você possa atribuí-los ao projeto. Observe que, por padrão, você deve ativar os usuários manualmente. Então, depois que um usuário preencher a página de registro, você deve efetuar login como Admin, navegar até Administração:Usuários e definir o Filtro para Todos. Ative os usuários conforme necessário. |
||
| 12 | Uma vez ativo, você pode atribuir um usuário a um projeto. Ao fazer isso, você pode especificar uma ou mais funções que eles desempenham. As opções padrão para funções são: |
||
| 13 | |||
| 14 | 2 | Antonio Albuquerque | * Gerente |
| 15 | * Desenvolvedor |
||
| 16 | * Relator |
||
| 17 | 1 | Antonio Albuquerque | |
| 18 | Essas funções afetam o que cada usuário tem permissão para fazer em cada projeto. Deve-se observar que atribuir uma função afeta as permissões em duas áreas diferentes: |
||
| 19 | |||
| 20 | Primeiro, uma função afetará as permissões em todos os aspectos de um projeto. Por exemplo, a função Gerente permitirá que um usuário crie novos (sub)projetos, gerencie os Fóruns, o Wiki, o Repositório e qualquer outra coisa (em geral) dentro de um projeto. Por outro lado, a função Desenvolvedor não poderá editar o Projeto ou excluir mensagens dos Fóruns. |
||
| 21 | 2 | Antonio Albuquerque | Segundo, uma função afetará as permissões no Workflow. Em geral, uma nova Tarefa progride por vários estados, de New a In Progress, Resolvido e Fechado. Uma das principais diferenças entre Managers e Developers é que Managers podem Rejeitar Tarefas, mas Developers não. (Mais sobre isso abaixo na explicação do Workflow). |
| 22 | 1 | Antonio Albuquerque | |
| 23 | h2. Fluxos de trabalho... Você não consegue explicar isso! |
||
| 24 | |||
| 25 | Fluxos de trabalho ("Workflows") são como o Redmine rastreia Tarefas desde a criação até a conclusão. O Workflow padrão contém os seguintes estados: |
||
| 26 | |||
| 27 | 2 | Antonio Albuquerque | * New |
| 28 | * In Progress |
||
| 29 | * Resolvido |
||
| 30 | * Feedback |
||
| 31 | * Fechado |
||
| 32 | * Rejeitado |
||
| 33 | 1 | Antonio Albuquerque | |
| 34 | Por padrão, qualquer pessoa que esteja logada pode criar uma Tarefa (Bug ou Feature), mas somente Managers podem Rejeitá-los ou Reabrir uma Tarefa fechada. |
||
| 35 | |||
| 36 | |||
| 37 | h2. Resolvido vs Fechado? |
||
| 38 | |||
| 39 | Há muita discussão na Internet sobre isso, mas o consenso geral é que "Resolvido" significa que um desenvolvedor acha que corrigiu o bug, e "Fechado" significa que o relator original ou um Manager o aprovou. Muitos blogs falam sobre isso — tal como http://journal.sifterapp.com/blog/2011/07/resolved-vs-closed/. |