Difference between revisions of "Bug Tracker/es"

From Second Life Wiki
Jump to navigation Jump to search
(→‎Searching: Translated this paragraph - Párrafo traducido)
(→‎How do I help out?: Paragraph translated - Apartado traducido.)
Line 292: Line 292:
* Desde ese momento, puede acceder a esa búsqueda y realizarla simplemente pulsando el enlace "Filter" en la esquina superior derecha de la página. Así ahorra tiempo y trabajo, sobre todo si usa la misma búsqueda con frecuencia y quiere tener un atajo práctico para hacerla.
* Desde ese momento, puede acceder a esa búsqueda y realizarla simplemente pulsando el enlace "Filter" en la esquina superior derecha de la página. Así ahorra tiempo y trabajo, sobre todo si usa la misma búsqueda con frecuencia y quiere tener un atajo práctico para hacerla.


== How do I help out? ==
== ¿Cómo puedo ayudar? ==


Glad you asked!
¡Encantados de que pregunte!  


=== Marking Duplicates ===
=== Marque los Duplicados ===
If you notice an newer issue that is a duplicate of an existing issue with a lot more comments, patches, or votes, feel free to choose "Resolve" and choose "Duplicate". But when you do this, please also choose "Link", and then say "This issue duplicates" and enter the main bug number. This lets everyone keep track of which bugs are duplicates of each other, and which bugs are reported more than others. This ensures that bugs that are often reported get the most attention, and also allows the duplicates to be reviewed from one central location, to ensure they are truly duplicates.
Si se da cuenta de que una cuestión nueva es un duplicado de otra existente ya con cantidad de comentarios, votos, etc., con toda libertad escoja "Resolve" y elija "Duplicate". Pero cuando lo haga, por favor, elija también "Link", y escriba "This issue duplicates" con el número del bug original. Así todos pueden seguir qué bugs son duplicados de otros, y qué bugs son más reportados que otros. De este modo se garantiza que todos los bugs reportados con frecuencia tengan más atención, y también permite revisar los bugs duplicados para asegurarse de que en verdad lo sean.


=== Resolving support issues ===
=== Solucionando cuestiones de soporte ===
This one is best left to technically adept users that can spot the difference between a support issue and a bug -- it's not always a simple matter to figure out. You should at most "Resolve" a report that seems to be a support issue. "Resolving" an issue puts the responsibility back on the reporter to provide more information on why the report isn't a support issue, and is indeed a reproducible bug that an entire class of user experiences.
Es mejor que esto quede para usuarios técnicamente expertos, que pueden ver ''in situ'' la diferencia entre una cuestión de soporte y un bug, lo que no siempre es fácil de averiguar. Usted debe "Resolve" un informe que parezca ser una cuestión de soporte. "Resolver" una cuestión pasa al responsabilidad a quien reportó de proporcionar más información sobre por qué el informe no es una cuestión de soporte, y es -sin duda- un error que puede reproducirse y no una experiencia concreta de un usuario.


=== Resolving bugs that you can't reproduce ===
=== Solucionando bugs que usted no puede reproducir ===
If you do exactly what they say in the bug, with the same environment, and can't reproduce the bug, you should resolve the bug. Be careful, if a bug is related to graphics rendering, and you do not have the same video card, for example, that is not the same environment and you can't make this determination.  Again this is also best left to technically adept users.
Si hace exactamente lo que dicen en el bug, con el mismo entorno, y no puede reproducir el error, debe resolver el error. Tenga cuidado si es un bug relacionado con los gráficos y usted no tiene la misma tarjeta de vídeo, pues al no ser el mismo entorno no debe decidir darlo por resuelto. Una vez más, también aquí es mejor dejarlo para los usuarios técnicamente expertos.


