New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Cycle e Suporte #199

Closed
williamespindola opened this Issue Jun 6, 2018 · 51 comments

Comments

Projects
None yet
7 participants
@williamespindola
Collaborator

williamespindola commented Jun 6, 2018

Definir um ciclo de lançamento e suporte nos ajuda a manter e organizar a evolução e manutenção. Alguns pontos aqui dependem do negócio, hoje é a Portabilis quem mantem o software e ela que presta suporte direto, logo cabe a vocês o feeling para definir alguns pontos aqui.

## Versões MAJOR
- A cada 6 meses
- Pre-releases 3 meses antes
- Manutenção de segurança 6 até meses

## Versões MINOR
- Lançado logo após adição
- Sem pre-releases

## Versões PATCH
- Lançado logo após o bug fix

## Versões suportadas
- Pelo menos até 2 MINOR
- A última release da última MAJOR

**Exemplo 1:**
- A última release é `1.0`
- A última release da última MAJOR será `0.9`

Daremos suporte para `0.9.x`, `0.8.x` and `1.0.x`.

**Example 2:**
- A última release é `1.5`
- A última release da última MAJOR será `0.9`

Daremos suporte para `1.5.x`, `1.4.x` and `0.9.x`.

Explicando cada ponto:

## Versões MAJOR
- A cada 6 meses
- Pre-releases 3 meses antes
- Manutenção de segurança 6 meses

A cada 6 meses, poderíamos lançar uma versão que quebra retro compatibilidade, de 1.0 para 2.0 por exemplo, onde as funcionalidades da versão 1.0 não teriam garantia de funcionamento na 2.0 em diante.
A cada 3 meses uma pre-release seria lançada, com algumas das futuras funcionalidades que a próxima versão terá, mas em beta. Esta será constantemente atualizada com as novas funcionalidades programadas para a próxima release até sua estabilidade e lançamento oficial no 6 mês.
Versões fora do ciclo e não suportadas podem ser mantidas ainda durante 6 meses mas apenas para bugs de segurança e não receberam mais novas funcionalidades.

## Versões MINOR
- Lançado logo após adição
- Sem pre-releases

MINOR qualquer adição de nova funcionalidade que não quebre retro compatibilidade pode ser lançada logo após a sua implementação e gerada release por um dos core commiters, algo como 1.2 par 1.3. Estas não precisam de uma pre-release, mas é importante ter uma rotina de testes que garanta a integridade do software.

## Versões PATCH
- Lançado logo após o bug fix

Não é necessário aguardar nenhum ciclo para resolver um bug encontrado na aplicação e ele é lançado logo após a solução ter sido implementada e a release gerada por um dos core commiters.

## Versões suportadas
- Pelo menos até 2 MINOR
- A última release da última MAJOR

Como exemplificado acima isto garante que não manteremos um software defasado, não precise corrigir bugs retroativos e manter a aplicação em constante evolução.

A Portabilis precisa nos passar se estes períodos estão muito longos ou muito curtos comparado ao que acontece hoje.

@williamespindola williamespindola changed the title from Release Cycle and Support to Release Cycle e Suporte Jun 6, 2018

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 6, 2018

Mover essa discussão para o Slack, ou de preferência no repo comunitário. Lá te responderei.

@nawarian

This comment has been minimized.

nawarian commented Jun 6, 2018

@farribeiro por favor dê uma olhada aqui: #203

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 6, 2018

@nawarian você teria alguma coisa para falar sobre o Release Cycle?

@nawarian

This comment has been minimized.

nawarian commented Jun 6, 2018

No canal do Slack foi comentado sobre SEMVER, seu exemplo está complacente. Acho interessante manter este formato :)

Quanto a dar suporte, será que não rola simplificar para darmos suporte a apenas 2 versões por vez? De acordo com seu primeiro exemplo fazer "Daremos suporte para 0.9.x e 1.0.x." somente.

Como vimos a organização do projeto não está muito avançada, acho que seria interessante criar regras mais abrangentes quando tiver algo mais concreto. O que acha @williamespindola ?

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 6, 2018

Acho uma boa, mantendo a última minor e ultima major?

Estou levantando isto porque codigo de condulta, release cycle e outros pontos que citei na issue #201 são escenssiais para algumém entender como as contribuições funcionam.

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 7, 2018

@nawarian é isso? Gostaria de fazer estilo kernel... pares stable e impares unstable ?

