Iniciar discussão para o ROADMAP v3

[farribeiro]

Olá e obrigado por nos ajudar a tornar o i-Educar um projeto melhor. Não esqueça de revisar o nosso guia de contribuição para saber melhor como colaborar com a nossa comunidade. Você também pode usar o template abaixo para preencher sua issue:

CONTEXTO: Por que esta alteração é importante? Como você usaria isto? Como esta alteração pode beneficiar outros usuários?

Discussão de ROADMAP para o próximo ciclo.

IMPLEMENTAÇÃO: Não obrigatório, mas sugira uma idéia de como isto poderia ser implementado.

Iniciar branch v3.0.0

[ghost]

@farribeiro , não é nem questão de iniciar a discussão. Acompanhei um cenário semelhante no AROS.

A ABIv1.0 quebrava a compatibilidade e era um major milestone. Resultado, tem anos que existe o branch v0 e v1.0 ... equanto não for finalizada a v1.0, a v0 é a padrão, mas o rocknroll está no branch da v1.0 (e quando algo do "futuro" é interessante para o "presente" é feito um backport)

Acho.

[farribeiro]

Vamos seguir o que @williamespindola recomendou... como esse ciclo não é v0 ! Vide #199

[ghost]

@farribeiro É que são coisas diferentes, a ideia de releases e a ideia de forks (que são chamados de branches no caso).

Vc pode ter a mesma release, em 2 formatos diferentes. Uma aplicando namespaces com os arquivos no diretorio src, e outro com os arquivos no lugar original usando o require.

Ps: no caso do aros não existe releases propriamente dito, são nightly builds, a release é apenas um nightly build considerado estável.

[farribeiro]

@farribeiro É que são coisas diferentes, a ideia de releases e a ideia de forks (que são chamados de branches ni caso).

Branch de trabalho, não é fork.

Vc pode ter a mesma release, em 2 formatos diferentes. Uma aplicando namespaces com os arquivos no diretorio src, e outro com os arquivos no lugar original usando o require.

Pode, naturalmente, refrescou a memória que eles vão trocar de ciclo ao estilo rolling.

Mas não custa sonhar o que esperamos na v3

[ghost]

@farribeiro usei o termo fork para salientar que a ideia não é mergear de volta.

[fernandosjp]

@farribeiro o que acham de focar no ciclo atual? Acho que ainda estamos com vários desafios para superar antes de iniciar um conversa sobre o próximo.

Antes de abrir mais frentes precisamos avançar com o que já está definido no roadmap. https://github.com/portabilis/i-educar/projects/3

[ghost]

Posso estar enganado @Fernandosjp , mas essas 3 tarefas são apenas 1.

Os psrs são cumulativos, logo adotar o psr4 está incluído o psr2 e o separar o html do php.

Acho que o @farribeiro não usou o termo adequado, o proposto virou um blocker?

Se é um blocker, pq é um blocker? Pq todas as APIs foram deprecated?

Será que trocar require_once por namespaces só funcionam se todos os arquivos forem alterados de uma vez?

No caso específico da refatoração da classe utils/validation existe um todo list com todos os arquivos dizendo, todo, wip, done?

Se o roadmap diz: ajustar tudo para psr2, e as APIs estão deprecated, por exemplo, vão aplicar o psr2 as APIs ?

Não é discutir um novo ciclo, é operacionalizar o ciclo atual sendo que os ciclos não são estanques, se for estanque vc vai fazer o que tem que fazer nesse ciclo para depois desfazer no próximo? Ou rejeitar algo do proximo ciclo pq ainda não chegou lá?

Ngm pode ser contra adotar padrões, por evidente, mas o i-educar sobreviveu todos esses anos dessa forma, aplicar padrões a todos os arquivos de uma vez é um plano?

O que foi levantado fernando foi uma estratégia de abordagem operacional.

Perceba que colocar todos os arquivos em determinado formato, não se cria novos arquivos.

Eu não pretendo voltar a este assunto, pq já comentei antes, mas da forma como caminha, para mim o melhor é aguardar até o ano que vem, pois será quando eu terei pé do que aconteceu.

Pois fora essa classe de validação, que aprendi muito, eu não sei onde está o rocknroll

(Claro que vi o novo site e achei bem legal, mas que não é no escopo do que estamos falando, e é independente do resto dos códigos)

[ghost]

Não é uma tarefa trivial, pelo menos para mim. Quem está a anos com esse código sabe em que lugares atualizar o código permitiria maior avanços. Eu até pretendo fazer alguns testes, mas esse apego emocional existente é o maior blocker.

Pq não quebra esse ciclo em tarefas menores, por exemplo, e escolhe alguma bibliotecas/classes para serem refatoradas? Quais bibliotecas/classes? O i-educar é um mundo de arquivos separados, eu não saberia por onde começar, mas começar por tudo é assustador.

[fernandosjp]

@JDias Concordo com vários pontos que você levantou mas o projeto precisa de algum foco antes de voltar a abrir (talvez poderíamos ter uma data para isso, algo perto de novembro). O refactoring não deveria durar para sempre e deve ser focado onde pode agregar mais valor. O seu objetivo é permitir que a manutenção do código seja sustentável e a comunidade possa voltar a planejar novas funcionalidades.

