Contribuir al Centro de Ayuda de VaultPAM

Esta guía explica cómo escribir y editar artículos en el Centro de Ayuda de VaultPAM. Abarca voz y tono, estructura de artículos, convenciones de capturas de pantalla y el proceso de solicitud de cambios. No necesita un entorno de desarrollo local para proponer un cambio: el editor web de GitHub es suficiente para la mayoría de las ediciones.

---

1. Voz y tono

Escriba para la persona operador: un profesional que gestiona el acceso privilegiado diariamente y necesita respuestas precisas y orientadas a tareas rápidamente. El estilo de escritura sigue estos principios:

• Orientado a tareas. Comience con el objetivo del usuario, no con teoría de fondo. Coloque el "qué" y el "cómo" antes del "por qué".
• Segunda persona. Dirígase al lector como "usted". Evite "el usuario" o "se debe".
• Voz activa. "Haga clic en Conectar" no "Se debe hacer clic en el botón Conectar".
• Lenguaje simple. Prefiera oraciones cortas. Evite jerga a menos que sea terminología específica de VaultPAM que ya tenga un artículo en la sección Conceptos.
• Inclusivo. Evite expresiones idiomáticas que no se traduzcan bien. Escriba de una manera que funcione igualmente bien para hablantes del inglés como lengua materna y como segunda lengua.
• Específico. Nombre elementos exactos de la interfaz de usuario en negrita (**Guardar**, pestaña **Conectores**). Incluya mensajes de error exactos en bloques de código.

Mapa de personas

Persona	Quiénes son	Cambio de tono
Evaluador	Recién registrado; primera sesión	Apoyo adicional; agregar listas de verificación "Antes de comenzar"
Operador	Usuario diario; lanzamiento de sesiones, aprobaciones	Conciso; conocen el producto
Administrador	Configuración de organizaciones, políticas, MFA	Preciso; necesitan nombres y valores exactos de campos
Administrador autohospedado	Administrador detrás de un cortafuegos	Tenga en cuenta las restricciones sin conexión; marque funciones solo en la nube
Ingeniero de soporte	Resolución de tickets	Secciones vinculables profundamente; incluya códigos de error exactos

---

2. Estructura de artículos

Cada artículo debe incluir el bloque frontmatter y seguir el orden de secciones a continuación.

Frontmatter (requerido)

---
title: Título corto, imperativo (p. ej., "Conectar un Connector")
description: Resumen de una oración para SEO e índice de búsqueda.
persona: operator          # uno de: evaluator, operator, admin, self-hosted-admin, support
category: how-to           # uno de: get-started, how-to, concepts, reference, troubleshooting, release-notes, security-compliance, admin
last_reviewed: "YYYY-MM-DD"
applies_to_versions: ["v1"]
keywords: [connector, rdp, session]
---

Los seis campos son obligatorios. El pipeline de compilación emite una advertencia para cualquier campo faltante. Una vez que el flujo de trabajo de autoría sea maduro, el gate de CI tratará las advertencias como errores.

Orden de secciones

1. Título (H1) — coincide con el title del frontmatter.
2. Párrafo de resumen breve — 1–3 oraciones: qué logrará el lector y cuándo usar este artículo. Sin encabezado H2.
3. Antes de comenzar (H2 opcional) — requisitos previos, permisos requeridos, enlaces a artículos de configuración. Use una lista de verificación (- [ ]).
4. Pasos (H2 para cada tarea principal) — pasos numerados (1., 2., …). Una acción por paso. Coloque el resultado esperado al final de un paso cuando no sea obvio.
5. Solución de problemas (H2 opcional) — lista de pares "Problema / Solución". Use un estilo de lista de definiciones o una tabla.
6. Artículos relacionados (H2 opcional) — 3–5 enlaces de viñeta a documentos relacionados. Use enlaces relativos al sitio ([Agregar un Safe](/how-to/add-safe), etc.).

Esqueleto de ejemplo

---
title: Aprobar una Solicitud de Sesión
description: Cómo aprobar o rechazar una solicitud de aprobación de sesión RDP entrante en VaultPAM.
persona: operator
category: how-to
last_reviewed: "2026-05-12"
applies_to_versions: ["v1"]
keywords: [approval, session, rdp]
---

# Aprobar una Solicitud de Sesión

Cuando un usuario solicita una sesión RDP que requiere aprobación, recibe una notificación en VaultPAM. Este artículo le muestra cómo revisar y aprobar o rechazar esa solicitud.

## Antes de comenzar

- [ ] Tiene el rol **Aprobador** en el Safe relevante.
- [ ] La solicitud de sesión no ha expirado (TTL predeterminado: 10 minutos).

## Aprobar la solicitud

1. Abra **VaultPAM** y haga clic en **Aprobaciones** en la barra lateral.
2. Localice la solicitud pendiente y haga clic en **Revisar**.
3. Compruebe los campos **Destino**, **Solicitante** y **Justificación**.
4. Haga clic en **Aprobar** o **Rechazar**.

El solicitante recibe una notificación dentro de la aplicación inmediatamente.

## Solución de problemas

**Falta el menú Aprobaciones.**
No tiene el rol Aprobador. Pida a su administrador de VaultPAM que lo agregue como aprobador en el Safe relevante.

## Artículos relacionados