=== Reproducing bugs ===
=== Reproduciendo bugs ===
This one is very important! If you can create a step-by-step list to reproduce the bug in the bug report, this helps Linden Lab concentrate on bugs that can be verifiably fixed. Unless a bug can be reproduced, it is impossible to know if it has been fixed or not. Do what the bug reporter said they were doing, write a detailed step-by-step list of things you did to cause the bug to happen, and add it to the bug saying that you have successfully reproduced the bug. Such bugs with solid reproductions get higher priority in the development process, and help the Bug Triage Team work more efficiently.
¡Esto es muy importante! Si puede crear en el informe una lista que reproduzca paso a paso el bug, ayuda a Linden Lab a concentrarse en bugs que pueden ser resueltos. Hasta que un bug no pueda reproducirse, es imposible saber si ha sido solucionado o no. Haga lo que el informe dice que se estaba haciendo, escriba paso a paso y detalladamente lo que usted hizo para que ocurriera el bug, y añádalo al bug indicando que, efectivamente, usted ha podido reproducirlo. Los bugs que tienen reproducciones constantes y firmes, tienen más prioridad en el proceso de desarrollo, y ayudan a que sea más eficiente el trabajo del "Bug Triage Team".


== Recursos relacionados ==
== Recursos relacionados ==

Revision as of 04:00, 12 June 2008

Emblem-important-red.png Advertencia

La traducción de este artículo no está actualizada. Consulta la versión en inglés para acceder a las últimas actualizaciones de contenido. Si estás interesado en ayudarnos a actualizar la traducción de este artículo, únete al proyecto de traducción de la comunidad Community Translation Project. set version=2

Update Needed

This article needs an update to reflect recent changes in the base article located at Issue tracker. When you're done with the update, change the {{Help/CODE|Parent=Issue tracker|BugFixes=*}} part to {{Help/CODE|Version=2|Parent=Issue tracker|BugFixes=*}}. Thank you for your help!

Esta página está pendiente de ser traducida al español.

Al no estar reflejada en la página del Proyecto de Traducción del wiki, es importante que si usted empieza a traducirla lo indique aquí para evitar que otro usuario realice un trabajo baldío:


Una vez traducida la página, por favor, borre este texto.
JIRA.jpg

Ante todo, dos avisos:

  • The JIRA Issue Tracker no está para peticiones de soporte técnico. Si está usted buscando ayuda para una cuenta concreta, por favor, use nuestros recursos para soporte.
  • Todas las aportaciones al sitio (incluido el JIRA included) se rigen por el Second Life Project Contribution Agreement. El hecho de enviar parches u otra información usando este sitio, da por supuesto que usted está conforme con que ha leído y entendido esos téminos, y que está de acuerdo con ellos.

El JIRA public issue tracker, que está en http://jira.secondlife.com, es una base de datos con motor de búsqueda (searchable database) que se usa para organizar diversas cuestiones (por ejemplo, bugs y peticiones de desarrollos) remitidas por la comunidad de Second Life community. Así, usted puede ayudar aportando información sobre cuestiones que ha encontrado usando el código abierto (open source) o las versiones estándar de Second Life. La información de esta página le ayudará a familirizarse con el JIRA.

Para ser exactos, JIRA es una herramienta para manejar projectos de seguimiento de cuestiones (issue-tracking project management tool) elaborada por Atlassian. Es primordialmente usada por la comunidad de código abierto de Second Life, y se suele citar como "Public JIRA", "PJIRA", o simplemente "JIRA", según el contexto.

Cómo trabaja

Hay dos tipos básicos de cuestiones: informe de bugs y nuevos desarrollos.

  • El informe de un bug comprende una descripción del problema y, si es posible, una forma de reproducirlo.
  • Un nuevo desasrrollo comprende una descripción del mismo y cómo se pretende que trabaje esa característica.

Ambas cuestiones recibirán la atención de otros usaurios, que puyeden añadir mejores o más simples descripciones o añadidos. Las cuestiones populares acumulan votos de otros usuarios. Los programadores en código abierto pueden añadir "parches", o cambiar el cógido fuente en la dirección que sugiere la ucestión. Votos, y eventos como los bug triages, ayudar a priorizar unas u otras cuestiones. help prioritize the issues. Aquellas que son suficientemente acordadas, pasan a copia privada del JIRA de los Linden.

