La Base de Conocimiento de Mozilla permanece abierta para todos los que quieran contribuir. Cualquiera puede enviar una revisión menor para corregir o actualizar nuestros artículos de soporte sin necesidad de permisos especiales.

Este documento describe el flujo de trabajo para nuevas solicitudes de contenido y actualizaciones mayores que se coordinan a través de Bugzilla. Estas solicitudes siguen un proceso diferente porque a menudo requieren colaboración con los equipos de producto y otras partes interesadas.

Si no estás seguro de qué flujo de trabajo se aplica a tu cambio, consulta la sección Regla general a continuación o revisa Cambios menores frente a cambios mayores para entender en qué categoría se encuentra tu cambio propuesto.

¿Por qué Bugzilla?

Usamos Bugzilla para coordinar las discusiones sobre nuevas solicitudes de contenido y actualizaciones mayores porque este proceso a menudo involucra a múltiples partes interesadas.

Usar un único espacio de colaboración ayuda a garantizar que las conversaciones permanezcan transparentes y accesibles para todos los involucrados. Usamos intencionadamente Bugzilla en lugar de las discusiones de los artículos de la Base de Conocimiento porque muchas de las partes interesadas de nuestros productos ya trabajan en Bugzilla como parte de su flujo de trabajo normal, mientras que comparativamente pocos están familiarizados con el sistema de discusión de la Base de Conocimiento.

Bugzilla también proporciona una clara propiedad de las tareas y un seguimiento del progreso. Dado que la creación de contenido es un esfuerzo colaborativo entre el personal de Mozilla y los colaboradores de la comunidad, es importante que todos puedan ver fácilmente quién es responsable de una solicitud, qué decisiones se han tomado y qué trabajo queda por hacer. Esto ayuda a evitar la duplicación de esfuerzos, reduce la confusión y facilita el mantenimiento de la documentación relacionada con los lanzamientos según lo programado.

Regla general

Como regla general, puedes hacerte la siguiente pregunta:

¿Este cambio requiere la opinión o validación del equipo de producto?

• Si es así, crea o trabaja a través de un ticket de Bugzilla para que las partes interesadas apropiadas puedan participar en la discusión.
• Si no, generalmente eres libre de enviar el cambio directamente como una actualización menor de la Base de Conocimiento.

En otras palabras, si tu cambio propuesto no requiere la participación de las partes interesadas del producto y se encuentra dentro del alcance de una revisión menor, no es necesario pasar por Bugzilla.

Por qué existe este proceso

Este proceso está destinado a apoyar las contribuciones de la comunidad. Nos ayuda a:

• Proteger los plazos de lanzamiento
• Aclarar la propiedad y la responsabilidad
• Preservar una colaboración saludable
• Evitar la fricción causada por expectativas poco claras

Valoramos profundamente la experiencia de los colaboradores. El conocimiento de larga data sobre los productos dentro de la comunidad es increíblemente valioso. Al mismo tiempo, el trabajo de contenido vinculado a los lanzamientos de productos y la colaboración interfuncional requiere una propiedad clara, plazos predecibles y una coordinación estructurada para que podamos garantizar la entrega oportuna de contenido preciso y útil para apoyar a la base de usuarios global de Mozilla.

Flujo de trabajo para solicitudes de contenido a través de Bugzilla

El siguiente proceso se aplica a las nuevas solicitudes de contenido y a las actualizaciones mayores enviadas a través de Bugzilla.

Las solicitudes de contenido generalmente se dividen en dos categorías:

• Solicitudes "on-train": Contenido vinculado a un lanzamiento programado de Firefox. Estas solicitudes son sensibles al tiempo y deben seguir el calendario de lanzamiento.
• Solicitudes "off-train": Contenido que no está vinculado a un lanzamiento programado de Firefox. Estas solicitudes aún pueden tener una fecha límite, pero generalmente permiten más flexibilidad.

Para una vista previa completa, por favor abre la imagen en una nueva pestaña.

1. Envío

Todas las actualizaciones de contenido mayores deben enviarse a través de un ticket de Bugzilla.

2. Triaje y asignación

