Políticas afirmativas - Githubissues

helioaga commented 4 months ago

Incluir na ficha de matrícula campo para indicar se aluno ingressou por vagas de ampla concorrência ou reservadas por políticas afirmativas.

leomurta commented 4 months ago

Hélio, queremos saber exatamente se ele usou vaga de política afirmativa ou basta saber se ele era optante? Pergunto pois são coisas distintas. Um aluno optante, que ficou em 1o lugar na seleção, entra por ampla concorrência.

Qual seria o uso da informação?

leomurta commented 4 months ago

O @helioaga me respondeu por e-mail que seria interessante ter ambas as informações (se optou por ação afirmativa e se foi efetivamente selecionado via vaga de ação afirmativa). Ambas as informações, acredito eu, estão no sistema de seleção. @JoaoFelipe , será que não seria o caso termos campos em matrícula para essas duas informações e, na migração de candidato para aluno/matrícula, povoarmos esses campos?

IgorMonardez commented 4 months ago

Para entender melhor sobre a tarefa ela seria para acrescentar duas flags(?) sobre a política afirmativa de cada aluno na matrícula e ela seria povoado baseado por um sistema de seleção, qual seria esse sistema? Não conheco

IgorMonardez commented 4 months ago

Ou teria alguma especificação sobre politicas afirmativas, no sentido de ter algum código, ou seja criaríamos uma tabela de politica afirmativa com o código e a descrição e o ligaria com enrollment via 1-n.

leomurta commented 4 months ago

@IgorMonardez , o "sistema de seleção" é, na verdade, o módulo de seleção do Sapos. Ele tem uma funcionalidade no final onde "promovemos" alguns candidatos que foram aprovados em alunos. Aí criamos entidades de aluno e matrícula com os dados deles. Talvez seja um pouquinho mais complexo que duas flags, já que temos tanto para "negros e indígenas" quanto para "PcD". Como o @JoaoFelipe foi quem implementou a parte de seleção, acho que ele vai conseguir falar como seria o melhor mapeamento.

JoaoFelipe commented 4 months ago

A parte de seleção é uma das abas que aparece no SAPOS. No código em si, é o que está dentro de admissions.

Dei uma olhada no formulário que estão usando na seleção e tem dois campos lá relacionados a isso:

Raça/cor com as opções: Não declarado/Branca/Preta/Parda/Amarela/Indígena
Pessoa com deficiência com as opções: Não/Sim

Acho que seria interessante adicionar os dois campos em Aluno e criar uma relação entre esses campos no form de seleção e os campos em aluno. No caso, possivelmente teria que alterar os seguintes arquivos para fazer esse mapeamento:

assets/javascript/form_fields/config_student.js (não tenho certeza se é necessário)
função populate_field de controllers/admissions/form_templates_controller.rb para usar STUDENT_FIELD ao invés de SELECT nessas situações
função update_student de models/admissions/admission_application.rb para atualizar o valor do model Student na hora de transformar candidatura em Student
models/admissions/filled_form_field.rb para adicionar validação
views/admissions/filled_form/edit/_generic_student_field.rb para mostrar os campos editáveis (talvez... pode ser que já esteja carregando direto do ActiveScaffold)

Mas só ter esses campos não garante que o aluno pediu cota nem que o aluno entrou por cota. Acho que essa informação da seleção deveria entrar em matrícula (enrollment). Podem ser duas flags a serem populadas manualmente na hora de transformar candidatura em matrícula. Ou melhor ainda: um campo para indicar se o aluno pediu cota (esse campo pode ser populado da mesma forma que número da matrícula é populado no edital - ou seja a partir de um campo preenchido em algum dos formulários, com isso conseguiriamos popular automaticamente a partir de um form de consolidação) e um campo pré-preenchido com o nome do seletor de ranking (também pode ser um campo configurável no edital, já que o seletor de ranking fica salvo como campo)

@leomurta, me parece que isso tem duas questões diferentes que seria bom ter no SAPOS. Que tal quebrarmos a issue?

leomurta commented 4 months ago