https://semver.org/

@nawarian

This comment has been minimized.

nawarian commented Jun 7, 2018

Concordo @williamespindola, acho que assim que a gente bater o martelo aqui dá pra dar uma atenção justa ao contributing :)

@farribeiro a ideia é bacana porém retira da comunidade uma responsabilidade que eu acho interessante a gente manter: desenvolver software de qualidade e estar de prontidão para manutenção.
O SEMVER já propõe a utilização de traços pra marcar um pre-release (ex.: 0.1.x-alpha). Acho que é um bom ponto de partida caso a gente queira manter essas flags de estável ou instável. O que acha?

@MarceloCajueiro

This comment has been minimized.

Member

MarceloCajueiro commented Jun 9, 2018

Olá pessoal. Ótima discussão, mas ainda não temos uma opinião formada.

A Portabilis trabalha com deploy contínuo, então tudo que está aqui agora, está rodando no cliente.

Pegar um sistema desse e falar que não atende a retro-compatibilidade é bem complicado. Todo upgrade deve ser pensado em quem usa. E de um deploy para o outro, deve tudo continuar funcionando.

Como devemos trabalhar tendo em vista esse cenário?
Como vamos lançar versões?

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 10, 2018

O release cycle esta totalmente ligado a planejamento e ao roadmap, então quando temos algo que vai sair, quanto queremos fazer algo que demanda um cuidado como estabilidade usamos ele para demarcar. São vários cenários, vou ilustrar alguns exemplos para ficar mais simples.

Exemplo 1 Vamos supor que iremos trocar a versão do php de 5.6 para 7.2, isto vai demandar o trabalho de implementação e define que quebra retro-compatibilidade. Logo definimos que no próximo major (de 1.0 para 2.0) faremos isto e então temos um target, trabalharemos para atender esta data.

Exemplo 2 Vamos supor que uma nova funcionalidade foi implementada uma nova extração de relatório por exemplo. Isto não quebra retro-compatibilidade. Então ela pode ser lançada a qualquer momento. algo como 1.0 para 1.1

Exemplo 3 Também podemos trabalhar com um grupo de features, por exemplo, teremos um planejamento para implementação de standards como PSR-2, modularização de algumas funcionalidades e implementação de algumas features novas. Definimos isto para a próxima major e trabalhamos para atender-la. algo como 1.0 para 2.0

Exemplo 4 com o lançamento de uma nova major 3.0 a versão 1.0 esta depreciada, então não vamos mais garantir manutenção para ela. E se alguém tem esta versão instalada ele precisa atualizar.

O release cycle não retira ou altera o continuous ele pode continuar sem problemas, sempre que novas funcionalidades e bugs surgem.

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 10, 2018

Gosto muito da ideia de trabalharmos com versões. Não gosto muito da ideia de termos cíclos fixos pra isso. Acho que as novas versões tem que surgir quando fizer sentido e, principalmente neste início, onde semanalmente a Portabilis vai lançar patches com dezenas de bug fixes, a gente tem que pensar direitinho em como vamos fazer isso e, principalmente, quando...

Então também coloco o questionamento de qual pode ser a nossa abordagem pra isso. Acho que algo rígido com datas de pré-release, release, etc., ou até mesmo 100% compatível com SEMVER não são possíveis.

A gente tem que lembrar também que não estamos trabalhando numa biblioteca onde SEMVER é importante por causa de dependências. Como aplicação, existe um caminho claro pra upgrades e como o @MarceloCajueiro falou, temos isso rodando em produção com deploys contínuos. Podemos pensar em um esquema de versionamento que faça mais sentido pra esta realidade.

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 10, 2018

Entendo o problema de ciclos fixos, por isto que falei no início da conversa que isto ia depender de como a Portabilis entrega o projeto hoje.

Se não estamos trabalhando com gestão de dependência, é uma excelente hora de começar. :D

Poderia mer da um exemplo de um problema em seguir o Semver?

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 11, 2018

@williamespindola eu acho o próprio fato da Portabilis enviar patches semanais com inúmeros bug fixes de coisas que estão em produção torna difícil a gente definir versões com o SEMVER. Acabaria sendo algo meio arbitrário mas é algo que pode ser ajustado...

