How a request works, from the request page to the postmortem

A request belongs to the project. The operator decides what gets done and when it is finished, and signs. The fessionals bring the how and the hours. No fessional closes a stage.

Who. The operator (with 2 agreed hours a week) and their alternate, named in the request. Two fessionals: the tech lead (convenes, merges, keeps the repo) and the second (reviews, keeps CAMBIOS.md, stands in). One role per person. Without the four signatures there is no date. Whoever brought the project is a bridge: introduces, coordinates and convenes until session 0; they can lead that first stage if the operator agrees; after that they are one more voice. Bringing a project doesn’t grant leadership.

Two ways in (2026-10-27). a, bring a project: a socio-environmental organization from where you live, wherever that is, with someone who operates it and is willing to sign the request; you tell it in the form however you can (text, audio or a photo of the paper). b, sign up for two requests in /jects: whoever comes in this way is the second on those requests and doesn’t open new ones; if they arrive after session 0, they listen to its recording, read SESION0.md and sign the agreement before touching any data. Unsigned requests can be chosen now, but they start when the project signs; until then, the sign-up waits. If someone from b later brings a project, they move to a.

Meetings. Six hours in twelve weeks, all online: a short call between the two fessionals to split roles; a two-hour session 0 by video call, at the project’s time, with whoever brought the project and the operator, recorded with the operator’s permission for whoever joins later; five fifteen-minute calls every two weeks (what changed, what’s blocking, what’s next; with nothing written down, it’s cancelled); a one-hour handover. Dates: each sign-up brings the week’s free slots as a code (lu-n,mi-t); whoever convenes cross-checks them in /cruzar/, in their browser, storing nothing, and proposes a day and time in an issue in the project’s repo, with their name; for session 0, three dates, a place and an agenda (SESION0.md). No system schedules; no external scheduling service.

The stages. Stages 0 and 1 are off the clock; the twelve weeks start at stage 2.

Stage 0 · Description. The fessional who brings the project describes, in a few lines, the organization and the need as they see them from outside. They write out separately each assumption they haven’t confirmed with the organization yet.

• That description is what the form asks for when “I bring an organization” is chosen.
• Whoever signs up leaves their X link and gets a code (sidepro-XXXX) to verify the account is theirs: they put it in their bio for a while or post it, with three texts to choose from. Posting is optional; the bio is enough. Whoever answers checks it before stage 1.
• The template plantillas/DESCRIPCION.md asks for the same as the form: what the organization is, what it does and for whom, where, what gets lost or is hard today, and the assumptions to validate: what the fessional thinks the organization needs to run better.

Stage 1 · Discovery. The fessional meets the organization with the plantillas/RELEVAMIENTO.md sheet. It has three parts:

1. The stage 0 assumptions, each marked as confirmed, wasn’t so, or changed, with what the organization said.
2. A “before you leave, check you know this” list, answered in the organization’s own words:
   • the problem and how often it happens;
   • how much, as a rough volume;
   • how they do it today and where it breaks;
   • who does it and how many hours it takes;
   • what happens when it goes wrong and what they’ve already tried;
   • what they have to work with;
   • the one thing that has to keep running, and what it is not;
   • who would operate it;
   • whether there is sensitive data;
   • whether there is or could be pay.
3. The need described in three to five sentences, which the organization reads and confirms with a “yes, that’s it”. With that it writes and signs its PEDIDO.md, with “funding: no / yes, per milestone”, and the project repo is created with two owners. That closes stage 1; the project closes it.

Stages 2 to 5.

1. Paper (weeks 1 and 2): session 0, online, with the notebook or spreadsheet where everything gets lost today on screen: draw how a record is entered, found and corrected, and the operator explains it to a third person with that paper; if they don’t get it, nothing gets coded; tool chosen from the short list; test data; SALIDA.md v0. Closed by the operator.
2. Real data (3 to 6): weekly commits; in week 4 the operator loads real data herself; CSV export; backup made and restored; DESPLIEGUE.md run by her; if there is funding, first milestone. Closed by the operator.
3. Solo (7 to 10): the operator changes something without the pair and writes it down; MANTENIMIENTO.md. Closed by the operator.
4. Handover (11 and 12): passwords with the project, fessionals without write access, final SALIDA.md, public postmortem signed by the operator. Closed by the project. “I still use it” three months later is not a stage: it is the test.

Log. A request’s memory is text files in the project’s canonical repo: PEDIDO.md, SESION0.md, CAMBIOS.md, DESPLIEGUE.md, MANTENIMIENTO.md and SALIDA.md. Nothing lives anywhere else. The unit is the step forward: any change that brings the request closer to what has to keep running (one column fewer in the spreadsheet, a restored backup, a decision taken). A step forward is a commit and a line in CAMBIOS.md; the commit carries who (author, with name or alias), when and what, and its short hash is the step’s id. The full history stays and is never deleted: what was wrong is reverted with another step, never by rewriting the previous one. Whoever made the change writes it; the operator signs each stage closure, and if she doesn’t type, she dictates and her line says “dictated”. The request page on sidepro shows stage, date and a link to the repo; it doesn’t duplicate.

Concurrency. Nobody writes over what they haven’t read: the main branch is protected, everything comes in by PR, and git rejects a change made on an old version of the file. GitHub guarantees it, not anyone’s good will. The tech lead merges, the second reviews, and anything touching data or DESPLIEGUE.md is approved by the operator.

Permissions. What is public about a request is how it works: problem, what exists, what has to keep running, stack, stage, form of the agreement. People’s names, specific dates, amounts and contacts live in a private repo of the sidepro organization, readable by those already signed up as fessionals and writable by whoever is on that request. What sidepro shares (RFCs, templates, conventions) is read-only for everyone and changes by PR. Each fessional writes only in the requests they are on, from their fork, with their name on every commit; at handover they lose write access and keep the fork. The operator is owner of the project’s repo from day one, with their alternate as second owner.

Portability. They are files: they get cloned, read without an account, and moved to another provider with a git push. The memory travels with each person: the fessional’s fork carries their name in the history; the canonical repo stays with the project; sidepro keeps a public mirror with the history intact. How to set up the repo, in plantillas/REPO.md.

Stack. Whatever the operator already opens on her phone: forms (KoboToolbox or Grist), database (Grist or NocoDB at no cost, or SQLite), CSV export, static site on the project’s GitHub Pages, the project’s domain; a written plan B. Nothing someone from the project can’t operate and change without the pair.

Pay. There may or may not be pay: it depends on the project, its funds, its wish or ability to pay, or on getting funding. If there is, it is written in the request before starting: how much, for which milestone and in what form (with an invoice, or in kind with its value in pesos, like an exchange for food). Payment is for what is delivered, not for hours of presence; first the operator’s hours and the year-2 system; where every peso went, in SALIDA.md. No agreement sets a precedent for another. Payment doesn’t buy scope, support after the handover or rights over the code. sidepro doesn’t charge, pay or intermediate.

If someone is missing. Whoever leaves, leaves without penalty, with a documented handover. If the operator doesn’t show up, the request is paused after ten days and renegotiated after thirty.

Templates. DESCRIPCION.md, RELEVAMIENTO.md, PEDIDO.md, SESION0.md, CAMBIOS.md, DESPLIEGUE.md, MANTENIMIENTO.md, SALIDA.md and REPO.md are in the plantillas/ folder of the sidepro repo (in Spanish).