Triaje: Todas las nuevas solicitudes de contenido pasan por un proceso de triaje para determinar la prioridad y la asignación. El triaje se realiza semanalmente los jueves.

Las solicitudes de contenido que están abiertas a los colaboradores se marcarán con la palabra clave sumo-contributors en Bugzilla. Si estás interesado en ayudar con una de estas solicitudes, no dudes en expresar tu interés comentando directamente en el ticket de Bugzilla.

Asignación: Un miembro del personal de CX asignará el error a un colaborador o a un redactor técnico. Una vez asignado, el Community Manager u otro miembro del equipo de CX te guiará a través del proceso. Por favor, no empieces a redactar hasta que un miembro del personal de CX confirme tu asignación.

Expectativa de tiempo: El triaje se realiza semanalmente, y los colaboradores pueden esperar una respuesta a su solicitud de asignación dentro de cinco días hábiles.

• Solicitudes "on-train": La asignación para las solicitudes "on-train" es sensible al tiempo. Si una solicitud relacionada con un lanzamiento está abierta a los colaboradores pero permanece sin asignar después del siguiente ciclo de triaje (5 días hábiles), el equipo de CX puede asignarla a un redactor técnico para asegurar que el calendario de lanzamiento no se retrase.

• Solicitudes "off-train": Las solicitudes "off-train" generalmente permiten más flexibilidad y pueden permanecer disponibles para la asignación de colaboradores por más tiempo, dependiendo de la fecha límite solicitada.

3. Creación de contenido

Borrador de contenido: Revisa cuidadosamente el ticket para comprender la solicitud, el alcance, el lanzamiento o la fecha límite objetivo, y el resultado esperado antes de comenzar tu trabajo.

Una vez que se te asigne el error, puedes comenzar a crear el contenido. Si el equipo del producto proporciona un borrador, úsalo como punto de partida. De lo contrario, puedes empezar a redactar el contenido en Google Docs. Si Google Docs no es una opción, puedes adjuntar tu borrador directamente al ticket de Bugzilla para su revisión.

Asegúrate de publicar el enlace a tu borrador en el ticket de Bugzilla y de configurar los permisos del documento para permitir que las partes interesadas comenten.

Aprobación del contenido: Colabora estrechamente con el solicitante o las partes interesadas del producto para asegurarte de que el artículo esté completo y sea preciso. Si falta alguna información que necesites para completar el trabajo, utiliza la opción “Solicitar información de…” en Bugzilla para obtener detalles adicionales.

Puedes verificar la última línea de la descripción del formulario de Bugzilla para ver si se ha identificado un aprobador formal para el borrador.

Expectativa de tiempo:

• Solicitudes "on-train": Deben tratarse como de alta prioridad. A menos que el progreso esté bloqueado por dependencias de otras partes interesadas, el equipo de CX puede reasignar las solicitudes "on-train" si un borrador significativo no está listo para su revisión dentro de una semana después de la asignación o una semana antes del día de lanzamiento objetivo. Esto ayuda a garantizar que el contenido esté listo a tiempo para el lanzamiento.

• Solicitudes "off-train": El borrador generalmente debe estar listo para la revisión de las partes interesadas al menos una semana antes de la fecha límite solicitada.

Escalamiento:

• Si crees que no podrás cumplir con el plazo esperado, por favor, notifica al equipo de CX lo antes posible actualizando el ticket de Bugzilla o contactando directamente a un miembro del personal de CX. La comunicación temprana nos da tiempo para ajustar el plan o encontrar apoyo adicional sin retrasar la publicación.
• Si no puedes obtener la información requerida del solicitante, contacta al miembro del personal de CX que te asignó el error para que te ayude a obtener la información que necesitas.

4. Publicación de contenido

Publicar contenido: Una vez que el borrador esté finalizado y aprobado por las partes interesadas, puedes enviar el contenido como una nueva revisión en el artículo real de la Base de Conocimiento.

Por favor, recuerda que nuestra KB utiliza una sintaxis wiki personalizada, así que asegúrate de que tu contenido esté formateado correctamente al transferirlo desde Google Docs u otra herramienta que estés usando para redactar el contenido.