Ou teremos um milhão de minor versions com uma página de releases mega poluido, ou vamos ter que definir arbitráriamente quando pontuar uma versão. Não sei qual seria a melhor alternativa...

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 11, 2018

Este é um processo normal, talvez vocês não estejam acostumado. Se estão rodando continous então, será quase imperceptivel pois tudo esta automatizado. Quando a release for criada o deploy será automático.

Não tem problema você ter uma lista grande de releases, ninguém vai ficar olhando release por release. O motivo de criar releases é ter um controle de quando uma coisa entrou ou saiu. Imaginando que implementamos namespace que alterou la os 1496 arquivos que tem require_once esta é uma alteração grande e quebra retro-compatibilidade. Como conseguimos identificar em que momento isto entrou e fazer um row back?

E o ponto que estou trazendo nesta issue é o planejamento junto do controle.

Quantas minors e patches vocês geram por semana?

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 11, 2018

Rolling não é ruim... mas tem que marcar qual será o fechamento da versão

@nawarian

This comment has been minimized.

nawarian commented Jun 13, 2018

Eu concordo com o @williamespindola. Eu inclusive adoraria ter uma lista enorme de minor versions que seja descritivas quanto o changelog. Fica muito mais fácil de encontrar problemas pontuais e reverter se necessário.

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 13, 2018

Eu só peço que sejam devidamente "tageada"

@nawarian entre para o usergroup https://t.me/i-educar

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 15, 2018

@MarceloCajueiro e @eberfreitas o que o @farribeiro falou na issue #246 esta ligado com o que estamos discutindo aqui. É bom definirmos isto para continuarmos.

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 15, 2018

@MarceloCajueiro e @eberfreitas o que o @farribeiro falou na issue #246 esta ligado com o que estamos discutindo aqui. É bom definirmos isto para continuarmos.

É que já faz uma semana que a v2.0.0 foi lançada e não há um CHANGELOG

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 18, 2018

Link Issue #255 (comment)

Como utilizar semver na prática

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 18, 2018

@eberfreitas vamos aproveitar este PR #248 para montar nosso plano. Vi um ciclo ali, vocês trabalharam em várias issues durante a semana e no final da semana fizeram o deploy, foi isto?
Esta poderia ser uma tag MINOR, e.g 1.0 para 1.1 com uma lista de bugs e improvements sendo lançados que não quebram retro-compatibilidade.
Todas elas poderiam ser feitas separadamente dentro de um plano de lançamento ou não.
Alguma delas, algum bug talvez foi feito o fix e deploy no mesmo momento?

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 18, 2018

Acho que vamos precisar do @MarceloCajueiro e do @munizeverton pra fechar essa questão de uma vez.

Se o fato de termos um "sem número" de minors não for um problema, eu acho que faz sentido a gente agrupar um conjunto de issues ao término de um tempo X e definir uma versão seguindo SEMVER.

Também vejo o projeto evoluindo de forma mto progressiva, então não sei se vai ficar claro quando vamos, por exemplo, subir uma major. Por exemplo, creio que a migração pra PSR-4 vá ocorrer aos poucos e vamos ter, ao mesmo tempo, código antigo e código "novo" coexistindo no master.

Um ideia talvez seja subir a major quando aquele projeto for finalizado, ou não... Do ponto de vista do usuário, não vai ocorrer mudança.

@MarceloCajueiro

This comment has been minimized.

Member

MarceloCajueiro commented Jun 19, 2018

Eu estou ausente aqui nessa Issue pois estou envolvido em diversas frentes na Portabilis. Nem tudo vai caminhar rápido quanto a comunidade gostaria.

Nós adiantamos o processo de abertura do código - que era para acontecer até fim de Julho - para início de Junho para iniciar as movimentações da comunidade, mas está sendo bem difícil pra gente.

Lembro a todos que a Portabilis é uma empresa, que usa o i-Educar em produção em mais de 60 municípios. Temos uma equipe com 6 desenvolvedores trabalhando diretamente nele. Temos uma lista de issues de clientes que é bem grande e a mudança de mindset para trabalhar 100% em comunidade não acontece da noite para o dia, pois temos que resolver os problemas dos clientes em tempo real. Cada resolução de um cliente, é uma resolução para a comunidade, pois passa também pelo nosso processo de QA (2 profissionais).

O que acham da gente fazer um hangouts a respeito disso? Aí eu conto um pouco mais sobre tudo e deixamos gravado tbm para a comunidade.