@JoaoFelipe , no form de homologação temos a seguinte info:

O Hélio marca essas checkboxes para indicar que o candidato apresentou a autodeclaração. O ideal seria pegar a info daí, né?

Quanto a dividir a issue, ok por mim. Vc poderia fazer, já que tem mais claro o caminho da solução?

IgorMonardez commented 3 months ago

Deixa eu ver se entendi, nós vamos replicar o dado de skin_color e PCD para a tabela Student, certo? Mas eu não entendi sobre a questão de como isso entra na politica afirmativa... todo o candidato que não seja branco ou que seja PCD estaria optando pela politica afirmativa?

JoaoFelipe commented 3 months ago

Movi a parte de adicionar campos em aluno para a issue #477.

Nesta, vamos ficar com a parte de adicionar campos em matrícula. No caso, pensei em dois campos:

Seleção - campo de texto
Solicitou cota - estou em dúvida se é melhor um campo booleano ou um campo de texto que permita indicar quais cotas foram solicitadas.

Para preencher esse campos, pensei em fazer o mesmo que fazemos para o campo de número de matrícula: o processo seletivo passaria a ter uma configuração de qual é o campo de formulário que preenche esses campos da matrícula e na hora de criar matrícula, seria possível pegar o valor que já está salvo.

Para o campo de seletor, isso deve funcionar com bem pouco esforço de configuração: ao gerar o ranking das candidaturas, já é criado um campo de seletor no formulário salvo que poderia ser usado.

Para o campo de solicitou cota, precisariamos adicionar uma consolidação para transformar os checkboxes do print do Leo no campo que vai ser preenchido na matrícula.

Dessa forma, o sistema não ficaria preso aos tipos de cotas que temos atualmente e deixaria cada programa configurar da forma que atender melhor (ou mesmo não usar esses campos de seleção/solicitou cota).

O que acham?

leomurta commented 3 months ago

Acho que é por aí, João. Talvez trocaria só o nome dos campos. Pensei no seguinte:

Opção de ingresso: campo texto que indica todas as opções de política afirmativa do candidato que foram homologadas pela secretaria. Aqui pode ser "Ampla Concorrência", "Racial", "PcD" ou "Racial e PcD".
Vaga de Ingresso: campo texto, que indica o tipo da vaga efetivamente usada no ingresso, com as opções "Ampla Concorrência", "Racial" ou "PcD".

Outra opção seria não usarmos campo texto. Aí teríamos que pensar em um modelo de Tipo de Vaga onde cadastraríamos "Ampla Concorrência", "Racial" ou "PcD" e teríamos relacionamento entre Opção de Ingresso (N:M) e Vaga de Ingresso (N:1) com Tipo de Vaga.

Talvez essa solução seja interessante, pois seriam campos em Matrícula que poderiam ser cadastrados manualmente, com os valores disponíveis a partir do Tipo de Vaga. Mas, no caso do PGC, teríamos isso automático pegando do módulo de Seleção. Isso é verdade tb caso seja campo texto, mas aí não há garantia que sempre serão usados os mesmos valores (um cadastro pode ser com "Racial", outro com "racial", outro com "negro", etc.), levando a dificuldade em consultas.

leomurta commented 3 months ago

Deixa eu ver se entendi, nós vamos replicar o dado de skin_color e PCD para a tabela Student, certo? Mas eu não entendi sobre a questão de como isso entra na politica afirmativa... todo o candidato que não seja branco ou que seja PCD estaria optando pela politica afirmativa?

@IgorMonardez , são algumas camadas distintas. Vamos lá:

O candidato tem uma Raça/cor, que é informada na sua ficha de candidatura. Ele também pode ou não ser PcD, e isso é informado na sua ficha. Isso é um fato que precisamos ter registrado em Aluno (issue #477).
O candidato que é negro ou que é PcD pode (ou não) optar por concorrer a vagas reservadas para política afirmativa. Note que eu coloquei um "ou não", pois isso é uma opção. Se um candidato negro ou PcD não optar, irá concorrer na ampla concorrência.
A secretaria homologa as inscrições e verifica se há tal opção feita pelo candidato, com a devida assinatura. Nesse momento, é uma auto-declaração. Mas em breve a UFF vai iniciar processo de heteroidentificação, onde haverá uma banca para aprovar ou não a opção. Então o que vale para aquele edital é o que a secretaria indicou na homologação, e não o que o candidato indicou na candidatura. Essa informação aqui povoaria o campo "Opção de ingresso" que eu comentei no post anterior.
A classificação dos candidatos segue um conjunto de critérios definidos no edital, que, por sua vez, seguem regras da UFF. Se um candidato optante fica em 1o, ele ocupa vaga de ampla concorrência. Até o limite das vagas de ampla concorrência, não interessa se o candidato é optante ou não. Só quando terminam as vagas de ampla concorrência que iremos classificar os candidatos optantes. Essa informação de qual vaga que o candidato efetivamente ocupou iria para o campo "Vaga de ingresso" que comentei no post anterior.

Enfim, podemos ter aluno negro que não optou por política afirmativa. Podemos ter aluno negro que optou mas que efetivamente não usou, pois ficou nas primeiras posições e entrou em vaga de ampla concorrência. Por isso precisamos de tantos campos, para mapear claramente as situações.

Se tiver restado dúvida, pergunte.

IgorMonardez commented 3 months ago

Interessante. Para resumir, os requisitos dessa tarefa seriam formar uma nova tabela Tipo de Vaga que vai se relacionar com Enrollment através dos atributos - Opção de ingresso(N-M) e Vaga de ingresso(N-1), onde a esquerda é Enrollment e direita Tipo de Vaga. Para povoarmos os dados antigos que ainda está um pouco obscuro para mim sobre a fonte desses dados hoje.

leomurta commented 3 months ago

@IgorMonardez , a meu ver, é isso. Para os dados antigos, talvez a migration possa pegar nas candidaturas que já foram processadas e aceitas, mas é algo mais desafiador, pois essa migration será muito customizada para nós (o que é razoável, pois provavelmente só nós teremos dados antigos). Possivelmente teríamos que ignorar caso a migration rodasse sobre um BD que não tem candidaturas. Acho que o @JoaoFelipe vai conseguir nos ajudar a pensar nisso tb...

JoaoFelipe commented 3 months ago

Essa migration vai ser complicada mesmo... Como o form é dinamico, teremos que ver exatamente qual id de cada campo que queremos e só temos dados de 1 seleção no SAPOS. Talvez faça mais sentido um cadastro manual do que tinha antes.

leomurta commented 3 months ago

Pode ser manual. Não é tanta gente assim. A menos que demore para termos isso pronto. Aí teremos 2 seleções... :)

IgorMonardez commented 3 months ago

Beleza, então a tarefa é basicamente criar os modelos, fazer as verificações e criar o formulário.

Em sáb., 8 de jun. de 2024 22:41, Leonardo Gresta Paulino Murta < @.***> escreveu:

Pode ser manual. Não é tanta gente assim.

— Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/461#issuecomment-2156263415, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU3E3EUGWYDOSQWLJPEDIQTZGOXETAVCNFSM6AAAAABH2WSA5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGI3DGNBRGU . You are receiving this because you were mentioned.Message ID: @.***>

leomurta commented 3 months ago

Não é só isso, Igor. Ao final do processo seletivo, os candidatos aprovados são entrada para criação automática de alunos/matrículas. Nesse processo, precisamos preencher os novos campos também. Note que isso não é um migration do Rails. O migration seria para povoar com os dados dos processos seletivos que já passaram. Isso é uma funcionalidade que já existe que precisa ser adaptada, para povoar os novos campos daqui para frente quando o aluno/matrícula é criado a partir de um candidato aprovado. Para complicar, esse povoamento precisa ser flexível, já que os campos do form de seleção são configuráveis.

Eu acho que é melhor vc iniciar pela issue #477 , pois me parece algo mais simples e mais alinhado ao que já está implementado. Além disso, vai ajudar vc a entender melhor o problema.

leomurta commented 3 months ago