Em relação ao seu ultimo comentário, achei ele o mais concreto e acionável. Seria uma ótima contribuição para a issue de implementação de padrões. A issue continua muito grande e você levantou como podemos deixá-la menor. Pergunta por lá se a Portabilis não poderia selecionar os 5 arquivos de maior prioridade.

[ghost]

eu tenho algumas possíveis sugestões, como atacar a medida que for sentindo necessidade, ter um branch para código novo, usar o router/front-controller como forma de dividir.

quando chega no banco de dados a discussão fica mais difícil.

mas algumas perguntas podem serem feitas, querem realmente trabalhar com MVC? se sim, parar de chamar de model o que não é model, de view o que não é view e de controller o que não for controller. (e nisso a quebra para um branch/fork ajuda a agrupar as coisas de forma lógica e intuitiva, o que surge uma nova pergunta, é de interesse ter um código de fácil manutenção? então não criar o que já existe pronto)

pela estrutura atual do i-educar, eu não mexeria em nada do antigo e deixaria como está. (não quebrar nada do que já está funcionando, apenas abrir espaço o suficiente para que as coisas novas possam se acomodar) se começar pela API vc vai conseguir visualizar exatamente um roadmap, pq? Pq na API vc pode ter todas as funcionalidades do site, sem as views. (e aí a tarefa não seria separar php de html, mas somente ter o html) Então nas APIs, vc vai ter necessidade de front controller, de http requests, e vai evidenciar as facilidades e dificuldades atuais.

o i-educar trata suas proprias requests, testa o metodo, faz tudo isso por conta própria.

uma pergunta simples @fernandosjp como eu coloco esse arquivo de acordo com o roadmap proposto? https://github.com/portabilis/i-educar/blob/master/ieducar/intranet/add_fotos.php

ps: @fernandosjp agora que vi sua resposta então esse meu comentário ficou um pouco deslocado, mas vou postar, pois levantar a discussão ajuda a achar respostas.

eu acho que a pergunta nem seria os 5 arquivos, mas os 5 tópicos específicos. (vc pode em 1 só funcionalidade bater em 5 arquivos, da forma como as coisas estão estruturadas), tópicos menores que converter TUDO para php-fig.

se no roadmap geral tem a intenção de ter uma pasta src, de se ter o router do symphony, de utilizar o doctrine, não ter tudo em php-fig não pode ser blocker para iniciativas nessa direção (mas pela resposta percebo que o sr concorda comigo em certa medida, então, me desculpem a minha contribuição não ser em forma de commit, mas... não tem mas, são perguntas, pensamentos soltos, algo a ser elaborado de forma a contribuir)

[fernandosjp]

@JDias levanta então as funcionalidades que valeria tentar refatorar. Também acho que o que é código que não vamos mexer muito poderia ficar como está e deixar funcionando. Só refatorar o minimo necessário para estabilizar bugs e ter espaço para planejar novos crescimentos.

[farribeiro]

Quero relembrar que essas atividades é para depois do fechamento do ciclo atual, ou seja, posterior a Dezembro

O ROADMAP do ciclo atual está definida. Bastamos executá-las

[fernandosjp]

@farribeiro, ness caso acho que não é o momento de puxar. Além disso esse seria um papel que podemos deixar para o mantenedor. Assim que eles puxarem acho muito legal colaborarmos para sugerir o caminho que gostaríamos que o projeto tomasse. Mas essa papel é deles que estão conectados com os usuários e com a operação de dia-a-dia do software.

[ghost]

@fernandosjp @farribeiro foi o que eu disse, o melhor a se fazer é hibernar até janeiro!

@fernandosjp eu vou precisar de um tempo para tentar elaborar a sua resposta.

[fernandosjp]

@JDias acho que não precisa ficar na sua mão. O que quis dizer é você levantou um bom ponto. Aplicar padrão ainda é um tarefa muito grande e precisamos fatiar um pouco mais. Para isso podemos ter ajuda da portabilis. Se fosse você perguntaria qual a funcionalidade mais crítica que queremos focar nessa aplicação de padrões?

[farribeiro]

Hashtag partiu específicar APIs e gerar sistemas que consomem tal API

[ghost]

@fernandosjp eu acho que a 1a coisa que eu faria seria trocar os require_once por use aonde o código já permitir! que tal?

tive a curiosidade de olhar o https://github.com/portabilis/i-educar/issues/287

e por acaso fui navegando no código. (é sempre uma aventura)

por exemplo, em ieducar\modules\Avaliacao\Model\NotaComponente.php tem require_once 'CoreExt/Entity.php'; eu tentei trocar por use CoreExt_Entity;

e o require_once 'Avaliacao/Model/Etapa.php'; por use Avaliacao_Model_Etapa;

mas eu tenho certeza que eu devo estar fazendo algo errado, por lógica!

então a pergunta "qual a funcionalidade mais crítica que queremos focar nessa aplicação de padrões?" para mim é um mistério ainda maior.

ps: a impressão que me dá como leigo @farribeiro é que o código foi deliberadamente ofuscado :confused:

[farribeiro]

Poderia por gentileza trocar o nome da PLANEJAMENTO TÉCNICO PARA ROADMAP-MILESTONE v2?

[farribeiro]

A PR #389 pode ser considerada próximo ciclo do ROADMAP-MILESTONE v3

[edersoares]

Atualmente não há planejamento para iniciar uma versão 3.