@MarceloCajueiro

This comment has been minimized.

Member

MarceloCajueiro commented Jun 19, 2018

Perdão se fui repetitivo sobre alguns pontos que o @eberfreitas já falou aqui: #250 (comment)

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 19, 2018

Mai rapai compartilha esta lista de issues com a gente. Taca no roadmap para todo mundo trabalhar junto.
Vamos pegar um projeto para comparar, Firefox por exemplo, código aberto, bug tracker e issues também abertos, milhões de usuários no mundo inteiro usando o sistema.
Não estou desmerecendo o Ieducar, mas não é a quantidade de clientes usando ou desenvolvedores trabalhando que pode definir a não existência de releases, isto é importante para a vida do software. Isto vai crescer ainda mais. Vai atingir o Brasil inteiro e manter esta releases vai nos ajudar a organizar a casa e saber onde estamos e par onde vamos.
Exemplo, como posso garantir uma versão estável hoje se todos os merges vão para o master? E se em algum momento eu precisar fazer um roll back para a versão anterior porque a versão atual que foi feito deploy quebrou a aplicação? Hoje eu não consigo responder estas perguntas. Ou internamente vocês estão mantendo isto separado por branches.

Podemos fazer o hangouts sim.

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 19, 2018

Sabe como pode ser refeito o changelog? Com Squash!

@fernandosjp

This comment has been minimized.

Contributor

fernandosjp commented Jun 20, 2018

Acho que para começar só o fato de ter os releases com tag e o grupo de commits no change log já seria ótimo. O i-Educar está na versão 2.0 considerando que essa lógica esta começando agora e para ficar coerente com o trabalho que vem sendo feito pela comunicação.

Para começar de forma simples acho que a Portabilis poderia deixar a versão que está em produção hoje como 2.0 e já que os commits que estão entrando são apensas bugfix começarmos a soltar junto com os sprints o versionamento de ptach para bugs 2.0.1, 2.0.2, 2.0.3. O que acham?

@fernandosjp

This comment has been minimized.

Contributor

fernandosjp commented Jun 21, 2018

Concordo com você @eberfreitas! Para mim só faria sentido uma major quando se consolidarem mudanças grandes para o usuário. Acho que por enquanto não precisamos nos preocupar com isso. Vai ficar claro mais para frente. Vamos somente com minors e bug fix partindo de 2.0? @williamespindola @nawarian @MarceloCajueiro @farribeiro O que acham de começarmos assim?

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 22, 2018

Bora começar! @eberfreitas uma major só acontece quando ela quebra retro compatibilidade, ou seja a versão anterior é totalmente incompatível com a atual. Vai ficar bem claro isto quando acontecer.
E ela pode ser programada também, vamos supor que vamos fazer um esforço de trocar de linguagem de php para c++, esta seria a próxima major release, não importa qual número seja o importante é depois olharmos e saber que entre a 2.0 e a 3.0 são incompatíveis por porque isto e aquilo mudou.
Olhar e ver que da 2.0 para 2.1 fo adicionado esta e aquela funcionalidade e elas em hipótese alguma pode quebrar aplicação.
Outra programação legal também são para as minos de evolução de arquitetura e implementação de issues que são bem complexas onde colocamos um objetivo e falamos para a comunidade para ajudar a atender. Tipo na próxima release, daqui 3 meses precisamos integrar com a nasa e para isto vamos precisa refatorar a parte de relatórios para suportar um tipo x de arquivos.
Este é um processo bem natural quando você esta trabalhando com semantic version.
De uma olhada neste projeto https://github.com/mautic/mautic/releases

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 22, 2018

@fernandosjp quando você disse na issue #250 sobre colocar o roadmap no tempo é algo parecido com o que propus aqui? Algo como planejar as entregas?

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 23, 2018