Pode ser manual. Não é tanta gente assim. A menos que demore para termos isso pronto. Aí teremos 2 seleções... :)

@IgorMonardez , o que eu falei que pode ser manual aqui é a migração dos dados que já estão no BD. Mas o povoamento de aluno/matrícula a partir de candidato para os processos seletivos futuros tem que ser automático.

IgorMonardez commented 2 months ago

Boa tarde, voces sabem onde está esse formulário não consigo achar aqui no sistema.

Essa migration vai ser complicada mesmo... Como o form é dinamico, teremos que ver exatamente qual id de cada campo que queremos e só temos dados de 1 seleção no SAPOS. Talvez faça mais sentido um cadastro manual do que tinha antes.

IgorMonardez commented 2 months ago

@JoaoFelipe , no form de homologação temos a seguinte info:

O Hélio marca essas checkboxes para indicar que o candidato apresentou a autodeclaração. O ideal seria pegar a info daí, né?

Quanto a dividir a issue, ok por mim. Vc poderia fazer, já que tem mais claro o caminho da solução?

Mais precisamente esse aqui

helioaga commented 2 months ago

Boa tarde, Igor!

Acho que é o "formulário para homologação" (está no módulo "Seleção>Formulários"):

[image: image.png]

At.te, Helio

Em ter., 30 de jul. de 2024 às 09:12, Igor Monárdez < @.***> escreveu:

@JoaoFelipe https://github.com/JoaoFelipe , no form de homologação temos a seguinte info: [image: image] https://private-user-images.githubusercontent.com/304759/337787729-9c213683-5a78-4f27-967c-6efef1e6c2a7.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjIzNDA1MzUsIm5iZiI6MTcyMjM0MDIzNSwicGF0aCI6Ii8zMDQ3NTkvMzM3Nzg3NzI5LTljMjEzNjgzLTVhNzgtNGYyNy05NjdjLTZlZmVmMWU2YzJhNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNzMwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDczMFQxMTUwMzVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kMDNmOTVhY2FhZGMzN2U5OWNhOGRmNGU0YTY2M2RiOWQ0YzEyYWQwMWU3YWNhZmZlNWQwYjU0MDVmZWVmNDM4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.ZnMBxxGBUkZ3_XbXSLf4s_sdmVfM0P3pSAnMHUGVdOA O Hélio marca essas checkboxes para indicar que o candidato apresentou a autodeclaração. O ideal seria pegar a info daí, né?

Quanto a dividir a issue, ok por mim. Vc poderia fazer, já que tem mais claro o caminho da solução?

Mais precisamente esse aqui

— Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/461#issuecomment-2258201653, or unsubscribe https://github.com/notifications/unsubscribe-auth/BIRIKF5OL2BFQPQ5XFCK423ZO57K3AVCNFSM6AAAAABH2WSA5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJYGIYDCNRVGM . You are receiving this because you were mentioned.Message ID: @.***>

IgorMonardez commented 2 months ago

Entendi, só para esclarecer um pouco mais sobre a utilização desses formulários, eles são usados aonde e para onde vão os dados resultantes dele?

leomurta commented 2 months ago

Esses forms são do módulo de seleção de candidatos ao mestrado e doutorado. São dinâmicos (criados pelo admin do Sapos) e tanto os candidatos preenchem com seus dados quanto o Hélio preenche homologando as candidaturas quanto o comitê de avaliação preenche com notas.

João, pode complementar com a parte técnica de como o Igor pode fazer para mapear?

Em ter., 30 de jul. de 2024 às 17:37, Igor Monárdez < @.***> escreveu:

Entendi, só para esclarecer um pouco mais sobre a utilização desses formulários, eles são usados aonde e para onde vão os dados resultantes dele?

— Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/461#issuecomment-2259165367, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACKM53ZCX6OKXGGGR7EBR3ZO72PJAVCNFSM6AAAAABH2WSA5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJZGE3DKMZWG4 . You are receiving this because you were mentioned.Message ID: @.***>

gems-uff / sapos

Políticas afirmativas #461