Mi equipo usa MadCap Flare para la documentación y tenemos un editor en el equipo. Cuando un escritor está listo, armamos un paquete de revisión en Flare y se lo enviamos al editor, y ella hace los cambios y se los envía al escritor para que los resuelva. (El escritor tiene la última palabra y la responsabilidad de asegurarse de que las ediciones no cambien la precisión técnica de la documentación). El paquete de revisión enviado al escritor contiene cambios marcados similares a los del modo de "control de cambios" de Word: - tachaduras para las eliminaciones, un color diferente para las inserciones y anotaciones (llamadas) para otras comunicaciones entre el editor y el escritor.
Eso está bien, pero Flare requiere que cada cambio sea aceptado o rechazado individualmente, y el problema que tenemos es que una edición de un solo párrafo puede producir una docena de cambios individuales, cada uno de los cuales necesita ser manejado. Si aceptara accidentalmente 11 de ellos y rechazara uno, tendría un texto desordenado porque todos los cambios están relacionados. Queremos grupos de cambio atómico , aceptar todos o ninguno de estos, en esta situación. (Flare admite "aceptar todo" o "rechazar todo" a nivel de archivo, pero eso es demasiado grueso).
Probamos Google y tenemos algunos usuarios de Flare bastante experimentados en el equipo, y lo mejor que se nos ocurrió, cuando un bloque de texto requiere muchas ediciones pequeñas, es hacer que el editor corte/pegue el texto en un nuevo bloque, edítelo y luego elimine el original. Pero eso es tedioso si se hace todo el tiempo y difícil de anticipar si se realizan cambios durante la edición. El editor no debería tener que hacer dos pases, uno para leer y luego un segundo para regresar y hacer cambios "en línea" (si son solo unos pocos) o mediante esta rutina más elaborada de cortar/pegar (si es más extensa).
¿Hay alguna manera de hacer que Flare agrupe un conjunto seleccionado de cambios para admitir la atomicidad? Preveo que el editor pueda marcar todos los cambios en un párrafo como parte del mismo grupo, y que el escritor pueda decir "sí" o "no" a ese grupo.
Estamos usando una combinación de las versiones 9 y 10. Si actualizar a todos a la versión 10 ayudaría, podemos hacerlo.
Esto no tiene nada que ver con el control de código fuente, por lo que la compatibilidad con GIT en V11 y 12 es una pista falsa.
No hay mejor manera de hacerlo, a partir de la versión 12 (abril de 2016). Lo que estás haciendo y tu trabajo son las dos únicas formas que conozco de hacer lo que quieres.
En nuestro grupo, usamos Seguimiento de cambios para los cambios que queremos que el autor revise. No usamos Control de cambios para los cambios que tenemos la autoridad de hacer sin que el autor original los vuelva a revisar. Pero esto tiene el efecto no deseado de requerir que el editor siga haciendo clic en el botón de encendido/apagado.
Su otra opción sería permitir que el revisor solo anote el documento, en lugar de editarlo, pero eso tiene otras repercusiones dolorosas.
Finalmente, señalaré que en Flare 12, cuando genera un PDF, Flare ahora tiene la opción de imprimir el contenido de cambios de seguimiento y las burbujas de comentarios en el PDF, para que las personas puedan revisar el archivo PDF y ver los cambios realizados. Sé que esto todavía no responde directamente a la necesidad de su pregunta, pero es una nueva característica interesante relacionada con lo que estamos hablando.
Lo mejor que puede hacer en este punto es enviar una solicitud de función en el sitio web de MadCap dándoles un ejemplo y un caso de uso. Son bastante receptivos a la retroalimentación.
José
Mónica Celio
rdtsc