Después de que una ucestión recibe la atención de los Linden, aun pueden otros seguir ayudando:

  • Una vez que se han completado los cambios y están esperando ser liberados al público, el bug queda solucionado como "Fix Pending".
  • Cuando el cambio ya está dispobinle, queda resuelto como "Fixed".
  • Generalmente, tras ser confirmado por el Quality Assurance Team de Linden Lab y nuestra comunidad, su estatus cambia de "Resolved" a "Closed".

Ademas de "Fix Pending" y "Fixed", una ucestión puede ser resuelta o cerrada si se ve que está duplicada, o es irreproducible, de un archivo perdido, no es un bug, está incompleta, etc.

Creando informes de bug o petición de desarrollos

Si se ve perdido y no sabe por dónde empezar, vea la sencilla guía "Como informar mejor de bugs".

Manténgase actualizado

Puede revisar las Release Notes o las Beta Release Notes para mantenerse actualizado sobre los cambios recientes de Second Life. A veces, se descubre lo que rodea a un nuevo bug, o se encuentra que un cambio ha sido intencionado. Por ejemplo, el que no se pueda vender tierra por 0 L$ es un desarrollo, no un bug.

Además, debe asegurarse de que sus "video drivers" estén actualizados. Generalmente, puede conseguirlos en el sitio web del fabricante de su tarjeta gráfica, que, con frecuencia, será el NVIDIA official site o el ATI official site. Los Omega Drivers es usual que ofrezcan versiones modificadas de esos drivers.

Descubra si el asunto ya ha sido enviado

Evitar asuntos duplicados es muy importante. Tener los duplicados es una pérdida de tiempo y esfuerzo (tanto para el personal de Linden Lab como para los compañeros Residentes), y provoca errores y que parezca que se está prestando menos atención a determinadas propuestas de lo que en realidad se hace. Es más eficaz concentrar los esfuerzos sobre el mismo problema y en la misma cuestión, especialmente desde que los temas "más activos" tienen mayor prioridad.

Tras conectarse, verá el "Dashboard", con varios filtros de búsqueda que le permitirán acceder a la información más actualizada de las cuestiones remitidas. Por ejemplo, puede pulsar en los asuntos "unresolved" ("unfixed" o "untested") de cada proyecto, y empezar desde ahí una búsqueda de texto (editando el filtro). Por supuesto, en cualquier momento puede salvar sus propios filtros, o, sin más, empezar una nueva búsqueda desde la caja "Quick Search". En cualquier caso, ¡es mejor intentar varias búsquedas del asunto que quiere reportar antes de enviarlo!

Si encuentra que su cuestión ya ha sido enviada, aun es posible que haga varias cosas para ayudar:

  • Deje un comentario aportando detalles o información complementaria.
  • Si se trata de un bug, a lo mejor puede aportar otra forma de reproducirlo.
  • Vote por ese asunto para expresar que lo ve importante.

Cuanta mejor información haya sobre un asunto concreto, más oportunidades tiene de solucionarse con rapidez.

Directrices

  • Envié directamente al Equipo de Seguridad las cuestiones relativas a seguridad y "exploits". Los "exploits" son bugs que podrían usarse para tener ventaja sobre otros, acceder sin permiso a scripts, hacer copias no autorizadas o transferencias o modificaciones de objetos de los que usted no quiere que eso ocurra (también llamados "permissions" bugs), y otros bugs que podrían -potencialmente- poner en jaque el grid o la privacidad de los residentes. Para que haya rapidez en los resultados, contacte con un Linden del grupo "Bug Hunters", y envíe un correo-e con su informe a security@lindenlab.com. Vea el artículo cuestiones de seguridad.
  • Si su asunto es urgente (como una pérdida de contenido), y tiene usted una cuenta Premium Account, use el soporte por teléfono o chat. También podría intentar una respuesta rápida enviando un Tique de Soporte a través del Portal de Soporte, pero, generalmente, puede llevar hasta siete días el que se abra su tique.
  • Si es posible, cuando describa el bug intente omitir nombres de Residentes o información personal que pueda identificarles. Si parece que el bug sólo le afecta a usted o a unos pocos, quizá debería pensar en otros caminos para encontrar soporte técnico a través del del Portal de Soporte.
  • Cuanto más fácilmente podamos reproducir el bug, más rápidamente podremos arreglarlo. Por ejemplo, en vez de decir "Me caigo cuando subo cualquier cosa", la reproducción debería describirse en pasos concretos:
    Por ejemplo:
    • Pulsar File > Upload Image ($L10)...
    • Elegir un archivo .TXT en vez de un archivo .JPG
    • Pulsar el botón Open
