Cómo funciona un pedido, de la ficha al postmortem

Un pedido es del proyecto. Quien opera decide qué se hace, cuándo está terminado y firma. Los fessionals ponen el cómo y las horas. Ningún fessional cierra una etapa.

Quiénes. Quien opera (con 2 horas semanales acordadas) y su suplente, nombradas en la ficha. Dos fessionals: el referente técnico (convoca, mergea, lleva el repo) y la segunda (revisa, mantiene CAMBIOS.md, suplanta). Un rol por persona. Sin las cuatro firmas no hay fecha. Quien trajo el proyecto es puente: presenta, coordina y convoca hasta la sesión 0; puede ser referente de esa primera etapa si quien opera consiente; después es una voz más. Traer no da liderazgo.

Dos maneras de entrar (27/10/2026). a, traer un proyecto: una organización socio-ambiental de tu localidad, vivas donde vivas, con alguien que la opere y esté dispuesto a firmar la ficha; se cuenta en el formulario como se pueda (texto, audio o foto del papel). b, anotarse a dos pedidos de /jects: quien entra así es segunda de esos pedidos, no abre pedidos nuevos y arranca por videollamada: escucha el audio de la sesión 0, lee SESION0.md y firma el acuerdo antes de tocar datos. Los pedidos sin firma se pueden elegir desde ya, pero arrancan cuando el proyecto firme su ficha; hasta entonces, la anotación espera. Si alguien de b más adelante trae un proyecto, pasa a a.

Encuentros. Seis horas en doce semanas: una llamada corta entre los dos fessionals para repartirse roles; sesión 0 presencial de dos horas, en lugar y horario del proyecto, con quien trajo el proyecto y quien opera (la segunda que entró por b la escucha grabada, con permiso de quien opera, y la hace suya en la primera quincenal); cinco quincenales de quince minutos por llamada (qué cambió, qué bloquea, qué sigue; sin asunto escrito, se cancela); traspaso presencial de una hora. Las fechas: cada anotación trae las franjas libres de la semana como un código (lu-n,mi-t); quien convoca las cruza en /cruzar/, en su navegador, sin guardar nada, y propone día y hora en un issue del repo del proyecto, con nombre; para la sesión 0, tres fechas, lugar y orden del día (SESION0.md). Ningún sistema agenda; ningún servicio externo de agenda.

Las cinco etapas.

1. Pedido (semana 0, fuera del reloj): ficha y acuerdos firmados, con “financiamiento: no / sí, por hito”; repo del proyecto con dos owners. Cierra el proyecto.
2. Papel (semanas 1 y 2): sesión 0, en persona, sobre el cuaderno donde hoy se pierde todo: se dibuja cómo se carga, se busca y se corrige un dato, y quien opera se lo explica a un tercero con ese papel; si no lo entiende, no se programa; herramienta elegida de la lista corta; datos de prueba; SALIDA.md v0. Cierra quien opera.
3. Datos reales (3 a 6): commits semanales; en la semana 4 quien opera carga datos reales ella misma; exportación a CSV; copia hecha y restaurada; DESPLIEGUE.md ejecutado por ella; si hay financiamiento, primer hito. Cierra quien opera.
4. Sola (7 a 10): quien opera cambia algo sin la dupla y lo anota; MANTENIMIENTO.md. Cierra quien opera.
5. Traspaso (11 y 12): contraseñas en el proyecto, fessionals sin permiso de escritura, SALIDA.md final, postmortem público firmado por quien opera. Cierra el proyecto. “Lo sigo usando” a los tres meses no es etapa: es la prueba.

Registro. La memoria de un pedido son archivos de texto en el repo canónico del proyecto: PEDIDO.md, SESION0.md, CAMBIOS.md, DESPLIEGUE.md, MANTENIMIENTO.md y SALIDA.md. Nada vive en otro lado. La unidad es el avance: cualquier cambio que deje al pedido más cerca de lo que tiene que quedar andando (una columna menos en la planilla, una copia restaurada, una decisión tomada). Un avance es un commit y una línea en CAMBIOS.md; el commit lleva quién (autor, con nombre o alias), cuándo y qué, y su hash corto es el id del avance. La historia completa queda y no se borra: lo que estuvo mal se revierte con otro avance, nunca reescribiendo el anterior. La escribe quien hizo el cambio; quien opera firma cada cierre de etapa, y si no tipea, dicta y su línea dice “dictó”. La ficha en sidepro muestra etapa, fecha y link al repo; no duplica.

Concurrencia. Nadie escribe sobre lo que no leyó: la rama principal está protegida, se entra por PR, y git rechaza un cambio hecho sobre una versión vieja del archivo. Lo garantiza GitHub, no la buena voluntad de nadie. El referente mergea, la segunda revisa, y lo que toca datos o DESPLIEGUE.md lo aprueba quien opera.

Permisos. Lo público de un pedido es cómo funciona: problema, qué hay, qué queda, stack, etapa, forma del acuerdo. Nombres de personas, fechas puntuales, montos y contactos viven en un repo privado de la organización sidepro, con lectura para quienes ya están anotados como fessionals y escritura para quien está en ese pedido. Lo compartido de sidepro (RFC, plantillas, convenciones) es solo lectura para todos, y se cambia por PR. Cada fessional escribe solo en los pedidos donde está, desde su fork, con su nombre en cada commit; al traspaso pierde la escritura y conserva el fork. Quien opera es owner del repo del proyecto desde el día uno, con su suplente como segundo owner.

Portabilidad. Son archivos: se clonan, se leen sin cuenta, se mudan a otro proveedor con un git push. La memoria viaja con cada quien: el fork del fessional lleva su nombre en el historial; el repo canónico queda con el proyecto; sidepro guarda un espejo público con el historial intacto. Cómo se arma el repo, en plantillas/REPO.md.

Stack. Lo que quien opera ya abre en su teléfono: formulario (KoboToolbox o Grist), base (Grist o NocoDB sin costo, o SQLite), exportación a CSV, sitio estático en GitHub Pages del proyecto, dominio del proyecto; plan B escrito. Nada que una persona del proyecto no pueda operar y modificar sin la dupla.

Si se cobra. Puede haber remuneración o no: depende del proyecto, de sus fondos, de su deseo o posibilidad de pagar, o de que consiga financiamiento. Si la hay, se escribe en la ficha antes de empezar: cuánto, por qué hito y en qué forma (con factura, o en especie con su valor en pesos, como un intercambio por alimentos). Se paga por lo entregado, no por hora de presencia; primero las horas de quien opera y el sistema del año 2; dónde fue cada peso, en SALIDA.md. Ningún acuerdo es precedente de otro. El pago no compra alcance, soporte después del traspaso ni derechos sobre el código. sidepro no cobra, no paga ni intermedia.

Si alguien falta. Quien se va, se va sin sanción, con traspaso documentado. Si quien opera no aparece, el pedido se pausa a los diez días y se renegocia a los treinta.

Plantillas. PEDIDO.md, SESION0.md, CAMBIOS.md, DESPLIEGUE.md, MANTENIMIENTO.md, SALIDA.md y REPO.md están en la carpeta plantillas/ del repo de sidepro.