Gestionar temas, revisión y estado de publicación en Google Sheets
Gestiona cada artículo como una fila y separa redacción, revisión, aprobación y publicación. Incluye la importación de un CSV local, listas desplegables, vistas de filtro, permisos de uso compartido e historial de versiones, y establece un flujo para actualizar manualmente los archivos del sitio después de la aprobación.
Contenido revisado 2026.09.19Incluye archivos de ejemplo
Ver el índice
La traducción se ha realizado con IA. Comprueba el código, las unidades y los valores junto con el original. La revisión por hablantes nativos de cada idioma aún no se ha completado. English
Para quién esRedactores y revisores que gestionan juntos un pequeño sitio de tutoriales o documentación interna de conocimiento
Preparación
Prepara los archivos descargados content-register.csv y README.txt.
El administrador decide qué cuentas de Google utilizará el equipo y quién será propietario del archivo. No se crearon ni conectaron cuentas para este artículo.
Acordad los roles de redacción, revisión y publicación, así como los criterios para cambiar el status.
01Poner la siguiente acción de un artículo en una sola fila
Con solo una lista de temas, resulta difícil saber qué borrador está en revisión y qué bloquea la publicación. Este ejemplo vincula article ID, audience, deliverable, writer, reviewer, status, evidence, privacy check, approval date, published URL y release version en una sola fila. El article ID se mantiene aunque cambie el título y se utiliza como clave para volver a localizar los registros.
02Definir primero qué significan las columnas y los statuses
Grupo de columnas
Qué registrar
Article ID · title · audience · deliverable
Qué problema se resuelve, para quién y qué recibe
Writer · reviewer · review due date
Roles y fechas que deben comprobarse
Status · next action
La etapa actual y lo que debe hacer la siguiente persona
Evidence · privacy check
Fuentes oficiales o una descripción del ejemplo sintético, y el resultado de la comprobación
Approval date · published URL · release version
Cuándo se aprobó y el resultado que realmente se publicó
Utiliza únicamente uno de estos statuses: idea, drafting, in review, changes requested, approved, published, on hold. approved es el registro del equipo de que la revisión ha terminado, y published es el registro de que se aplicó al sitio y se comprobó el resultado. Esta distinción es una regla operativa que hemos establecido, no un sistema de aprobación integrado en Sheets.
03Importar el CSV y configurar dropdowns
El administrador prepara una nueva hoja de seguimiento en Google Sheets y selecciona el archivo local content-register.csv desde File > Import. Comprueba import location y separator, y no sustituyas accidentalmente una hoja de seguimiento existente.
Después de importar, comprueba que se conserven las 14 header columns, las 4 sample rows, el texto en coreano y las columnas approval date y published URL vacías. La importación real en Google Sheets no se probó para este artículo.
Comprueba que review due date y approval date se reconozcan como fechas y muéstralas como YYYY-MM-DD. Mantén article ID como identificador de texto.
Selecciona las data cells de la columna status y registra los siete statuses en Insert > Dropdown o Data > Data validation. Permite solo un status por fila.
Para la columna privacy check, registra not checked, needs changes y done. Comprueba también el ajuste para valores que no estén en la dropdown list.
Después de comprobar el comportamiento con la muestra, elimina las filas sintéticas o consérvalas en una copia de práctica separada para que no se confundan con registros reales.
La ayuda oficial de Google describe file import y cell dropdowns como funciones separadas. Un CSV contiene únicamente valores, por lo que debes añadir estos ajustes después de importarlo. No describas el archivo como si ya tuviera configurada una sincronización automática o conexiones.
04Usar filter views para ver solo tu propio trabajo
Un reviewer puede querer ver primero las filas cuyo status es in review, y un writer puede querer ver primero sus propias changes-requested rows. En Sheets de escritorio, utiliza Data > Create filter view, selecciona los criterios de status y owner, y guarda views como “Awaiting review” y “My changes”. Un filter normal también puede ser visible para otros usuarios de un archivo compartido, así que utiliza filter views para organizar el trabajo individual.
Un filter oculta filas. No lo trates como si las eliminara o restringiera permissions.
Ordenar una sola columna por separado puede desalinear titles y owners, así que asegúrate de que todo el managed range esté incluido en el sort.
Comprueba también por separado las filas con due date vacío. Que no aparezcan en un filter no significa que estén terminadas.
Un temporary filter view creado con view permission puede no guardarse, así que comprueba el management role necesario y si quedó guardado.
05Gestionar permisos de uso compartido e historial de versiones
El propietario del archivo debería considerar mantener general access como restricted y añadir personas concretas. Los writers pueden ser editors, los reviewers que solo dejan feedback pueden ser commenters y los stakeholders que solo leen pueden ser viewers. Los commenters no pueden cambiar directamente el status de una celda, por lo que debe acordarse que el editor que recibe el review feedback registre el status y el approval date. El administrador concede permissions según las necesidades reales del trabajo.
Los usuarios con edit permission pueden consultar estados anteriores y quién hizo cambios en version history, y asignar nombres a versiones en puntos importantes. Esto ayuda a localizar el estado justo antes de la aprobación, pero no es lo mismo que el version history de los site files. Restaurar una versión anterior puede deshacer otras ediciones, así que comprueba el impacto antes de hacerlo. Descargar un CSV no conserva sharing permissions ni version history.
06Flujo manual desde la aprobación hasta la actualización del sitio
El reviewer comprueba sources, example results y sensitive information, y deja change requests o approval feedback.
Basándose en el draft que incorpora el feedback, el editor cambia el status a approved y registra el approval date.
El publisher aplica manualmente el approved content al content JSON y a los download assets del sitio. Este ejemplo no incluye automatic CMS sync desde Sheets al sitio.
Comprueba structure, links, examples y page display del artículo modificado y después haz deploy. Si el audience del sitio es owner-private, el resultado también permanece dentro de ese access scope.
Después de comprobar la deployed page, registra el published URL real y la release version, y cambia el status a published. Si se necesita public publishing, el audience del sitio debe cambiarse a public y el access debe comprobarse por separado.
Cuando sea necesario un cambio, conserva el mismo article ID, vuelve a poner el status en changes requested o in review y registra el motivo en next action.
No se ha implementado ningún comportamiento automático del tipo “cambiar el status a approved en Sheets actualiza el sitio”. Esta tracking sheet es un registro en el que las personas vinculan quién aprobó qué draft y en qué release se incluyó.
07Comprobar las reglas operativas con la muestra sintética
Sample
Status · check
Acción necesaria ahora
EX-001
Idea / not checked
Escribir el draft del ejemplo sintético
EX-002
Drafting / not checked
Completar los handover items
EX-003
In review / needs changes
Volver a revisar después de eliminar internal paths
EX-004
Approved / done
Aplicar al JSON, verify y deploy; published URL sigue vacío
EX-004 tampoco tiene published URL ni release version, por lo que no se cuenta como published. A la inversa, añadir únicamente un link no permite omitir el review. Antes de publicar, una persona comprueba que estén presentes approval date, evidence y privacy check result. El CSV no contiene formulas ni automation que impongan estas decisiones.
Comprueba que el mismo article ID no aparezca dos veces.
Comprueba que el link real de las filas con status published se abra y corresponda al draft correcto.
Elimina los filters para comprobar que no falten filas on-hold, undecided o unassigned.
Comprueba conjuntamente la sharing list y general access.
En una test copy, comprueba qué roles pueden ver version history y cuáles solo pueden dejar comments.
08Descargas y alcance de la verificación
content-register.csv es una plantilla local con 14 columnas y 4 filas de datos sintéticos. README.txt, column-guide.txt y workflow-checklist.txt contienen los ajustes que deben aplicarse después de importar y las status rules. Se comprobaron la UTF-8 encoding del archivo local, los row and column counts, duplicate article IDs, allowed statuses y los blank published URLs de las muestras. No se probaron la importación real de Google Sheets ni las operaciones de dropdown, permission y version history.
No se crearon ni conectaron cuentas ni Google Drive files, y no se modificó el site checkout. En organization accounts, el sharing scope puede estar limitado por admin policy. Las páginas oficiales de ayuda se comprobaron el 19 de septiembre de 2026, y los menu labels pueden variar según display language y product updates.
Registro de ejecución y verificación
@oai/artifact-tool local y comprobaciones CSV/JSON con Python; fuentes oficiales comprobadas el 2026-09-19
Se comprobaron la UTF-8 encoding del CSV local, sus 14 columns, 4 rows de datos sintéticos, duplicate article IDs y status values
Se comprobó la article JSON structure y que los sample statuses y next actions coincidan
Se comprobó el guardado y la nueva lectura de los local table values
Límites de la verificación
No se verificaron la importación real de Google Sheets ni las operaciones de dropdown, filter, sharing y version history
No se crearon ni conectaron Google accounts ni Drive files
No está implementada la automatic site sync después de la aprobación en Sheets; se requieren manual update, verification y deployment
El código de ejemplo, los nombres de archivo y las claves de entrada se mantienen como en el original. Consulta también los comandos y los pasos de comprobación del texto traducido.
Material de práctica original · Guarda los archivos originales por separado antes de ejecutarlo.
Fuentes de referencia
Las explicaciones y los ejemplos son de elaboración propia. Puedes consultar los comportamientos y conceptos relacionados en las siguientes fuentes oficiales.
En lugar de quedarse en otro resumen de la reunión, separa el trabajo acordado de los asuntos abiertos. Convierte notas sintéticas de reunión en una lista con responsables, fechas límite, entregables y evidencias de finalización, y redacta una solicitud para IA que ayude con la misma tarea.
Define una convención sencilla de nombres de archivo para el equipo, pruébala en una carpeta sintética y crea un informe de revisión sin renombrar ni eliminar nada. El comprobador separa errores estructurales, fechas no válidas y extensiones no admitidas.
Convierte notas de versión sin procesar en una entrada de changelog que separe los cambios de las acciones necesarias del usuario y de los pasos de verificación. Una actualización sintética de software muestra cómo hacer que una nota de versión sea útil para alguien que no realizó el cambio.
Convierte las notas de traspaso de un proyecto en una lista estructurada que registre qué debe transferirse, quién es responsable, dónde está almacenado y qué sigue sin resolverse. Un pequeño ejemplo sintético muestra cómo detectar responsables, ubicaciones y detalles de asuntos abiertos que faltan antes del traspaso.