Fala galera, então vamos tentar finalizar um formato? Seguindo o que tem sido falado por aqui, principalmente os inputs finais aqui do @williamespindola @fernandosjp e @MarceloCajueiro talvez possamos trabalhar da seguinte forma:

  • O branch master sempre está em situação "estável". Entre aspas porque, para todos os efeitos, estamos trabalhando em um montão de mudanças e o i-Educar ainda tem muitos bugs e muito código legado mas, querendo ou não, este é o código que está em produção hoje. Por isso acho que vale a pena usarmos o identificador -beta em todos os releases pra denotar bem a situação do projeto que não está estável como gostaríamos que estivesse;
  • De tempos em tempos vamos taguear uma versão. Muito provavelmente esta versão será definida quando a Portabilis fizer o PR com tudo o que foi feito durante a última sprint, mas não acredito que seja necessário nos limitarmos a isso. O PR pode ser um bom parâmetro mas acho importante termos liberdade para definir novas versões quando fizer sentido;
  • A ideia é usar SEMVER então bug fixes e melhorias serão patches. Teremos uma minor com a introdução de novos recursos e outras mudanças significativas que não quebram compatibilidade. E major apenas quando um conjunto de (aparentes) features forem implementadas como grandes projetos.

No release de cada versão fazer um chagelog resumindo as principais coisas que foram resolvidas, indicar a lista de commits pra uma visão mais panorâmica. O changelog pode estar num arquivo e na ferramenta de releases do GitHub pra ficar fácil de consultar, seja lá qual for sua fonte de acesso.

Esqueci de algo? Querem acrescentar ou remover alguma coisa?

@fernandosjp

This comment has been minimized.

Contributor

fernandosjp commented Jun 26, 2018