¡Intente enviar su escrito a un amigo para ver si él puede seguir los pasos! Si su amigo puede seguirlo, ¡hay muchas oportunidades de que nosotros también!
  • Evalúe si subir imágenes, vídeos, "crash logs", o cualquier archivo relacionado (con un límite de 10MB cada uno). En el ejemplo de arriba, quizá pueda subir los archivos que intenta subir y causan la caída.
  • No envíe más de una cuestión en un solo informe.
  • Busque en los informes antes de enviar el suyo para asegurarse de que no es un duplicado.

Remitiendo un bug

Para remitir un nuevo bug al JIRA, haga lo siguiente:

  • Pulse el enlace "Create New Issue" en la barra de navegación de la parte alta de su pantalla. (Si no la ve, asegúrese de estar conectado al JIRA).

En la primera página:

  • Elija el "project" que más se acerque al tipo de bug que está enviando: vea #Projects and Components.
    • Recuerde: las cuestiones relativas a seguridad, debería enviarlas directamente al Equipo de Seguridad. Vea cuestiones de seguridad..
  • Elija "Bug" como su "issue type".
  • Pulse "Next".

En la última página:

  • Ponga un conciso pero descriptivo "summary" (título) al asunto.
  • Elija la "priority" (gravedad) del bug. Por ejemplo, un bug "blocker" podría inutilizar el programa, pero un bug "small" quizá sea sólo algo estético. Pulse el icono que hay junto al desplegable para más detalles.
  • Seleccione los "components" que delimiten el alcance del error. Puede seleccionar varios con "Ctrl-Clic".
  • Elija las "versions" afectadas por el bug. Sólo debería elegir aquellas en las que lo ha observado, y seleccionar una versión "first look" sólo si el bug es únicamente aplicable a First Look.
  • Generalmente, el "Linden Lab Issue ID" deberá dejarlo en blanco, a menos que sea usted un Linden. Si quiere hacer referencia del número de un Tique de Soproete, hágalo en la descripción, no aquí.
  • Describa el "environment" en que sucede el problema, si sabe que sólo ocurre con ciertas configuraciones de hardware o software. Una forma de encontrar información es el botón de Second Life "About". Puede subrayar hechos que pudieran ser pertinentes (como el modelo de tarjeta gráfica para problemas gráficos problemas, o los modelos de auriculares para funciones de voz), y buscar más ayuda en los párrafos de más abajo. Si la configuración no parece tener importancia, puede dejarla en blanco.
    • Por ejemplo, "Sólo ocurre con Mac OS X 10.4.1," o "Visto únicamente con la tarjeta NVIDIA GeForce Go 7800", etc.
  • Aporte una "description" detallada del problema, y asegúrese de incluir:
    • Pasos para que se pueda reproducir el error (cómo hacer que suceda el error), o, al menos, una descripción con cierto detalle de lo que parece conducir al error, con cierto detalle. Trate de hacer de este de la forma más simple posible sin dejar de ser lo suficientemente específico. Reproducciones simples hacen más fácil el reducir las causas.
    • Efectos observados (qué sucede cuando ocurre el bug).
    • Efectos esperados (qué comportamiento debería haber sucedido).
    • Cualquier cosa que piense que puede ayudar como enlaces a foros o blogs.
    • Insistimos, ¡sea tan detallado como pueda sin incluir información personal!
  • Si tiene una captura de pantalla o un vídeo del bug, u otro archivo relevante, puede adjuntarlo en "attachment". Hay un límite de 10MB por archivo. También pude adjuntar archivos más tarde. (Vea en Debug Help varias formas de aportar esa información adicional).
  • Si es usted programador y está adjuntando un "patch" del código fuente, enter the source version the patch is against and check the patch attached box.

