Fuentes de señales de trabajo
Conecta GitLab para que los borradores de IA citen trabajo real entregado. Obtención bajo demanda, con privacidad acotada, opt-in por borrador y nunca un almacén de vigilancia.
Por qué importa
Las evaluaciones escritas de memoria infravaloran de forma sistemática a quien entrega con constancia y sin ruido, y sobrevaloran a quien fue visible el último mes. La solución no es la vigilancia. Es dejar que el redactor de IA cite trabajo real al redactar el borrador: las merge requests que alguien entregó y las revisiones que hizo para otros, como títulos y enlaces que después sopesa un evaluador humano.
Kit obtiene las señales de trabajo bajo demanda cuando el evaluador activa el opt-in para un borrador. No mantiene una base de datos aparte de actividad en bruto. Sí conserva en la evaluación un resumen de las señales usadas, con títulos, enlaces, fechas, repositorios y anotaciones relacionadas con la IA. No existe ninguna clasificación de productividad ni vista de comparación de actividad entre empleados.
Warning
Las señales producen pruebas narrativas, nunca puntuaciones. No se recogen métricas de volumen ni estadísticas de diffs, no existe ninguna superficie de comparación entre personas y la obtención es opt-in por borrador. Comenta las fuentes con la persona evaluada. Si buscas una clasificación de productividad, esta función no te la va a dar.
Conectar GitLab
GitLab es el proveedor de la v0 (una conexión por cuenta). Ve a Performance > Work signals:
| Campo | Valor |
|---|---|
| GitLab URL |
https://gitlab.com, o la URL de tu instancia autoalojada; el autoalojamiento es compatible (HTTPS, host accesible públicamente) |
| Group access token | Un Group Access Token read_api con el rol Reporter, o un PAT de cuenta de servicio en el plan Free |
Pulsa Connect GitLab (conectar GitLab). El token se cifra en reposo y después solo se muestra enmascarado. Kit usa acceso de API de solo lectura; nunca escribe en tu GitLab. Si la conexión falla más adelante (token revocado, host inaccesible), la fuente pasa a Error con el mensaje del fallo visible; vuelve a introducir las credenciales para reconectar. Si una obtención falla durante la redacción, el borrador usa las fuentes restantes y anota la fuente no disponible. Los borradores posteriores omiten una fuente en estado Error hasta que la reconectes.
Confirmar identidades
Las señales se obtienen por persona, así que cada miembro del equipo debe estar asociado a su nombre de usuario de GitLab, y la asociación debe estar confirmada por un administrador antes de usarse siquiera una vez. Esta es la valla contra el fallo obvio: un nombre de usuario con una errata jamás debe traer la actividad de un desconocido a la evaluación de alguien. Las asociaciones sin confirmar se rechazan en el momento de la consulta, sin excepciones.
En Identity mapping (asociación de identidades), añade el nombre de usuario de GitLab de cada miembro (Kit sugiere uno buscando a la persona por correo en tu GitLab cuando puede) y confírmalo después. Los miembros sin asociación confirmada se omiten en silencio al redactar; no se consulta nada sobre ellos.
Qué se obtiene
Al redactar el borrador, con el opt-in de ese borrador marcado, Kit consulta para el periodo evaluado (el periodo del ciclo o, si no está definido, los últimos 6 meses):
| Señal | Significado |
|---|---|
| Merge requests fusionadas | El trabajo que la persona entregó |
| Actividad de revisión | Las MR que la persona revisó para otros: el trabajo de cohesión que la mayoría de las herramientas ignora |
Cada señal incluye título, enlace, fecha y repositorio, más el tipo de actividad y las anotaciones descritas a continuación. Ni tamaños de diff, ni recuentos de líneas, ni frecuencias de commits. Sobre la marcha se derivan dos anotaciones de la era de la IA: autoría de IA (trailers de commit como Assisted-by:/Co-Authored-By: que nombran agentes de código; el redactor reconoce la dirección y el rigor de revisión, nunca el volumen inflado) y trabajo de habilitación de IA (cambios en skills, configuraciones de agentes, herramientas MCP, prompts: trabajo que el redactor tiene instrucciones de reconocer de forma explícita).
Opt-in, transparencia y rechazo
- Opt-in por borrador: las señales se usan solo cuando el evaluador marca «Include work signals from GitLab (opt-in for this draft)». Nunca por defecto, nunca de forma encubierta.
- Transparencia de fuentes: el evaluador ve junto al borrador los títulos, enlaces, fechas y repositorios conservados. La persona evaluada no tiene acceso automático a este panel en la evaluación de otra persona. Comenta las fuentes con ella antes de la finalización.
- Barrera humana posterior: un borrador informado por señales sigue pasando por la barrera de envío de editar-o-asumir; las señales informan la valoración de una persona, nunca se convierten en la valoración.
- El trabajo invisible para las herramientas tiene su canal: el campo Your own notes de la autoevaluación existe precisamente porque la mentoría, los incidentes y desbloquear a otros no aparecen en un repositorio de código.
Note
Para clientes en Alemania: la cogestión del comité de empresa (BetrVG §87(1) Nr. 6) cubre los sistemas capaces de monitorizar el desempeño. Involucra a tu comité de empresa antes de conectar una fuente.
En resumen
- Crea en GitLab un Group Access Token read_api (rol Reporter)
- Conéctalo en Performance > Work signals, gitlab.com o autoalojado
- Asocia y confirma el nombre de usuario de GitLab de cada miembro
- Cuenta al equipo que las señales existen y son opt-in por borrador, nunca un uso encubierto
- Recuerda a las personas evaluadas que usen Your own notes para el trabajo que GitLab no ve
Y ahora qué
- Evaluaciones redactadas con IA: donde las señales afloran
- Descripción general de las evaluaciones de desempeño: cómo encaja la capa de señales en el módulo completo