Revisión de contenido: Los colaboradores deben esperar a que su revisión de la KB sea revisada por un miembro del personal o un revisor de la KB que no sea el autor. En esta etapa, la revisión se centra principalmente en el aseguramiento de la calidad y el marcado adecuado, en lugar de validar la precisión de la información subyacente del producto.

Expectativa de tiempo:

• Solicitudes "on-train": El ticket de Bugzilla puede especificar una fecha de publicación planificada alineada con el calendario de lanzamiento de Firefox. Por favor, envía la revisión de la KB para su revisión al menos dos días antes de la fecha de publicación objetivo, a menos que el progreso haya sido bloqueado por dependencias de otras partes interesadas. Esto da a los revisores tiempo suficiente para completar la revisión final de calidad y marcado sin poner en riesgo la fecha límite del lanzamiento.

• Solicitudes "off-train": La publicación debe seguir la fecha límite acordada en el ticket de Bugzilla.

Escalamiento: Si necesitas ayuda con la revisión de una revisión de la Base de Conocimiento, puedes contactar a los revisores de la KB enviando un correo electrónico a kb-reviewers@mozilla.com.

Cierre del ticket: Una vez que el artículo de la KB haya sido publicado, el ticket de Bugzilla puede cerrarse marcándolo como Resuelto — Corregido.

Entendiendo la aprobación de contenido vs. la revisión de contenido

Históricamente, los colaboradores de la Base de Conocimiento solo están familiarizados con el proceso de revisión de la KB, donde cualquier persona con permisos de revisor de la KB puede revisar y aprobar o rechazar las revisiones de los artículos.

Sin embargo, al trabajar a través de Bugzilla, hay dos puntos de control distintos:

1. Aprobación de contenido: Completada por las partes interesadas del producto apropiadas durante el proceso de creación de contenido en Bugzilla.
2. Revisión de contenido: Completada por los revisores de la Base de Conocimiento antes de que se publique el artículo.

Aunque ambos son importantes, sirven para propósitos diferentes.

Aprobación de contenido por las partes interesadas

El objetivo principal de la aprobación de contenido es validar la sustancia y la intención del contenido con las partes interesadas del producto. Esto incluye asegurarse de que el borrador del contenido sea:

• Técnicamente preciso y refleje el comportamiento previsto del producto
• Coherente con la terminología y las convenciones de nomenclatura aprobadas del producto
• Consistente con la voz y los mensajes de la marca Mozilla

Revisión de contenido por el revisor de la KB

La revisión de contenido complementa la aprobación centrándose en la calidad y presentación del artículo. Durante esta etapa, los revisores de la Base de Conocimiento verifican que el artículo:

• Utiliza la sintaxis y el formato correctos, incluido el marcado wiki
• Es claro, bien estructurado y fácil de seguir
• Sigue las directrices editoriales y de contenido de Mozilla

Juntos, estos dos pasos ayudan a garantizar que cada artículo sea técnicamente preciso y fácil de entender para los usuarios antes de su publicación.

Directrices adicionales para colaboradores

• Equidad en la asignación

Los colaboradores que tienen relaciones directas con los equipos de producto pueden estar al tanto de las próximas solicitudes antes de que se envíen formalmente. Sin embargo, por favor, no comiences a trabajar ni solicites la asignación antes de que la solicitud de contenido sea creada y triada. Esto asegura que las oportunidades para contribuir permanezcan abiertas y equitativas para todos los colaboradores.

• Respeta el proceso de triaje

Por favor, permite al equipo de CX el plazo completo de 5 días hábiles para revisar y asignar los tickets de Bugzilla. Evita solicitar o presionar para que se tomen decisiones de asignación antes de que haya transcurrido este período.

• Comunica los cambios de disponibilidad

Entendemos que pueden surgir situaciones inesperadas. Si no puedes cumplir con un plazo al que te has comprometido, por favor, notifica al equipo de CX lo antes posible para que podamos ajustarnos en consecuencia.

• Política de reapertura de tickets de Bugzilla