- [¿Qué es un Safe?](/concepts/what-is-a-safe)
- [Aprobar una sesión pendiente](/how-to/approve-session)
- [Compartir una grabación](/how-to/share-recording)

---

3. Convenciones de capturas de pantalla

Las capturas de pantalla ayudan a los operadores a reconocer el elemento correcto de la interfaz de usuario de un vistazo. Siga estas reglas para mantener las capturas de pantalla mantenibles y accesibles.

Regla	Detalle
Formato	Solo PNG. No use JPEG o WebP (los artefactos de compresión oscurecen el texto de la interfaz de usuario).
Ancho máximo	1024 px. Exporte a densidad de píxel 1x (no 2x/Retina) para mantener el tamaño del archivo por debajo de 200 KB.
Recortar ajustadamente	Muestre solo el área relevante. Evite capturas de pantalla de navegador completo a menos que sea necesario el contexto completo de la ventana gráfica.
Enmascarar datos sensibles	Desenfoque o reemplace cualquier nombre de host, dirección IP, nombre de usuario o token visible en la captura de pantalla. Use un cuadro de color sólido, no una superposición de texto.
Texto alternativo	Obligatorio en cada imagen. Describa lo que muestra la captura de pantalla, no lo que desea que haga el lector. Ejemplo: Captura de pantalla del panel Aprobaciones mostrando una solicitud pendiente con un botón Aprobar.
Nombre de archivo	[article-slug]-[step-number]-[short-label].png, p. ej., connect-connector-01-enrollment-token.png.
Ruta de almacenamiento	Coloque imágenes en docs/help/img/[article-slug]/.

Markdown de imagen

![Captura de pantalla de la página Conectores mostrando un conector con estado En línea.](img/connect-connector/connect-connector-01-enrollment-token.png)

---

4. Proceso de solicitud de cambios

Opción A — Editar a través del editor web de GitHub (recomendado para cambios solo de contenido)

Cada artículo publicado tiene un enlace Editar esta página en la parte inferior. Al hacer clic en él, se abre el editor web de GitHub completado previamente con el archivo y rama correctos.

1. Haga clic en Editar esta página en la parte inferior del artículo.
2. Realice sus cambios en el editor.
3. En el panel Proponer cambios, escriba un mensaje de commit breve (p. ej., fix typo in session approval steps).
4. Haga clic en Proponer cambios → Crear solicitud de cambios.
5. En el formulario de solicitud de cambios, establezca el título para describir el cambio (p. ej., Fix typo in approve-session article). No se requiere clave de incidencia para correcciones de contenido puro.
6. Envíe la solicitud de cambios. Un comentario de vista previa se publica automáticamente con la URL de documentación de desarrollo con alcance de solicitud de cambios en https://dev.euwarden.com/docs/pr-<n>/: el enlace aparece en la solicitud de cambios dentro de unos minutos.

Opción B — Rama desde un incidente Jira (para trabajo de características o rediseño estructurado)

Cuando un cambio del centro de ayuda se rastrean bajo un incidente Jira (p. ej., agregar un nuevo artículo vinculado a un lanzamiento de características):

• Nombre de rama: AIC-XXXX-help-<slug> (p. ej., AIC-1234-help-connector-offline-guide).
• Prefijo de mensaje de commit: AIC-XXXX: <description>.
• Título de solicitud de cambios: [AIC-XXXX] Add connector-offline troubleshooting article.

Las solicitudes de cambios solo de documentos (sin cambios de código) pueden dirigirse directamente a main. La clave del incidente de Jira es opcional para correcciones de tipografía/redacción.

Revisión y fusión

CODEOWNERS solicita automáticamente revisión de @OWL-Management/product-analysts y @OWL-Management/pm para todas las solicitudes de cambios que toquen docs/help/**. Una solicitud de cambios debe recibir al menos una aprobación antes de poder fusionarse.

SLA de revisión: los revisores de contenido tienen como objetivo responder dentro de 2 días hábiles. Si una solicitud de cambios es urgente (p. ej., corregir una inexactitud que bloquea el soporte), agregue la etiqueta help-urgent y avise al canal Slack #docs.

URL de vista previa

Cada solicitud de cambios que modifique docs/help/** o docs-site/** activa una compilación de vista previa. CI publica la URL de documentación de desarrollo con alcance de solicitud de cambios (https://dev.euwarden.com/docs/pr-<n>/) como comentario fijo de solicitud de cambios dentro de aproximadamente 3 minutos.

Los entornos de vista previa no son indexados por motores de búsqueda (la etiqueta meta noindex está configurada).

---

5. Lista de verificación antes de enviar una solicitud de cambios

• Frontmatter tiene los seis campos obligatorios: title, description, persona, category, last_reviewed, applies_to_versions.
• last_reviewed es la fecha de hoy.
• Todas las capturas de pantalla son PNG, máximo 1024 px de ancho, con texto alternativo.
• Los datos sensibles en las capturas de pantalla están enmascarados.
• Los encabezados siguen el orden de secciones (sin H1 dentro de un bloque de paso).
• Los enlaces internos usan rutas relativas al sitio (comienzan con /).
• Sin enlaces rotos (la compilación de Docusaurus advertirá sobre enlaces rotos).
• URL de vista previa verificada y el artículo se renderiza correctamente.