@williamespindola sim, parecido com o que você propôs mas um pouco mais em alto nível. Eu entedi do seu comentário que inclusive os issues poderiam estar aberto. Minha proposta é que um roadmap em alto nível conseguiria dar mais visibilidade dos grandes temas que estão sendo prioridade. (Ex.: https://github.com/fernandosjp/test-roadmap/projects/1)

@eberfreitas tenho uma observação em relação ao primeiro item:

  • não acho que devemos chamar de beta pelo fato de ter alguns bugs
  • pelo que eu entendo os tags na master não precisam garantir versão estável, ou seja, não necessariamente o master está sempre estável. Exemplo: v0.29.0-RC1 do metabase não é uma versão estável mas é um tag de pre-release no master do projeto. https://github.com/metabase/metabase/releases/tag/v0.29.0-RC1
  • garantir versões "estáveis" (as que a portabilis usa em produção) nos release tags. Ex.: v2.0, v2.1, v2.1.1, etc
  • simplificar ao máximo Changelogs. Se não estiver organizado o que foi feito, deixar "correção de bugs". Aos poucos vai ficando mais claro.

Concordo com os outros 2 pontos. Bora tentar?

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 26, 2018

Bora!

Acho que a questão do -beta não é bem pelo fato de ter bugs (pq isso sempre vai ter) mas pq muita coisa está incompleta, não necessariamente no produto mas, por exemplo, testes... Seria só uma forma de deixar clara a situação do projeto. Mas também não vejo como algo essêncial. O que acha @MarceloCajueiro ?

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 27, 2018

O -beta Seria o pre-release que falei, não é um cara que tem bug, mas sim inacabado, que não esta 100% para alguém usar em produção seja por bugs ou features faltando.

@eberfreitas Esta representatividade do master que você falou, que não pode quebrar deveria ser a a release pois com o master você não tem o ponto para fazer roll back. Como o Fernando falou uma aplicação estável também pode dar problemas.
Resumindo:

  1. Deploy sempre da última release que não for beta ou pre-release.
  2. Releases são criadas em cima da master e a master pode receber PRs porem o deploy vai ser feito apenas quando a release for feita.

Bora tentar sim. Só vou ser chato e um ponto que falei várias vezes aqui. A sprint da Portabilis para este projeto i-educar tem que estar pública aqui nas issues.

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 27, 2018

@williamespindola não sei se entendi o que vc quis dizer por deploy. Não acho que deploy seja relevante pra gente pensar nesta estruturação, até pq cada um vai pensar na melhor estratégia de deploy pra sua realidade.

Por aqui nós devemos continuar fazendo deploy de tudo o que estiver no master, independente da versão.

A não ser que eu não tenha entendido o que foi dito (muito provavelmente, rsrs).

Com relação às issues da sprint algumas coisas devem começar a aparecer por aqui e vamos migrando aos poucos acredito eu.

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jun 27, 2018

@williamespindola não sei se entendi o que vc quis dizer por deploy. Não acho que deploy seja relevante pra gente pensar nesta estruturação, até pq cada um vai pensar na melhor estratégia de deploy pra sua realidade.

Será que ele quis dizer: "Empacotamento" ?

Por aqui nós devemos continuar fazendo deploy de tudo o que estiver no master, independente da versão.

Não recomendo fazer empacotamento do master e sim das tags

A não ser que eu não tenha entendido o que foi dito (muito provavelmente, rsrs).

Com relação às issues da sprint algumas coisas devem começar a aparecer por aqui e vamos migrando aos poucos acredito eu.

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jun 28, 2018

@eberfreitas o deploy é o ator principal disto é totalmente relevante. Consegue me falar onde na frase não entendeu?
Gerar release e faze o deploy sempre do master ignora tudo que estamos discutindo aqui.

Não pode acontecer em hipótese alguma vocês lançarem um pr ou fazer um merge com código/feature/fix que a comunidade não conhece. Se o projeto esta aberto toda a comunidade tem que saber o que esta acontecendo. Pensa no seguinte exemplo: eu estou aqui, sem cobrar nada doando meu tempo para contribuir neste projeto, pego uma task e começo a trabalhar, de repente o código onde estou mexendo tem um PR "mergeado" e meu trabalho é jogado fora pois por conta de uma decisão interna vocês decidiram remover a feature que eu estava trabalhando. Isto ja aconteceu no PR #248

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jun 28, 2018

@williamespindola entendo totalmente seu ponto de vista!

É algo que precisamos melhorar, mas é necessário entender também que internamente, fazer deploy do que está na master tem sido nosso fluxo e é um fluxo necessário para atender aos clientes da Portabilis em suas demandas do dia a dia, que no final das contas são demandas que atendem a qualquer instituição que resolva utilizar o i-Educar mesmo sem pagar um centavo.

Mais uma vez entra a questão de termos aqui públicos as issues em que trabalhamos, o que evitaria muitos destes problemas. Acho um ponto importante, acho que é algo que vai acontecer, não sei exatamente quando nem como, mas imagino que será algo gradativo e não imediato. Ping @MarceloCajueiro?

De qualquer forma, temos tido cuidado pra não haver sobreposição do trabalho. Não sei exatamente qual feature você estava trabalhando quando foi feito o PR #248 mas é algo que realmente não pode acontecer.

No final das contas, imagino que essa questão do deploy realmente não afeta o que estamos decidindo aqui. Não importa se a Portabilis (ou qualquer outra instituição) faz ou deixa de fazer da forma X ou Y. É necessário que a gente comece a organizar as versões da forma como temos conversado e se não houver resalvas sobre o formato proposto, imagino que possamos começar e dar esta discussão por concluida.

@fernandosjp

This comment has been minimized.

Contributor

fernandosjp commented Jun 28, 2018

Sobre versões:
Bora começar @eberfreitas dessa forma que acordamos! 👍 No fim o que vocês fazem é fazer um release de um patch de bug por sprint mas sem marcar que foi um release. Só o fato de começarem a colocar tags de release já resolve essa questão.

Sobre issues abertas para facilitar colaboração:
Concordo com os dois lados (@williamespindola e @eberfreitas). Para existir colaboração, é muito importante que fique transparente o que esta sendo trabalhado. Ao mesmo tempo entendo que a Portabilis está se adaptando a essa realidade de trabalhar em um projeto aberto e ao mesmo tempo precisa continuar atendendo seus clientes atuais.

Acho que essa demanda por issues e branches abertos também é poderia estar no roadmap do projeto para garantirmos que estamos todos alinhados aquando esperamos ter isso redondo. Esse aqui é o roadmap que mencionei quando falamos ontem https://github.com/fernandosjp/test-roadmap/projects/1. Ele comunica em alto nível o que esta sendo trabalhado.

screenshot from 2018-06-28 10-42-13

@williamespindola

This comment has been minimized.

Collaborator

williamespindola commented Jul 1, 2018

@MarceloCajueiro @eberfreitas e @fernandosjp eu quero muito continuar contribuindo para este projeto mas com PRs como este #284 não é possível, vocês precisam encarar que se o projeto é aberto tudo que vai entrar precisa ser público e seguir as regras que estão no contributing. Este PR desrespeita tudo que esta la e não contempla com o Roadmap.
Eber vi que você gerou a release, parabéns por este passo.
Vou acompanhar as atividades e quando ver que vocês conseguiram se organizar e seguir o guide line volto à ativa.

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jul 1, 2018

@williamespindola eles estão distribuindo algumas tarefas para correção do código já liberado e novas features

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jul 2, 2018

@williamespindola valeu cara. Na verdade eu só fui o cara que apertou os botões, mas todo mundo colaborou com o release :)

