Especificación del problema

• Crea una carpeta con el nombre del problema. Dentro, agrega el archivo settings.json siguiendo el ejemplo de problemas anteriores, y agrega una línea con la carpeta del problema a problems.json, que está en la raíz del proyecto.

  • El alias del problema en settings.json no se determina hasta que se escribe la redacción final. Puedes usar un alias temporal mientras tanto. (En la OFMI utilizamos dummy-ofmi.)
  • A partir de ahora, todas las instrucciones sobre escribir un problema se refieren a archivos dentro de la carpeta que acabas de crear.

• Escribe una descripción del problema en statements/es.markdown, pero no es la redacción final. Debe contener:

  • Descripción corta del problema. (Sin historia)
  • Descripción del formato de entrada y salida.
  • Descripción de las subtareas, de haber. Cada subtarea tiene que tener un identificador único que las distinga, de preferencia descriptivo en vez de sub1 o similares. (Más detalles en la sección de pruebas.)

• Agrega por lo menos un caso de prueba válido en cases: por ejemplo, el caso de ejemplo en cases/sample.0.in y cases/sample.0.out. El nombre no es estricto, pero es útil poder identificar los casos de ejemplo para los siguientes pasos.

  • Agrega un testplan que contenga esos casos y obtenga 100 puntos.

• Crea el archivo tests/tests.json para asegurarnos que el testplan suma 100 puntos. Su contenido debe ser el siguiente:

  {
    "max_score": 100
  }

• El primer caso de ejemplo que se vaya a incluir en la redacción debe ir en examples/sample.in y examples/sample.out (aquí el nombre sí es estricto). Todos los demás casos de ejemplo también deben ir en examples/, preferentemente con nombres que indiquen a qué se refieren. Para asegurarnos que los casos de ejemplo también sean validados, en vez de hacer nuevos archivos, haz symlinks hacia la carpeta de cases. Luego, para incluirlos en la redacción, se puede usar la siguiente sintaxis:

  ||examplefile
  sample
  ||description
  Aquí va la descripción del caso de ejemplo. Nota que arriba no se usó el
  nombre del directorio `examples/` ni la extensión de los archivos.
  ||examplefile
  caso_sin_descripción
  ||examplefile
  caso_más_complicado
  ||description
  No es necesario agregar una descripción en cada caso, pero se recomienda que
  se haga.
  ||end

• Al hacer el PR, asegúrate que el nuevo problema sí fue procesado por el sistema de integración continua.

Checklist de revisión

• El problema está en problems.json.
• settings.json: Visibilidad privada.
• settings.json: Alias dummy.
• settings.json: Permisos en omegaUp para el grupo adecuado.
• Redacción en statements/es.markdown.
• Hay al menos un caso de ejemplo en cases.
• testplan sumando 100 puntos.
• examples/sample.{in,out} apuntan al caso correcto.
• tests.json existe y checa el score del problema.
• Los logs del pull request dicen que el problema fue verificado.