Software Público Brasileiro

Em 6 de março de 2015 11:45, Marisa Souza escreveu:

> *Oi Paulo, tudo bem?*
>

Oi Marisa,

> Tivemos uma reunião com o pessoal do GSAN que demonstrou bastante
> interesse em utilizar o gerenciamento dos requisitos do gsan, mas eles
> querem algo para gestão de requisitos de negócio que vá descendo ate as
> issues de desenvolvimento.
>

Certo.

> Mostrei este link que você mandou do noosfero. Na verdade gostaríamos de
> conhecer um pouco mais as issues do gitlab para mostrar como eles podem
> trabalhar, porque eles estão muito inclinados a usar um redmine externo e
> isso não é bom pro projeto.
>

"Pessoas são mais importantes que ferramentas": acho que vocês devem fugir
um pouco da discussão das ferramentas. Eles devem saber o que eles quem e
como irão fazer tal mapeamento, a ferramenta vem depois para suportar isso.

Eu, falando apenas por mim, consigo e prefiro fazer tudo com issues,
atribuindo labels e milestones. Por outro lado, falando do nosso projeto,
por exemplo, o Hilmer prefere o Redmine, porque repositório nunca fez parte
do dia-a-dia dele, além dele estar interessando em automatizar coleta de
dados internamente.

Entretanto, o observe que apenas depois de mais de um ano com o projeto é
que o nosso redmine está sendo usando com uma certa maturidade, mas ainda
sem o nĩvel de automatização idealizado. No Participa.br, temos o Poppi e o
Ronald fazendo a gestão completa no GitLab, resolvendo a vida deles.

Não acredito que o "problema" ou a "solução" seja a ferramenta. Acho que
antes do Gsan instalar um Redmine próprio, causando um grande overhead para
eles, devem observar se conseguem organizar issues (requisitos, caso de
uso, histórias, tarefas ou o que for) de forma "simples". O beta do SPB
dará essa oportunidade para eles sentirem isso. Usando Redmine ou GitLab
eles terão que aprender ao longo do tempo, organizando da melhor forma para
eles.

Em suma, por mim, essa discussão passa entre o "bom" e o "ótimo". Agora
temos o "bom", mas querem o "ótimo", sendo que o "ótimo é inimigo do bom".

> Sabe dizer se as issues do gitlab tem como fazer o que eles querem?
>

Eu consigo fazer o que eles querem, mas observe que eu não consigo ainda
convencer o Hilmer, que está ao meu lado, 100% quanto a isso.

O custo-benefício de usar o GitLab para essa gestão é bem melhor que ter um
Redmine a parte para isso. Eu não tenho dúvidas.

> Tem alguém que pode nos ajudar nisso?
>

Eu mesmo, mas qual a prioridade disso? O esforço vale a pena? eles estão
minimamente dispostos a aprenderem/experimentarem/se adaptarem 'as
alternativas?

Se for apenas para você ter mais segurança nos argumentos, de maneira
geral, podemos tentar que marcar um dia no CDTC ou no LAPPIS para
simularmos algo. Quem sabe, aproveito e eu migro parte do o que está em
nosso redmine para o gitlab, como "estudo de uso".

>
> O redmine já foi descartado mesmo ou ainda há uma possibilidade?
>

Essa avaliação só será possível na release 5, não posso falar que está
descartado. Veremos quais serão as prioridades com o MP. O que estamos
fazendo é um ambiente de desenvolvimento colaborativo. Faremos uma análise
técnica, independente de gostos pessoais, se o Redmine agregará ao ambiente.

De toda forma, eu tenho a minha opinião pessoal. Eu acho que não será
necessário um Redmine a nova plataforma do SPB, mas isso será discutido no
segundo semeste de 2015. Por isso o que eu falar agora considere apenas com
pura especulação (e não um encaminhamento do projeto):

Tecnicamente, o Redmine atende bem um, e apenas um, grupo de projetos que
estão sob o mesmo direcionamento e mecanismo de gestão. Por exemplo, o
Redmine da DTI atende bem a DTI porque foi organizado para ser assim; O
Redmine do LAPPIS para o LAPPIS; assim por diante. No caso do SPB, não será
assim. Para mim, o Redmine não atende, no momento, a pluralidade dos
projetos do SPB, cada um com suas particularidades. Em outras palavras,
para o Redmine atender devidamente as expectativas de todos do SPB, o
investimento nele será grande.