Finalmente, pulse "Create" para crear la nueva cuestión.

Remitiendo un nuevo desarrollo

El proceso es similar al de remitir un bug, con estas diferencias:

Como "issue type" elija "New Feature" en vez de "Bug".

  • En lugar de "reproduction", describa claramente la implementación y funcionalidad del nuevo desarrollo. Asegúrese de que no ha sido hecho ya: puede ver las release notes para el contexto histórico y leer read nuestro blog para saber más de nuestros planes.

Votando asuntos

Puede votar los bugs y nuevos desarrollos que quiera ver resueltos, y ver todos los asuntos por votos. El JIRA usa approval voting, por lo que puede votar tantos asuntos como desee, con 1 voto por asunto.

Los votos pueden usarse fácilmente como parte de nuestro proceso para asignar prioridades. Tenga en cuenta que, como hemos de atender a aspectos como la viabilidad y los plazos de ejecución, una cuestión muy votada no necesariamente se va a resolver antes que otra menos votada, pero es más factible que así suceda.

Revisar el estado de una cuestión

Linden Lab revisará periódicamente los asuntos remitidos a jira.secondlife.com. El equipo técnico puede pedir información adicional a quien envió la cuestión o a otros contribuyentes, por lo que es bueno que revise periódicamente los asuntos que haya creado o comentado, dado que el soporte por correo-e del JIRA está deshabilitado.

Por otra parte, cuando las cuestiones se resuelvan internamente se actualizará el sitio web, por lo que le conviene revisar periódicamente sus cuestiones por si ha habido cambios.

"States" de los Asuntos

"States" usados

Así está usando Linden Lab sus resoluciones:

Open
Se trata de una cuestión que aún no ha sido asignada al "Assignee" (encargado). El "Assignee" puede arreglar el problema, o devolver el asunto a quien lo reportó para que la dé por "Resolved" (ver más adelante).
In Progress
Así es como un desarrollador indica a todos que él/ella está trabajando en el asunto.
Reopened
Lo mismo que "Open".
Resolved
Se trata de una devolución implícita a quien reportó el asunto. Aún no está "closed", pero se queda en un limbo que depende de su resolución. Todo depende de si quien lo reportó decide reabrir un asunto, o cerrarlo.
Fixed
Significa que el bug se ha corregido en una versión pública de Second Life.
Fix Pending
Significa que el bug se ha corregido en una versión del código que aun no está disponible al público.
Won't Fix
Significa que el "Assignee" no cree que deba arreglarse este asunto.
Duplicate
Significa que hay otros asuntos que describe el mismo problema o idea.
Needs More Info
A esta cuestión le falta información.
Cannot Reproduce
Estamos aplicando esta etiqueta con bastante frecuencia. Por favor, aporte una descripción detallada de cómo reproducir el problema. Los asuntos que no puedan reproducirse serán cerrados.
Misfiled
Esta cuestión no pertenece a este programa de seguimiento.
Closed
El lugar final que lleva al descanso.

¿Cuál es la diferencia entre "Fixed" y "Fix Pending"?

Sencillo:

  • "Fixed" significa que la corrección está disponible en estos momentos en la versión disponible de Second Life.
  • "Fix Pending" significa que la corrección ha sido hecha por Linden Lab y aún no se ha puesto a disposición del público. Es posible que haya que someterla a una mayor atención, como la garantía de calidad, o que necesite un branch antes de ponerla a su disposición. Véalo como un aviso de "Ya casi está... ¡próximamente!".

FAQ del JIRA de Second Life