Por favor, no reabras un ticket de solicitud de contenido de Bugzilla resuelto para solicitar una revisión de revisiones que no estén directamente relacionadas con la solicitud original. Para actualizaciones relacionadas, añade un nuevo comentario al ticket existente en lugar de reabrirlo. Si no tienes permiso para comentar, por favor, escala tu solicitud a la lista de correo de kb-reviewers (ver más abajo).

Reabrir tickets sin cumplir con este estándar puede resultar en que la solicitud sea desestimada. Por favor, sigue la Etiqueta de Bugzilla para mantener una colaboración productiva y respetuosa.

• Solicitudes de revisión acelerada

Si un nuevo artículo o una revisión requiere un plazo de entrega más rápido, como un cambio urgente en el producto, un incidente en curso o una inexactitud crítica, puedes enviar un correo electrónico a kb-reviewers@mozilla.com para solicitar una revisión acelerada.

Encontrar solicitudes de contenido para trabajar

Se anima a los colaboradores a involucrarse con las solicitudes de contenido a través de Bugzilla siempre que se alineen con los criterios descritos en la siguiente sección. A continuación, te indicamos cómo puedes buscar las solicitudes de contenido entrantes:

• Monitoreo manual

Puedes estar atento a las nuevas solicitudes de contenido revisando la lista de solicitudes de contenido sin asignar. Si encuentras una solicitud en la que te gustaría trabajar, simplemente deja un comentario en el error para que el equipo de CX sepa que estás interesado.

Después del triaje, las solicitudes de contenido que están abiertas a las contribuciones de la comunidad se etiquetarán con la palabra clave sumo-contributors en Bugzilla. Puedes usar esta palabra clave para seguir las solicitudes en curso que están disponibles para los colaboradores.

• Mantente actualizado

Si deseas recibir notificaciones sobre nuevas solicitudes de contenido, considera "observar" (watching) el componente Knowledge Base Content en Bugzilla. Para ello, ve a tu perfil de Bugzilla → Edit Profile & Preferences → Component Watching. Elige support.mozilla.org en la selección de productos, selecciona Knowledge Base Content en el campo Componente, y haz clic en el botón Add para guardar tus cambios.

Criterios de asignación

Una solicitud de contenido puede ser asignada a un colaborador cuando cumple las siguientes condiciones:

• No incluye información confidencial

Las solicitudes de contenido que involucren información embargada o contenido sensible seguirán siendo propiedad del personal.

• No implica dependencias internas estrictas

Las solicitudes que implican sensibilidad en los mensajes, revisión de cumplimiento o especificaciones en evolución y que requieren una coordinación activa con los departamentos legal, de marketing y comunicaciones, de seguridad o con socios externos también permanecerán en manos de los miembros del personal.

• No está relacionado con productos de pago

Las solicitudes de contenido relacionadas con productos de suscripción y funciones de pago deben seguir siendo propiedad del personal debido a requisitos legales, de cumplimiento, de pruebas y de coordinación interfuncional. Estas solicitudes a menudo implican información contractual, de facturación o sensible al lanzamiento que requiere una responsabilidad centralizada.

• No es sensible al tiempo

Las solicitudes de contenido con un tiempo de respuesta de menos de 5 días permanecerán en manos del personal para garantizar la entrega oportuna y la alineación con los calendarios de lanzamiento.

• Capacidad del colaborador

Los colaboradores están limitados a un máximo de 3 asignaciones activas a la vez. Esto ayuda a garantizar una ejecución enfocada y previene el desequilibrio de la carga de trabajo. Reconocemos que algunas solicitudes pueden retrasarse debido a dependencias técnicas. Si una solicitud permanece bloqueada por dependencias del lado del producto durante más de dos semanas, el ticket puede considerarse inactivo (obsoleto) y excluirse de las expectativas de carga de trabajo del colaborador.

Aclaraciones adicionales:

• Esto solo se aplica a las solicitudes a través de Bugzilla y no se aplica a las revisiones menores de la KB.
• Esto no se aplica a la creación de Respuestas predeterminadas del foro.
• El personal conserva la responsabilidad final sobre el contenido publicado.