Por fim, também não acho que devemos se fazer pensar que a plataforma
resolverá os problemas e desejos de todos. As pessoas/projetos _também_
podem se adaptar para tirarem o melhor proveito de algo que está na mão
deles sem custo/tempo algum.

meus 2 cents,
--
Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

A gente tem discutido muito isso no Interlegis e chegamos a um acordo de
que uma ferramenta como o GitHub ou GitLab + um quadro de Kanban como o
waffle.io, integrados no Colab, resolveria muito bem o problema de
organização e gerenciamento, deixando o processo super simples e ágil.

https://waffle.io/plonegovbr/brasil.gov.portal

Abraço,

Jean Ferri


On 06-03-2015 19:45, Paulo Meirelles wrote:

> Em 6 de março de 2015 11:45, Marisa Souza escreveu:
>
>> *Oi Paulo, tudo bem?*
>>
>
> Oi Marisa,
>
>
>> Tivemos uma reunião com o pessoal do GSAN que demonstrou bastante
>> interesse em utilizar o gerenciamento dos requisitos do gsan, mas eles
>> querem algo para gestão de requisitos de negócio que vá descendo ate as
>> issues de desenvolvimento.
>>
>
> Certo.
>
>
>> Mostrei este link que você mandou do noosfero. Na verdade gostaríamos de
>> conhecer um pouco mais as issues do gitlab para mostrar como eles podem
>> trabalhar, porque eles estão muito inclinados a usar um redmine externo e
>> isso não é bom pro projeto.
>>
>
> "Pessoas são mais importantes que ferramentas": acho que vocês devem fugir
> um pouco da discussão das ferramentas. Eles devem saber o que eles quem e
> como irão fazer tal mapeamento, a ferramenta vem depois para suportar isso.
>
> Eu, falando apenas por mim, consigo e prefiro fazer tudo com issues,
> atribuindo labels e milestones. Por outro lado, falando do nosso projeto,
> por exemplo, o Hilmer prefere o Redmine, porque repositório nunca fez parte
> do dia-a-dia dele, além dele estar interessando em automatizar coleta de
> dados internamente.
>
> Entretanto, o observe que apenas depois de mais de um ano com o projeto é
> que o nosso redmine está sendo usando com uma certa maturidade, mas ainda
> sem o nĩvel de automatização idealizado. No Participa.br, temos o Poppi e o
> Ronald fazendo a gestão completa no GitLab, resolvendo a vida deles.
>
> Não acredito que o "problema" ou a "solução" seja a ferramenta. Acho que
> antes do Gsan instalar um Redmine próprio, causando um grande overhead para
> eles, devem observar se conseguem organizar issues (requisitos, caso de
> uso, histórias, tarefas ou o que for) de forma "simples". O beta do SPB
> dará essa oportunidade para eles sentirem isso. Usando Redmine ou GitLab
> eles terão que aprender ao longo do tempo, organizando da melhor forma para
> eles.
>
> Em suma, por mim, essa discussão passa entre o "bom" e o "ótimo". Agora
> temos o "bom", mas querem o "ótimo", sendo que o "ótimo é inimigo do bom".
>
>
>> Sabe dizer se as issues do gitlab tem como fazer o que eles querem?
>>
>
> Eu consigo fazer o que eles querem, mas observe que eu não consigo ainda
> convencer o Hilmer, que está ao meu lado, 100% quanto a isso.
>
> O custo-benefício de usar o GitLab para essa gestão é bem melhor que ter um
> Redmine a parte para isso. Eu não tenho dúvidas.
>
>
>> Tem alguém que pode nos ajudar nisso?
>>
>
> Eu mesmo, mas qual a prioridade disso? O esforço vale a pena? eles estão
> minimamente dispostos a aprenderem/experimentarem/se adaptarem 'as
> alternativas?
>
> Se for apenas para você ter mais segurança nos argumentos, de maneira
> geral, podemos tentar que marcar um dia no CDTC ou no LAPPIS para
> simularmos algo. Quem sabe, aproveito e eu migro parte do o que está em
> nosso redmine para o gitlab, como "estudo de uso".
>
>
>>
>> O redmine já foi descartado mesmo ou ainda há uma possibilidade?
>>
>
> Essa avaliação só será possível na release 5, não posso falar que está
> descartado. Veremos quais serão as prioridades com o MP. O que estamos
> fazendo é um ambiente de desenvolvimento colaborativo. Faremos uma análise
> técnica, independente de gostos pessoais, se o Redmine agregará ao ambiente.
>
> De toda forma, eu tenho a minha opinião pessoal. Eu acho que não será
> necessário um Redmine a nova plataforma do SPB, mas isso será discutido no
> segundo semeste de 2015. Por isso o que eu falar agora considere apenas com
> pura especulação (e não um encaminhamento do projeto):
>
> Tecnicamente, o Redmine atende bem um, e apenas um, grupo de projetos que
> estão sob o mesmo direcionamento e mecanismo de gestão. Por exemplo, o
> Redmine da DTI atende bem a DTI porque foi organizado para ser assim; O
> Redmine do LAPPIS para o LAPPIS; assim por diante. No caso do SPB, não será
> assim. Para mim, o Redmine não atende, no momento, a pluralidade dos
> projetos do SPB, cada um com suas particularidades. Em outras palavras,
> para o Redmine atender devidamente as expectativas de todos do SPB, o
> investimento nele será grande.
>
> Por fim, também não acho que devemos se fazer pensar que a plataforma
> resolverá os problemas e desejos de todos. As pessoas/projetos _também_
> podem se adaptar para tirarem o melhor proveito de algo que está na mão
> deles sem custo/tempo algum.
>
> meus 2 cents,

Em 6 de março de 2015 20:15, Jean Rodrigo Ferri

> escreveu:

> A gente tem discutido muito isso no Interlegis e chegamos a um acordo de
> que uma ferramenta como o GitHub ou GitLab + um quadro de Kanban como o
> waffle.io, integrados no Colab, resolveria muito bem o problema de
> organização e gerenciamento, deixando o processo super simples e ágil.
>
>https://waffle.io/plonegovbr/brasil.gov.portal
>

Oi Jean,

Vocês do Interlegis sempre estão a frente nas discussões e soluções =)

Conversamos isso com o Sergio quando ele nos mostrou o waffle. Concordo que
esse é o caminho mesmo.

Para uma integração de um Kanban com o Colab temos que achar uma
alternativa livre ao waffle, pois ele é fechado e apenas funciona com
GitHub, confere?

Termos algo desse tipo no Colab é algo que temos que pensar juntos ;)

obrigado,
--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

*Oi Jean,*
Obrigada pelas contribuições. Muito legal mesmo :-) Parabéns por mais essa
iniciativa. É mais uma opção para avaliarmos.


*Oi Paulo,*
Antes de enviar este e-mail nós escutamos a Joelma justamente para trazer
uma melhor visão do problema para nossa discussão. Nós entendemos e
compartilhamos a necessidade de focar no processo, mas a percepção de qual
a melhor ferramenta é muito pessoal, veja seu exemplo e o do Hilmer... A
Joelma nos questionou algo que nós mesmo havíamos prometido: o redmime.

Acredito que nossa tentativa é justamente mostrar pra ela que é possível
fazer com o Gitlab, por isso pedi apoio no sentido de entendermos melhor a
ferramenta para tentar convencê-la já que não temos expectativas concretas
quanto ao uso do redmine ou qualquer outra ferramenta que a "substitua".
Entenda substituir no sentido de dar respostas de negócio que talvez o
gitlab não dê na forma como ela espera...

Nós aceitamos o convite de conversar sobre isso no CDTC, acho que ajudará
bastante. A sugestão de sermos um estudo é uma ótima ideia, só tem a
observação de que nós também usamos o redmine né? rsrsrs

Podemos agendar pro dia que for melhor pra você.

Marisa Souza

Analista em Tecnologia da Informação
Coordenação Geral de Sistemas de Informação - DGSI/MPOG

Em 7 de março de 2015 07:38, Paulo Meirelles

escreveu:

> Em 6 de março de 2015 20:15, Jean Rodrigo Ferri <
> jeanferri@interlegis.gov.br> escreveu:
>
>> A gente tem discutido muito isso no Interlegis e chegamos a um acordo de
>> que uma ferramenta como o GitHub ou GitLab + um quadro de Kanban como o
>> waffle.io, integrados no Colab, resolveria muito bem o problema de
>> organização e gerenciamento, deixando o processo super simples e ágil.
>>
>>https://waffle.io/plonegovbr/brasil.gov.portal
>>
>
> Oi Jean,
>
> Vocês do Interlegis sempre estão a frente nas discussões e soluções =)
>
> Conversamos isso com o Sergio quando ele nos mostrou o waffle. Concordo
> que esse é o caminho mesmo.
>
> Para uma integração de um Kanban com o Colab temos que achar uma
> alternativa livre ao waffle, pois ele é fechado e apenas funciona com
> GitHub, confere?
>
> Termos algo desse tipo no Colab é algo que temos que pensar juntos ;)
>
> obrigado,
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Aproveitando a deixa para fazer um parenteses: eu sou a favor de deixarmos
o Redmine e trabalharmos com as issues do Gitlab.
Sei que como toda mudança isso vai demandar um certo esforço mas eu
gostaria de colocar isso na mesa após o R3.