Sobre sua participação, fiquei em dúvida se você vai levar a cabo os PRs que tens em aberto? Se não, nos avise para que possamos passar as tarefas pra outras pessoas e não ficar lá travando.

Entendo totalmente sua resolução e, como já dissemos algumas vezes, este projeto tá na sua infância e estamos aprendendo aos poucos. Os motivos pelos quais fazemos as coisas como fazemos agora já foi explicado. Novas tasks estão aparecendo nas issues e aos poucos tudo vai se tornando mais transparente, mas fique bem à vontade para ir e voltar quando desejar. A gente agradece por toda força que já deu por aqui!

@fernandosjp

This comment has been minimized.

Contributor

fernandosjp commented Jul 2, 2018

@eberfreitas e outros devs Portabilis! Parabéns pelo avanço dos releases! Esta ficando com uma cara muito boa! Acredito que já podem fechar essa issue, certo?

Para a outra discussão que se abriu, concordo com o @williamespindola. Acho que para alguém que esta doando o tempo para contribuir, precisa ficar muito claro o que está acontecendo no projeto. Tornar as issues publicas ajuda nesse sentido e evita que duas pessoas comecem a trabalhar em cima do mesmo pedaço de código. Vi que essa mudança de modo de trabalhar já está contemplada no roadmap e também já existem issues sendo abertas pelo @munizeverton. Acredito que será um grande avanço para que colaboradores externos possam gerar valor para o i-Educar.

Vamos continuar essa discussão em #281 ?

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jul 2, 2018

Será que não estaria acontecendo conforme a PR #292 ?

@farribeiro farribeiro referenced this issue Jul 3, 2018

Closed

Sobre roadmap #295

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jul 5, 2018

@williamespindola eles iniciaram a refatoração do projeto (aqui no github), enquanto libera mais códigos, como disse anteriormente. E recebidas grandes melhorias por desenvolvedor independente

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jul 23, 2018

@williamespindola Agora descobri um terceiro ROADMAP, a DOCUMENTAÇÃO! É executado independente do que foi definido em projeto e ainda por cima... NÃO É PÚBLICO

Será que não necessita estar no ROADMAP? Mas se diz ao projeto, alguns interligados diretamente ao projeto.

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jul 23, 2018

@farribeiro onde vc descobriu este terceiro roadmap? Pq também não tenho conhecimento...

@vinicelms

This comment has been minimized.

Contributor

vinicelms commented Jul 25, 2018

@farribeiro , a documentação é o mínimo necessário para um projeto de código aberto. Sem documento nenhum movimento aberto se torna legítimo. O roadmap está mais focado no código e não em todo ecossistema.

Além do mais, é PÚBLICO SIM. Veja esta issue: #221

@farribeiro

This comment has been minimized.

Contributor

farribeiro commented Jul 25, 2018

@vinicelms até onde sei vc já publicou parte desta documentação e e eu não sei no que você está trabalhando no momento e quais os planos itens a fazer/realizar e por isso considero um outro ROADMAP

@vinicelms

This comment has been minimized.

Contributor

vinicelms commented Jul 25, 2018

Estamos embrionários, @farribeiro . É um processo de estruturação da documentação. Estamos estudando a melhor forma de documentar, para que possamos torná-la possível de documentar em comunidade.

Não compreenda que todos os movimentos que são feitos no projeto, estão acontecendo contra a comunidade. Cogitar que as ações são contra, é desmerecer o trabalho que está sendo feito, que não é pequeno e muito menos simples.

Respondendo a sua questão: não foi publicada nenhuma documentação nova, apenas transcrevi a atual, que está neste link: https://portal.softwarepublico.gov.br/social/i-educar/manuais-de-usuario

Apenas pensamos o que foi compartilhado na issue #221 , que vamos estruturar a documentação em processos e teremos as personas para organizar as coisas na ferramenta.

@eberfreitas

This comment has been minimized.

Contributor

eberfreitas commented Jul 25, 2018

Galera, essa issue era sobre o Release Cycle, algo que já foi debatido, decidido e já está em prática. Fechando a issue uma vez que as discussões aqui estão tomando outros rumos divergentes do assunto original.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment