Presentación

# Instrucións para crear un material educativo aberto

Estas instrucións proceden da guía «Vibe coding responsable», para publicar
materiais educativos creados con vibe coding
(https://vibe-coding-educativo.github.io/vibe-responsable/gl/).
Ségueas en todo o traballo, xunto co que che pida sobre o material que quero
crear. O material publicarase en aberto, para que outras persoas poidan
utilizalo e adaptalo.

## Antes de comezar

Se non cho dixen, pregúntame:
- A autoría que debe figurar (un nome ou un nome de usuario).
- Onde se publicará: a web dun chatbot, unha plataforma para crear
  aplicacións, ou un repositorio ou sitio propio.

## Como debe construírse

- Licenza: CC BY-SA 4.0 para os contidos e AGPL v3 para o código, agás que
  che indique outras.
- Se traballamos na web dun chatbot, fai o material como unha páxina HTML
  que funcione por si soa ao abrila no navegador, e non como un compoñente
  que só funciona dentro do chatbot.
- Podes utilizar bibliotecas, tipografías e outros recursos externos cando
  aforren traballo ou melloren o resultado. Cárgaos dun servizo coñecido e
  estable, e anótaos na nota de decisións, coa súa licenza. Se algo do
  material deixaría de funcionar ao abrilo descargado nun ordenador sen
  internet, dimo con palabras sinxelas, por exemplo: «se o abres sen
  internet, as fórmulas non se verán».
- Datos persoais: non pidas o nome nin ningún dato que identifique unha
  persoa, agás que a ferramenta o necesite para a súa función, como un
  caderno de notas. Nese caso gárdao só no dispositivo e ofrece a opción de
  exportar ou imprimir sen os nomes. Se o programa recolle respostas do
  alumnado, mostra o resultado ao rematar ou permite descargalo para
  entregalo, e identifica cada persoa cun código en lugar do seu nome. Non
  envíes nada a ningún servidor nin engadas analítica ou contadores de
  visitas.
- Accesible, seguindo as Pautas de Accesibilidade para o Contido Web
  (WCAG): manexable só co teclado, cunha orde de tabulación lóxica,
  etiquetas nos controis, textos alternativos nas imaxes, contraste
  suficiente, sen depender da cor para entender nada e lexible na pantalla
  dun móbil.
- Código lexible e comentado no idioma do material, sen comprimir, con
  nomes de variables comprensibles.
- Ao pé do material: o título, a autoría, a licenza coa súa ligazón e unha
  declaración breve de uso de IA, coa ferramenta, o mes e o ano, e o que eu
  comprobase (pregúntamo antes de publicar).
- Se incorporas imaxes, sons ou fragmentos de código doutras persoas,
  utiliza só material cuxa licenza permita a reutilización, e indica a súa
  autoría, a súa procedencia e a súa licenza dentro do propio material.
- Se o programa vai gardar datos do alumnado nos sistemas do centro, non
  escribas claves nin contrasinais no código que chega ao navegador, fai que
  só o docente ou o centro poidan ler o recollido e indícame que debe revisar
  unha persoa con coñecementos técnicos antes de poñelo en uso.
- Despois de cada cambio, volve comprobar o que xa funcionaba: executa as
  probas se as hai ou, se non podes facelo, dime que comprobacións debo
  repetir.

## Se se publica nun repositorio ou nun sitio propio

- Engade un ficheiro LICENSE coa licenza do código e outro coa dos
  contidos, e indica a licenza ao inicio de cada ficheiro de código cunha
  liña SPDX-License-Identifier.
- Engade un documento que explique como está organizado o proxecto e para
  que serve cada ficheiro.
- Leva un rexistro de decisións (ADR) dentro do proxecto, cun ficheiro por
  decisión que recolla o contexto, as alternativas descartadas e as
  consecuencias. Anota nel cada decisión que tomemos, sen esperar a que cho
  pida. Nas decisións técnicas, anota tamén en que te baseas (documentación
  oficial, unha versión concreta do código ou unha proba que se poida
  repetir), os riscos coñecidos e como o comprobaches. Non inventes fontes
  nin probas: o que non puideses comprobar, márcao como hipótese pendente de
  validación.
- Revisa a accesibilidade cunha ferramenta automática e corrixe o que
  detecte.
- Cando publiquemos unha versión, márcaa cunha etiqueta de versión (v1.0,
  v1.1…) e non movas nin reutilices despois unha etiqueta xa publicada.

## Cando remates o material

- Describe brevemente que fai o material, que garda e se se comunica con
  algún servizo externo.
- Prepara unha lista breve de comprobacións cos percorridos principais e os
  casos extremos, para repetila despois de cada cambio. Se o proxecto o
  permite, convértea en probas automáticas.
- Escribe unha nota breve coas decisións importantes que tomaches e o motivo
  de cada unha, ou resúmeas do rexistro de decisións se o hai.
- Indica que debo comprobar eu, empezando pola corrección dos contidos.

# Instrucións para avaliar un recurso educativo aberto (avaliación VCER)

Estas instrucións proceden da guía «Vibe coding responsable», para publicar
materiais educativos creados con vibe coding
(https://vibe-coding-educativo.github.io/vibe-responsable/gl/).
Serven para avaliar un recurso xa feito, propio ou doutra persoa, creado ou
non seguindo a guía.

## Como avaliar

- Traballa sobre o código do recurso que che dou. Se non o tes, pídemo antes
  de comezar.
- Non o corrixas: só avalíao.
- Puntúa cada un dos dez puntos con 2, 1 ou 0 segundo a rúbrica VCER (vibe
  coding educativo responsable), e xustifica cada puntuación cunha frase
  sobre o que viches no recurso.
- Se un punto non se pode comprobar co que che dei, déixao sen puntuar e di
  que faría falta para comprobalo.
- Antes de puntuar, fai inventario completo, non unha mostra: cada función
  que pide ou garda datos de persoas e como se exportan ou copian; cada
  imaxe, son, vídeo, icona e tipografía do proxecto, e de onde sae (mira as
  imaxes: un logotipo redebuxado segue sendo alleo); e todo o que se carga de
  fóra, e cando (ao abrir, ao premer algo ou nunha xanela nova).
- Se o recurso está publicado, avalía esa versión ou comproba que coincide
  co código que che deron. Anota que versión avaliaches: a etiqueta de
  versión e o commit se está nun repositorio, ou o enderezo e a data da
  avaliación se non o está.
- Para o punto 5, se podes executar código, abre o recurso nun navegador e
  pásalle unha ferramenta automática de accesibilidade, como axe-core, tamén
  con contido cargado e non só na pantalla inicial. Non contes o que se
  incrusta doutros sitios. A ferramenta non comproba o manexo co teclado:
  percórreo co tabulador. Na xustificación do punto, di que probaches e
  como; se só puideches ler o código, indícao.

## Rúbrica VCER

1. CONTIDO (eliminatorio)
   2: Non se detectan erros no que ensina: os datos, as definicións e as
      respostas que se dan por correctas.
   1: Hai algunha imprecisión menor no que ensina.
   0: Hai erros evidentes en conceptos, datos ou respostas.
   Esta puntuación só reflicte os erros que detectaches: enuméraos un por
   un e sinala o que convén que comprobe unha persoa. As gralladas e os
   fallos de formato das referencias non restan aquí: sinálaos á parte.

2. DATOS PERSOAIS (eliminatorio)
   2: Non pide datos que identifiquen a ninguén, ou gárdaos só no
      dispositivo e permite exportar sen nomes; ou envíaos unicamente a un
      servizo do centro, sen claves visibles no código e de forma que só o
      docente ou o centro poidan lelos. Non leva analítica.
   1: Non envía datos do alumnado a servizos alleos, pero garda nomes sen
      opción de exportar sen eles, ou o envío ao servizo do centro non está
      ben protexido (claves no código, un enderezo que permite ler o
      recollido).
   0: Envía datos do alumnado a un servidor alleo ao centro, ou leva
      analítica ou seguimento.
   Se o recurso manexa datos reais do alumnado, indica que convén a
   revisión dunha persoa con coñecementos técnicos antes de usalo.
   O que se carga ou se incrusta doutros servidores (vídeos, audios,
   tipografías, bibliotecas) valórase no punto 4, non aquí.

3. ENTENDER QUE FAI
   2: Pode describirse brevemente que fai, que garda e con que se comunica,
      e o que declara o material coincide co código.
   1: Enténdese o seu funcionamento, pero hai partes de propósito pouco
      claro ou non explica que garda.
   0: Hai funcións ou comunicacións cuxo propósito non se pode explicar, ou
      o que declara non coincide co código.

4. DEPENDENCIAS
   2: O que carga ou incrusta de fóra procede de servizos coñecidos e está
      anotado, e os textos, as imaxes e os datos propios están dentro do
      material.
   1: Carga ou incrusta recursos externos sen anotalos, ou parte do contido
      propio (un vídeo, un audio, un mapa) só está noutra plataforma.
   0: O contido principal depende dun servizo externo, ou carga código de
      enderezos descoñecidos.

5. ACCESIBILIDADE
   2: Manéxase enteiro co teclado, os controis teñen etiqueta, as imaxes
      texto alternativo, o contraste é suficiente, non depende da cor e
      adáptase a unha pantalla estreita.
   1: Falla nun ou dous deses aspectos, sen impedir o seu uso.
   0: Falla en tres ou máis, ou non se pode usar co teclado.

6. MATERIAL ALLEO
   2: Cada elemento alleo indica autoría, procedencia e licenza, e a
      licenza permite reutilizalo; ou non hai material alleo.
   1: Hai material alleo con licenza válida, pero sen acreditar de todo.
   0: Hai material alleo sen licenza que permita reutilizalo ou sen
      ningunha atribución.

7. RASTRO
   2: Hai un rexistro ou unha nota coas decisións importantes e o seu
      motivo.
   1: Hai documentación que explica como está feito, pero non por que.
   0: Non hai nada.

8. USO DE IA
   2: Indica que se fixo con IA e que comprobou a persoa.
   1: Indica que se fixo con IA, sen dicir que se comprobou.
   0: Non o indica. Se consta que non se usou IA, non se puntúa.

9. LICENZA
   2: Autoría e licenza libre visibles no material, con ligazón. Se é un
      proxecto de varios ficheiros, inclúe o ficheiro de licenza.
   1: Falta a autoría ou a licenza, a licenza non é libre (NC ou ND) ou non
      enlaza co seu texto.
   0: Non indica nin autoría nin licenza.

10. REUTILIZACIÓN
   2: O código pode obterse completo, enténdese ao lelo, con comentarios
      onde fan falta, e hai indicacións para modificalo.
   1: Pode obterse, pero é difícil de entender sen comentarios, está en
      parte comprimido ou non ten indicacións.
   0: Non pode obterse, ou está ofuscado ou comprimido.

## Resultado

- Calcula a porcentaxe: a suma das puntuacións dividida entre o máximo
  posible dos puntos puntuados.
- Dá un resultado: «Non recomendable» se o punto 1 ou o 2 teñen 0, sexa cal
  sexa a porcentaxe; «Mellorable» por debaixo do 70 %; «Recomendable» a
  partir do 70 %, sempre que os puntos 1 e 2 se puidesen puntuar e o punto
  5 non teña 0. Se algún dos puntos 1 e 2 quedou sen puntuar, o resultado é
  «Mellorable» e indica que falta por comprobar; se o punto 5 ten 0, tamén é
  «Mellorable» e indica que impide usalo.
- Comeza o informe cunha liña como «Rúbrica VCER: Recomendable (85 %)»,
  seguida doutra coa versión avaliada, e engade debaixo unha frase co que
  significa ese resultado:
  - Recomendable: cumpre o esencial da guía e pode utilizarse ou
    publicarse; as melloras propostas complétano.
  - Mellorable: ten fallos que convén corrixir antes de publicalo ou
    recomendalo, aínda que ningún o descarta.
  - Non recomendable: ten erros evidentes no que ensina ou envía datos do
    alumnado a servizos alleos ao centro; non convén utilizalo nin
    publicalo ata corrixilo.
- Na xustificación do punto 3, inclúe esa breve descrición. Na do 4,
  enumera os enderezos externos do código e para que serve cada un, e di con
  palabras sinxelas que deixaría de funcionar ao abrilo descargado nun
  ordenador sen internet. Na do 6, enumera o material alleo.
- Remata coas tres melloras que máis subirían a puntuación.

## Se o recurso é meu

- Fai isto só se o recurso é meu e podes modificar os seus ficheiros. Se non
  sabes se é meu, pregúntamo ao rematar o informe. Se é doutra persoa ou non
  podes modificar os seus ficheiros, non o menciones.
- Ofréceme estas dúas cousas e fai só as que aprobe:
  - Se o proxecto ten un cartafol propio, como un repositorio, gardar o
    informe completo nun ficheiro chamado evaluacion-vcer.md, que substitúe o
    dunha avaliación anterior.
  - Engadir ao pé do material, no seu idioma, unha mención co resultado,
    como «Avaliación VCER da versión 1.2: Recomendable (85 %), outubro de
    2026», ligada a un enderezo coma este:
    https://vibe-coding-educativo.github.io/vibe-responsable/vcer/?r=recomendable&p=85&f=2026-10&v=1.2&t=Fracci%C3%B3ns%20equivalentes&u=https%3A%2F%2Fejemplo.github.io%2Ffracciones%2F
- Na ligazón, r é o resultado (recomendable, mejorable ou no-recomendable,
  sempre nesta forma); p, a porcentaxe; f, o ano e o mes da avaliación; v,
  a versión avaliada; t, o título do recurso, o mesmo que figura no seu pé,
  e u, o seu enderezo. Codifica t e u como se fai nun enderezo web.
- Se o recurso non ten número de versión, quita «da versión 1.2» da mención
  e v da ligazón. Se non está publicado na web, quita u da ligazón.
- A porcentaxe é opcional: ofréceme a mención con ela e sen ela. Sen
  porcentaxe, quita «(85 %)» da mención e p da ligazón.
- Se xa hai unha mención, actualízaa co resultado novo.

## Se despois che pido corrixilo

- Antes de cambiar nada, dime que cambiarías e agarda a que o aprobe. Non
  cambies o contido nin o funcionamento, agás que cho pida.
- Se non hai nota de decisións, escribe unha que describa como funciona o
  recurso agora, e indica que se redactou despois.
- Se falta a licenza ou a indicación de uso de IA, prepárame o texto para
  engadilo.