--
Sergio Oliveira

"The brick walls are not there to keep us out; the brick walls are there to
give us a chance to show how badly we want something."
Randy Pausch

2015-03-09 13:12 GMT-03:00 Marisa Souza :

>
> *Oi Jean,*
> Obrigada pelas contribuições. Muito legal mesmo :-) Parabéns por mais essa
> iniciativa. É mais uma opção para avaliarmos.
>
>
> *Oi Paulo,*
> Antes de enviar este e-mail nós escutamos a Joelma justamente para trazer
> uma melhor visão do problema para nossa discussão. Nós entendemos e
> compartilhamos a necessidade de focar no processo, mas a percepção de qual
> a melhor ferramenta é muito pessoal, veja seu exemplo e o do Hilmer... A
> Joelma nos questionou algo que nós mesmo havíamos prometido: o redmime.
>
> Acredito que nossa tentativa é justamente mostrar pra ela que é possível
> fazer com o Gitlab, por isso pedi apoio no sentido de entendermos melhor a
> ferramenta para tentar convencê-la já que não temos expectativas concretas
> quanto ao uso do redmine ou qualquer outra ferramenta que a "substitua".
> Entenda substituir no sentido de dar respostas de negócio que talvez o
> gitlab não dê na forma como ela espera...
>
> Nós aceitamos o convite de conversar sobre isso no CDTC, acho que ajudará
> bastante. A sugestão de sermos um estudo é uma ótima ideia, só tem a
> observação de que nós também usamos o redmine né? rsrsrs
>
> Podemos agendar pro dia que for melhor pra você.
>
>
> Marisa Souza
> Analista em Tecnologia da Informação
> Coordenação Geral de Sistemas de Informação - DGSI/MPOG
>
> Em 7 de março de 2015 07:38, Paulo Meirelles
> escreveu:
>
>> Em 6 de março de 2015 20:15, Jean Rodrigo Ferri <
>> jeanferri@interlegis.gov.br> escreveu:
>>
>>> A gente tem discutido muito isso no Interlegis e chegamos a um acordo de
>>> que uma ferramenta como o GitHub ou GitLab + um quadro de Kanban como o
>>> waffle.io, integrados no Colab, resolveria muito bem o problema de
>>> organização e gerenciamento, deixando o processo super simples e ágil.
>>>
>>>https://waffle.io/plonegovbr/brasil.gov.portal
>>>
>>
>> Oi Jean,
>>
>> Vocês do Interlegis sempre estão a frente nas discussões e soluções =)
>>
>> Conversamos isso com o Sergio quando ele nos mostrou o waffle. Concordo
>> que esse é o caminho mesmo.
>>
>> Para uma integração de um Kanban com o Colab temos que achar uma
>> alternativa livre ao waffle, pois ele é fechado e apenas funciona com
>> GitHub, confere?
>>
>> Termos algo desse tipo no Colab é algo que temos que pensar juntos ;)
>>
>> obrigado,
>> --
>> Paulo Meirelles
>> FGA-UnB (http://fga.unb.br)
>> CCSL-IME/USP (http://ccsl.ime.usp.br)
>>
>> _______________________________________________
>> spb-dev mailing list
>> spb-dev@listas.softwarepublico.gov.br
>>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>
>>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Em 9 de março de 2015 13:12, Marisa Souza escreveu:

>
> *Oi Jean,*
> Obrigada pelas contribuições. Muito legal mesmo :-) Parabéns por mais essa
> iniciativa. É mais uma opção para avaliarmos.
>
>
> *Oi Paulo,*
> Antes de enviar este e-mail nós escutamos a Joelma justamente para trazer
> uma melhor visão do problema para nossa discussão. Nós entendemos e
> compartilhamos a necessidade de focar no processo, mas a percepção de qual
> a melhor ferramenta é muito pessoal, veja seu exemplo e o do Hilmer... A
> Joelma nos questionou algo que nós mesmo havíamos prometido: o redmime.
>

Redmine foi uma das ferramentas estudas, apenas. Assim como outros foram:
gitorious, trac, rhodecode etc. Temos fazer melhor as pessoas interpretarem
as informações.

> Acredito que nossa tentativa é justamente mostrar pra ela que é possível
> fazer com o Gitlab, por isso pedi apoio no sentido de entendermos melhor a
> ferramenta para tentar convencê-la já que não temos expectativas concretas
> quanto ao uso do redmine ou qualquer outra ferramenta que a "substitua".
> Entenda substituir no sentido de dar respostas de negócio que talvez o
> gitlab não dê na forma como ela espera...
>

A plataforma não terá como resolver os desejos/necessidades específicas. O
outro lado também pode aprender/adaptar-se. Vamos ajudá-la a conhecer as
possibilidades.

>
> Nós aceitamos o convite de conversar sobre isso no CDTC, acho que ajudará
> bastante. A sugestão de sermos um estudo é uma ótima ideia, só tem a
> observação de que nós também usamos o redmine né? rsrsrs
>

Usamos o Redmine localmente, no LAPPIS; Da mesma forma a DTI faz no MP. O
Redmine cabe bem quando usando internamente por qualquer grupo, mas não
entre vários grupos de "metodologias" diferentes deve ser avaliado. Caso o
Gsan necessite do Redmine por questões específicas deles, não podemos fazer
nada.

Para o nosso projeto, quando a nova plataforma estiver no ambiente da
DTI/MP, minha orientação como coordenador será irmos 100% para a nossa
plataforma, ou seja, o gestão também será no GitLab. Quando iniciamos o
projeto a nossa plataforma não existia e usamos a oportunidade para
explorar ao máximo o Redmine para hoje fazer tais considerações/ponderações.

Podemos agendar pro dia que for melhor pra você.
>

Se precisam logo disso, podemos marcar na próxima sexta-feira. Caso possam
esperar, deixamos para próxima semana.

att,
--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

Em 9 de março de 2015 13:19, Sergio Oliveira escreveu:

> Aproveitando a deixa para fazer um parenteses: eu sou a favor de deixarmos
> o Redmine e trabalharmos com as issues do Gitlab.
> Sei que como toda mudança isso vai demandar um certo esforço mas eu
> gostaria de colocar isso na mesa após o R3.
>

Concordo contigo, Sergio. Vamos tentar ir nessa direção, a partir do
planejamento para a R4.

--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

Podemos deixar para a próxima semana para que não atrapalhe a finalização
da R3.
Combinamos melhor semana que vem. ;-)

