Comparar revisiones

Seguimiento de bugs en la documentación

Revisión 440507:

Revisión 440507 de voylinux el

Revisión 440529:

Revisión 440529 de voylinux el

Título:
Seguimiento de problemas en la documentación
Seguimiento de problemas en la documentación
Enlace amigable (slug):
Project:en/Project:Tracking_documentation_issues
Project:en/Project:Tracking_documentation_issues
Contenido:

Revisión 440507
Revisión 440529
n10    <h2 id="Fallos_de_ingenieria_con_impacto_en_la_documentaci.C3n10    <h2 id="Fallos_de_ingenieria_relacionados_con_la_documentaci.
>.B3n">>C3.B3n">
11      Fallos de ingenieria relacionados con la documentación11      Bugs de ingenieria relacionados con la documentación
n14      Los fallos en el proyecto de Mozilla <a class="external" hrn14      Los bugs en el proyecto de Mozilla <a class="external" href
>ef="http://bugzilla.mozilla.org">Bugzilla database</a> que tienen>="http://bugzilla.mozilla.org">Bugzilla database</a> que tienen r
> relación con la documentación deberían ser etiquetados con la pa>elación con la documentación deberían ser etiquetados con la pala
>labra clave <code>dev-doc-needed</code>. Esta es otra gran manera>bra clave <code>dev-doc-needed</code>. Esta es otra gran manera d
> de encontrar elementos que pueden requerir ser documentados. Cua>e encontrar elementos que pueden requerir ser documentados. Cuand
>ndo en la documentación se han hecho los cambios necesarios, la p>o en la documentación se han hecho los cambios necesarios, la pal
>alabra clave <code>dev-doc-needed</code> debería ser cambiada a <>abra clave <code>dev-doc-needed</code> debería ser cambiada a <co
>code>dev-doc-complete</code>.>de>dev-doc-complete</code>.
n17      <strong>Nota:</strong> La palabra clave <code>dev-doc-needen17      <strong>Nota:</strong> La palabra clave <code>dev-doc-neede
>d</code> puede ser asignada a fallos antes incluso antes de estar>d</code> puede ser asignada a bugs antes incluso antes de estar r
> reparados; como norma general, de hecho solo deberías escribir l>eparados; como norma general, de hecho solo deberías escribir la 
>a documentación una vez que han sido reparados y posicionados en >documentación una vez que han sido reparados y posicionados en el
>el arbol.> arbol.
n20      Como norma general, la mejor apuesta es evitar escribir sobn20      Como norma general, la mejor apuesta es evitar escribir sob
>re algo hasta que el bug ha sido reparado, de manera que sabes qu>re algo hasta que el bug ha sido reparado, de manera que sabes qu
>e el asunto esta listo para ser documentado. Si decides escribir >e el asunto esta listo para ser documentado. Si decides escribir 
>sobre algo una vez que el fallo haya sido marcado como reparado, >sobre algo una vez que el bug haya sido marcado como reparado, pu
>puedes asignarte a tí mismo el fallo para reclamarlo.>edes asignarte a tí mismo el bug para reclamarlo.
n26      Si decides tomarte el trabajo de documentar un asunto marcan26      Si decides tomarte el trabajo de documentar un asunto marca
>do como <code>dev-doc-needed</code>, espera hasta que el fallo se>do como <code>dev-doc-needed</code>, espera hasta que el bug sea 
>a solucionado, entonces cambia la asignación del bug a tí mismo. >solucionado, entonces cambia la asignación del bug a ti mismo. De
>De esa manera, otros escritores sabrán quién se está encargando.> esa manera, otros escritores sabrán quién se está encargando.
n28    <h2 id="Other_documentation_issues">n28    <h2 id="Otros_asuntos_de_documentaci.C3.B3n">
n34    <h2 id=".22Firefox_X.C2.A0for_developers.22">n34    <h2 id=".22Firefox_X_para_desarrolladores.22">
n38      Cada gran lanzamiento de Firefox tiene una página corresponn38      Cada gran lanzamiento de Firefox tiene una página correspon
>diente titulada "Firefox X para desarrolladores". Los cambios pri>diente titulada "Firefox X para desarrolladores". Los cambios pri
>ncipales que afectan a los desarrolladores aparecen generalmente >ncipales que afectan a los desarrolladores aparecen generalmente 
>en listas de definiciones, con el título del artículo o sección c>en listas de definiciones, con el título del artículo o sección c
>orrespondiente&nbsp; y una breve explicación del cámbio. Los camb>orrespondiente&nbsp; y una breve explicación del cambio. Los camb
>ios menores se muestran como viñetas en una sección de&nbsp; "Mis>ios menores se muestran como viñetas en una sección de&nbsp; "Mis
>cellaneous changes".>cellaneous changes".
n41      Como norma general, los elementos listados en esta en listan41      Como norma general, los elementos listados en esta en lista
>s de definición son elementos de máxima prioridad y deberían ser >s de definición son elementos de máxima prioridad y deberían ser 
>documentados tan pronto como sea posible en el ciclo de documenta>documentados tan pronto como sea posible en el ciclo de documenta
>cion de la versión dada.>ción de la versión dada.
n63    <h2 id="The_Bugzilla_.22Whiteboard.22_field">n63    <h2 id="El_campo_.22Whiteboard.22_de_Bugzilla">
n67      Utilizamos el campo whiteboard en Bugzilla para seguir el en67      Utilizamos el campo whiteboard en Bugzilla para seguir el e
>stado de .>stado de la documentación de un Bug .
n92            El trabajo de documentación está a la espera,&nbsp; pn92            El trabajo de documentación está a la espera,&nbsp; p
>endiente de que el trabajo de ingeniería en curso sea terminado e>endiente de que el trabajo de ingeniería en curso sea terminado e
> incluido en el arbol. Generalmente se usa cuando el fallo ha sid> incluido en el arbol. Generalmente se usa cuando el bug ha sido 
>o reparado, pero por cualquier razón, el parche aún no ha sido la>reparado, pero por cualquier razón, el parche aún no ha sido lanz
>nzado.>ado.
n109      Utilizar con propiedad el "whiteboard" permite a los escritn109      Utilizar con propiedad el "whiteboard" permite a los escrit
>ores mantener el seguimiento de lo que está listo para ser docume>ores mantener el seguimiento de lo que está listo para ser docume
>ntado y lo que no. También nos ayuda a seguir la prioridad de los>ntado y lo que no. También nos ayuda a seguir la prioridad de los
> asuntos en documentación; obviamente, los fallos sobre la actual> asuntos en documentación; obviamente, los bugs sobre la actual (
> ( o siguiente ) version generalmente son mas importantes que los> o siguiente ) versión generalmente son mas importantes que los b
> fallos relativos a futuras versiones.>ugs relativos a futuras versiones.
n111    <h2 id="A_workflow_example">n111    <h2 id="Un_ejemplo_de_flujo_de_trabajo">
n115      Digamos que se rellena un fallo, sugiriendo que se añada unn115      Digamos que se rellena un bug, sugiriendo que se añada un n
> nuevo método, <code>foo()</code>, a la interfaz <code>IBar</code>uevo método, <code>foo()</code>, a la interfaz <code>IBar</code>.
>>. Idealmente, la persona que rellena el fallo aplicará la palabr> Idealmente, la persona que rellena el bug aplicará la palabra cl
>a clave <code>dev-doc-needed</code>, indicando que el bug, result>ave <code>dev-doc-needed</code>, indicando que el bug, resultará 
>ará en una documentación que requiera cambios. De lo contrario, a>en una documentación que requerirá cambios. De lo contrario, algu
>lguna otra persona lo har&amp;aacte;. Puede ser un escritor, pued>na otra persona lo hará. Puede ser un escritor, puede ser el inge
>e ser el ingeniero que hará los cámbios, podría ser algún otro qu>niero que hará los cámbios, podría ser algún otro que sea parte i
>e sea parte interesada.>nteresada.
n118      En este punto, te llama la atención como escritor que buscan118      En este punto, te llama la atención como escritor que busca
> fallos para documentar. Le echas un vistazo, y ves que de hecho,> bugs para documentar. Le echas un vistazo, y ves que de hecho, a
> aun no ha sido reparado,así que por ahora lo dejas estar.>un no ha sido reparado, así que por ahora lo dejas estar.
n121      Eventualmente, te dará cuenta de que hay un parche y el estn121      Eventualmente, te darás cuenta de que hay un parche y el es
>ado del bug es FIXED. En este caso, decides que te gutaría escrib>tado del bug es FIXED. En este caso, decides que te gutaría escri
>ir sobre ello. Así que te asignas el fallo a tí mismo, haciendo s>bir sobre ello. Así que te asignas el fallo a tí mismo, haciendo 
>aber a los demás que lo están escribiendo (preferiblemente con un>saber a los demás que lo estás escribiendo (preferiblemente con u
> comentario que lo diga, por el bebeficio de la gente que no se d>n comentario que lo diga, por el beneficio de la gente que no se 
>é cuenta de que eres un escritor), y te pones a trabajar.>dé cuenta de que eres un escritor), y te pones a trabajar.
n124      Despues de un tiempo, te das cuenta de que el codigo no es n124      Después de un tiempo, te das cuenta de que el código no es 
>auto-explicatorio, o hay algun otro detalle del que necesitas exp>auto-explicativo, o hay algun otro detalle del que necesitas expl
>licacion. Asi que le envias un email al ingeniero, o añades un co>icación. Asi que le envias un email al ingeniero, o añades un com
>emtario al bug, formulando la pregunta o preguntas. Ahora estas b>entario al bug, formulando la pregunta o preguntas. Ahora estás b
>loqueado pendiente de la respuesta, asi que añades <code>doc-wait>loqueado pendiente de la respuesta, asi que añades <code>doc-wait
>ing-info</code> al whiteboard y buscas otro trabajo que hacer has>ing-info</code> al whiteboard y buscas otro trabajo que hacer has
>ta que obtengas una respuesta.>ta que obtengas una respuesta.
n127      Una vez que obtines respuesta (ya sea por mail, o como un cn127      Una vez que obtienes respuesta (ya sea por mail, o como un 
>omentrio de seguimeinto en el propio bug en si), eliminas el term>comentario de seguimiento en el propio bug en si), eliminas el té
>ino <code>doc-waiting-info</code> del whiteboard y vuelves a escr>rmino <code>doc-waiting-info</code> del whiteboard y vuelves a es
>ibir.>cribir.
n130      Una vez que el texto esta completo, cambias las palabra clan130      Una vez que el texto está completo, cambias las palabra cla
>ve <code>dev-doc-needed</code> por <code>dev-doc-complete</code>.>ve <code>dev-doc-needed</code> por <code>dev-doc-complete</code>.
> Tambien deberias coemntar en el bug, diciendo que has terminado > Tambien deberías comentar en el bug, diciendo que has terminado 
>el trabajo de documentacion, con URLs a la pagina o paginas actua>el trabajo de documentación, con URLs a la página o páginas actua
>lizadas, incluyendo enlaces si el cambio es una seccion especific>lizadas, incluyendo enlaces si el cambio es una seccion especific
>a.>a.
n132    <h2 id="When_in_doubt...">n132    <h2 id="Cuando_tengas_dudas...">
t136      Cuando tengas dudas sobre la prioridad de un elemento de lat136      Cuando tengas dudas sobre la prioridad de un elemento de la
> documentacion o no estes seguro de que hacer, puedes sacar el te> documentación o no estes seguro de que hacer, puedes sacar el te
>ma en la lista de correo de<a class="link-https" href="https://li>ma en la lista de correo de<a class="link-https" href="https://li
>sts.mozilla.org/listinfo/dev-mdc" title="https://lists.mozilla.or>sts.mozilla.org/listinfo/dev-mdc" title="https://lists.mozilla.or
>g/listinfo/dev-mdc">dev-mdc mailing list</a> o escribir un email >g/listinfo/dev-mdc">dev-mdc mailing list</a> o escribir un email 
>a <a class="link-mailto" href="mailto:eshepherd@mozilla.com" titl>a <a class="link-mailto" href="mailto:eshepherd@mozilla.com" titl
>e="mailto:eshepherd@mozilla.com">developer documentation lead</a>>e="mailto:eshepherd@mozilla.com">developer documentation lead</a>
> para pedir ayuda.> para pedir ayuda.

Volver al historial