Advertencias

  • El "JIRA Issue Tracker" no está para peticiones de soporte técnico, por tanto, por favor, no envíes cuestiones que requieran una respuesta adaptada a su situación personal. Por ejemplo:
    • "No puedo cambiar mi 'tier'"
    • "Tengo una duda sobre el terreno que he comprado"
    • "He perdido parte de mi inventario"
    • "¡Me caigo siempre!!"
    • "Alguien me ha robado L$"
    • "Estoy en un sim lleno de lag"
    • "¿Cómo puedo comprar una casa?"
    • Más ejemplos de cuestiones que no tienen cabida
  • Generalmente, la gente que usa el JIRA no puede hacer nada con este tipo de asuntos, por lo que usted perderá el tiempo (como mucho conseguirá un educado "por favor, contacte con soporte"). También dificulta a sus compañeros Residentes usar el Programa de Seguimiento ("Issue Tracker"). Si busca asistencia personal, por favor, envíe su mensaje al lugar correcto poniéndose en contacto con Spporte, y asegúrese de incluir los detalles útiles que ayuden a Linden Lab a ayudarle.



Nota: Las Normas de la Comunidad de Second Life ("Community Standards") [ENLACE: http://secondlife.com/corporate/cs.php] se aplican a todas las áreas de Second Life, incluyendo el "Second Life Public Issue Tracker". Cualquier Residente que las contravenga, será excluido en el futuro de su uso.


Ejemplos de acciones o comportamiento concretos que pueden llevar a la exclusión del "Issue Tracker":

  • Usar el "Issue Tracker" para promocionar su negocio, causa, blog, sitio web, o cualquier cosa no relacionada directamente con las cuestiones.
  • "Flaming". - El acto de escribir un mensaje para incitar a ponerse en contra de o atacar directamente a alguien se conoce como "Flaming", y no es apropiado para el "Issue Tracker". Por favor, aténgase a los hechos del asunto en cuestión. Los mensajes que hagan caso omiso de esto serán borrados.
  • Discusiones Personales, haciendo un diario de sus opiniones personales o cuestiones que no tienen que ver con el tema. El "Pjira" se destina a encontrar solución a las cuestiones. Nos encanta el intercambio de opiniones que sea productivo. Por favor, cíñase a los detalles técnicos del tema.

Conectándose

  • Vaya a https://jira.secondlife.com y pulse el enlace 'Log In' en la esquina superior derecha.
  • En la página de conexión, introduzca su nombre de usuario de Second Life y su contraseña.
  • Así se cargará la misma página del Jira que usted vio antes, pero con más opciones, como "Create Issue", un enlace para editar su perfil, y algunos filtros pre definidos.

Bugs y Nuevos Desarrollos

  • Debería echar un vistazo a Bug Reporting 101 para descubrir qué debe intentar antes de remitir un bug.
  • También puede proponer nuevos desarrollos usando el JIRA. (JIRA es el sucesor de la Feature Voting Tool, porque tiene un mejor sistema de búsqueda y se corresponde a la forman en que los Lindens organizan internamente los asuntos. Además, usted puede debatir con otros Residentes).

Perfil de Usuario

  • Cada usuario del JIRA tiene un perfil. Incluye su Nombre de Usuario (el nombre de SL), Nombre Completo (en nuestro caso, también el nombre de SL), y todos los grupos del JIRA a los que pertenezca, lo que, para la mayoría, se traducirá en "jira-users".
  • La dirección de correo asociada a su cuenta permanecerá oculta a otros usuarios. Por el momento, la dirección no es visible ni configurable, ni está habilitado el importar directamente su dirección de correo desde la base de datos de Second Life.
  • El perfil del JIRA no es editable porque permitir cambiarlo podría crear conflictos con su cuenta de Second Life. Si quiere editar información de la cuenta como su dirección de correo-e, por favor, conéctese a la página de manejo de su cuenta en secondlife.com.

Personalizando Preferencias

  • Si quiere que se muestren más asuntos por página, o cambiar el lenguaje en que se muestra el JIRA, actualice sus Preferencias de usuario después de conectarse.

"Projects" and "Components"

Los "Projects" se usan para clasificar las cuestiones en grupos lógicos. Los "Components" se usan para especificar a qué parte del sistema afecta la cuestión. Dicho de otro modo: cuál es el alcance de un problema dentro del "project".

"Projects" y "Components" del JIRA
Viewer (VWR) Service (SVC) Website (WEB) Miscellaneous (MISC)
  • Avatar/Character
  • Building (in-world)
  • Chat/IM
  • Crashes
  • Documentation
  • Graphics
  • Internationalization
  • Inventory
  • Land
  • Linden Dollars (L$)
  • Missing Content
  • Performance
  • Permissions
  • Physics
  • Scripting
  • Sound
  • Source Code
  • Stipends
  • User Interface
  • Voice
  • HTTPRequest
  • Internationalization
  • Performance
  • Physics
  • Scripts
  • Simulation
  • Teleport
  • XML-RPC
  • Account summary
  • blog.secondlife.com
  • Developer Directory
  • Events
  • forums.secondlife.com
  • Friends Online
  • Interactive map
  • jira.secondlife.com
  • Land Store
  • lindenlab.com
  • Lindex
  • New account creation
  • Public Data Feeds
  • Public Metrics & Charts
  • secondlife.com
  • teen.secondlife.com
  • wiki.secondlife.com
  • Miscellaneous
Second Life Viewer (VWR)
Las cuestiones relativas al Visor de Second Life se reportan bajo este "project".
Ejemplos:
  • "La ropa de mi avatar está completamente negra después de actualizar un driver de vídeo" (Component = Avatar/Character)
  • "Los onjetos de mi Inventario nos e meustra en el orden correcto tras desconectarme y volver a entrar" (Component = Inventory)
Second Life Service (SVC)
Las cuestiones relativas al servicio de Second Life se reportan aquí.
Ejemplos:
  • "La capacidad del servidor disminuye cuando varios avatares se teleportan a la vez a la región" (Component = Performance y/o Teleport)
  • "Mis objetos con script no funcionan tras un tiempo de inactividad del grid de Second Life" (Component = Scripts).
Second Life Website (WEB)
Las cuestiones sobre el sitio web de Second Life van en este "project".
Ejemplos:
  • "El Wiki impide conectarse a usuarios con un guión en su nombre" (Component = wiki.secondlife.com)
  • "jira.secondlife.com me boliga a identificarme siempre, incluso si he salvado mis datos de registro" (Component = jira.secondlife.com).
Second Life Miscellaneous (MISC)
Cualquier otro tipo de cuestiones debería reportarse en el "MISC project".
Ejemplos:
  • "Los TOS no me permiten editar el código fuente del visor" (Component = Miscellaneous)

Cuestiones de Seguridad -- el "missing Fifth Project"

En el Jira, el "Security project" sólo es accesible a los empleados de Linden. Pero usted puede crear ahí una nueva cuestión, y el Equipo de Seguridad recibirá un aviso inmediatamente. See la página de cuestiones de seguridad para más información sobre remitir cuestiones con informes útiles, válidos y responsables.

¿Quién es "WorkingOnIt Linden"?

Cuando se trabaja sobre una cuestión, se asigna a "WorkingOnIt Linden" para marcar su "status". Cualquier Linden tiene acceso a esta cuenta. Vea más detalles en User:WorkingOnIt Linden.

¡Encontrado un bug en el mismo on JIRA itself!

Cuando encuentre un bug u otro problema (incluyendo cuestiones sobre desarrollo) en el mismo JIRA, los Lindes esperan que usted lo reporte en el JIRA mantenido por Atlassian (el desarrollador del software de JIRA), no en el JIRA público de SL. Puede verse en http://jira.atlassian.com

Los Lindens también esperan que ponga un enlace a esa cuestión que usted ha aportado aquí.

Buscando

Parámetros

  • Buscar en el JIRA le será fácil en cuanto conozca un poco de los parámetros que usa.
  • Para leer instrucciones sobre la búsqueda del JIRA, por favor, visite JIRA query syntax y JIRA quick search.

Haciendo una búsqueda

  • En primer lugar, pulse en el enlace ""Find Issues"" que hay arriba de la pantalla.
  • Después, escriba los parámetros que desea buscar en la celda de búsqueda que hay a la izquierda de la pantalla.
  • Por ejemplo, si quiero buscar cuestiones no resueltas que tengan la palabra "avatar", debería elegir estos parámetros:
    • Project = all projects
    • Text search = avatar
    • Resolutions = Unresolved
  • Otro ejemplo pordría ser buscar cuestiones de determinado "project" que hayan sido arregladas en la última semana. Por ejemplo, quiero encontrar todos los bugs resueltos en el Visor de Second Life entre el 1 y el 14 de febrero de 2007. Debería elegir estos parámetros:
    • (Opcional: Pulse el enlace "New" en el panel de buscar para limpiar toda opción previa)
    • Project = Second Life Viewer
    • Resolution = Fixed
    • Updated After = January 31, 2007
    • Updated Before = February 15, 2007

Guardar como Filtro una búsqueda

  • Una búsqueda filter es una búsqueda que se guarda y puede compartir con otros..
  • Tras hacer una búsqueda como se describe arriba, puede salvarlo como un filtro pulsando el enlace "Save" del panel de búsqueda.
  • Ponga un nombre descriptivo a esa búsqueda, por ejemplo, "Unresolved avatar bugs in all projects."
  • Desde ese momento, puede acceder a esa búsqueda y realizarla simplemente pulsando el enlace "Filter" en la esquina superior derecha de la página. Así ahorra tiempo y trabajo, sobre todo si usa la misma búsqueda con frecuencia y quiere tener un atajo práctico para hacerla.

¿Cómo puedo ayudar?

¡Encantados de que pregunte!

Marque los Duplicados

Si se da cuenta de que una cuestión nueva es un duplicado de otra existente ya con cantidad de comentarios, votos, etc., con toda libertad escoja "Resolve" y elija "Duplicate". Pero cuando lo haga, por favor, elija también "Link", y escriba "This issue duplicates" con el número del bug original. Así todos pueden seguir qué bugs son duplicados de otros, y qué bugs son más reportados que otros. De este modo se garantiza que todos los bugs reportados con frecuencia tengan más atención, y también permite revisar los bugs duplicados para asegurarse de que en verdad lo sean.

Solucionando cuestiones de soporte

Es mejor que esto quede para usuarios técnicamente expertos, que pueden ver in situ la diferencia entre una cuestión de soporte y un bug, lo que no siempre es fácil de averiguar. Usted debe "Resolve" un informe que parezca ser una cuestión de soporte. "Resolver" una cuestión pasa al responsabilidad a quien reportó de proporcionar más información sobre por qué el informe no es una cuestión de soporte, y es -sin duda- un error que puede reproducirse y no una experiencia concreta de un usuario.

Solucionando bugs que usted no puede reproducir

Si hace exactamente lo que dicen en el bug, con el mismo entorno, y no puede reproducir el error, debe resolver el error. Tenga cuidado si es un bug relacionado con los gráficos y usted no tiene la misma tarjeta de vídeo, pues al no ser el mismo entorno no debe decidir darlo por resuelto. Una vez más, también aquí es mejor dejarlo para los usuarios técnicamente expertos.

Reproduciendo bugs

¡Esto es muy importante! Si puede crear en el informe una lista que reproduzca paso a paso el bug, ayuda a Linden Lab a concentrarse en bugs que pueden ser resueltos. Hasta que un bug no pueda reproducirse, es imposible saber si ha sido solucionado o no. Haga lo que el informe dice que se estaba haciendo, escriba paso a paso y detalladamente lo que usted hizo para que ocurriera el bug, y añádalo al bug indicando que, efectivamente, usted ha podido reproducirlo. Los bugs que tienen reproducciones constantes y firmes, tienen más prioridad en el proceso de desarrollo, y ayudan a que sea más eficiente el trabajo del "Bug Triage Team".

Recursos relacionados

¿Quiere aprender más sobre nuestro Issue Tracker?

  • Issue Tracker Forum Transcript - Información aportada por Rob y Aric Linden sobre por qué tenemos un Issue Tracker, su funcionamiento entre bastidores, y respuestas a varias cuestiones.