Marisa Souza
Analista em Tecnologia da Informação
Coordenação Geral de Sistemas de Informação - DGSI/MPOG

Em 9 de março de 2015 14:19, Paulo Meirelles

escreveu:

> Em 9 de março de 2015 13:12, Marisa Souza escreveu:
>
>>
>> *Oi Jean,*
>> Obrigada pelas contribuições. Muito legal mesmo :-) Parabéns por mais
>> essa iniciativa. É mais uma opção para avaliarmos.
>>
>>
>> *Oi Paulo,*
>> Antes de enviar este e-mail nós escutamos a Joelma justamente para trazer
>> uma melhor visão do problema para nossa discussão. Nós entendemos e
>> compartilhamos a necessidade de focar no processo, mas a percepção de qual
>> a melhor ferramenta é muito pessoal, veja seu exemplo e o do Hilmer... A
>> Joelma nos questionou algo que nós mesmo havíamos prometido: o redmime.
>>
>
> Redmine foi uma das ferramentas estudas, apenas. Assim como outros foram:
> gitorious, trac, rhodecode etc. Temos fazer melhor as pessoas interpretarem
> as informações.
>
>
>> Acredito que nossa tentativa é justamente mostrar pra ela que é possível
>> fazer com o Gitlab, por isso pedi apoio no sentido de entendermos melhor a
>> ferramenta para tentar convencê-la já que não temos expectativas concretas
>> quanto ao uso do redmine ou qualquer outra ferramenta que a "substitua".
>> Entenda substituir no sentido de dar respostas de negócio que talvez o
>> gitlab não dê na forma como ela espera...
>>
>
> A plataforma não terá como resolver os desejos/necessidades específicas. O
> outro lado também pode aprender/adaptar-se. Vamos ajudá-la a conhecer as
> possibilidades.
>
>
>>
>> Nós aceitamos o convite de conversar sobre isso no CDTC, acho que ajudará
>> bastante. A sugestão de sermos um estudo é uma ótima ideia, só tem a
>> observação de que nós também usamos o redmine né? rsrsrs
>>
>
> Usamos o Redmine localmente, no LAPPIS; Da mesma forma a DTI faz no MP. O
> Redmine cabe bem quando usando internamente por qualquer grupo, mas não
> entre vários grupos de "metodologias" diferentes deve ser avaliado. Caso o
> Gsan necessite do Redmine por questões específicas deles, não podemos fazer
> nada.
>
> Para o nosso projeto, quando a nova plataforma estiver no ambiente da
> DTI/MP, minha orientação como coordenador será irmos 100% para a nossa
> plataforma, ou seja, o gestão também será no GitLab. Quando iniciamos o
> projeto a nossa plataforma não existia e usamos a oportunidade para
> explorar ao máximo o Redmine para hoje fazer tais considerações/ponderações.
>
> Podemos agendar pro dia que for melhor pra você.
>>
>
> Se precisam logo disso, podemos marcar na próxima sexta-feira. Caso possam
> esperar, deixamos para próxima semana.
>
> att,
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>

Só para esclarecer: Pessoalmente não sou a favor de ferramenta A, B ou C,
acho que precisamos ir atrás de soluções... Se o Gitlab resolver os nossos
problemas, ótimo! Será a escolhida, mesmo porque eu acredito que o Redmine
possui funcionalidades além do que precisamos... Acho que temos que
observar o custo x benefício, seja para qual ferramenta for. Se for no
próprio Gitlab, ótimo porque o problema já está resolvido.

Pessoalmente conversamos melhor e terei a oportunidade de conhecer um pouco
mais o Gitlab, afinal esse foi o objetivo da conversa :-) Conhecer para
orientar melhor os coordenadores.

Marisa Souza
Analista em Tecnologia da Informação
Coordenação Geral de Sistemas de Informação - DGSI/MPOG

Em 9 de março de 2015 14:20, Paulo Meirelles

escreveu:

> Em 9 de março de 2015 13:19, Sergio Oliveira escreveu:
>
>> Aproveitando a deixa para fazer um parenteses: eu sou a favor de
>> deixarmos o Redmine e trabalharmos com as issues do Gitlab.
>> Sei que como toda mudança isso vai demandar um certo esforço mas eu
>> gostaria de colocar isso na mesa após o R3.
>>
>
> Concordo contigo, Sergio. Vamos tentar ir nessa direção, a partir do
> planejamento para a R4.
>
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>

Em 9 de março de 2015 14:29, Marisa Souza escreveu:

> Só para esclarecer: Pessoalmente não sou a favor de ferramenta A, B ou C,
> acho que precisamos ir atrás de soluções... Se o Gitlab resolver os nossos
> problemas, ótimo! Será a escolhida, mesmo porque eu acredito que o Redmine
> possui funcionalidades além do que precisamos... Acho que temos que
> observar o custo x benefício, seja para qual ferramenta for. Se for no
> próprio Gitlab, ótimo porque o problema já está resolvido.
>

Perfeito, Marisa. É isso mesmo.

>
> Pessoalmente conversamos melhor e terei a oportunidade de conhecer um
> pouco mais o Gitlab, afinal esse foi o objetivo da conversa :-) Conhecer
> para orientar melhor os coordenadores.
>

Combinado!

Paulo

Em 9 de março de 2015 14:23, Marisa Souza escreveu:

>
> Podemos deixar para a próxima semana para que não atrapalhe a finalização
> da R3.
> Combinamos melhor semana que vem. ;-)
>

Combinado. Entre em contato para combinarmos melhor. Adianto que será numa
quarta ou numa sexta-feiral, pois são os dias que não estou em sala de aula
e/ou em reunião de professores.

--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

Então podemos deixar agendado para a próxima quarta-feira?
Qual horário?

Marisa Souza
Analista em Tecnologia da Informação
Coordenação Geral de Sistemas de Informação - DGSI/MPOG

Em 9 de março de 2015 20:28, Paulo Meirelles

escreveu:

> Em 9 de março de 2015 14:23, Marisa Souza escreveu:
>
>>
>> Podemos deixar para a próxima semana para que não atrapalhe a finalização
>> da R3.
>> Combinamos melhor semana que vem. ;-)
>>
>
> Combinado. Entre em contato para combinarmos melhor. Adianto que será numa
> quarta ou numa sexta-feiral, pois são os dias que não estou em sala de aula
> e/ou em reunião de professores.
>
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>