Bug Tracker/es
|
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 |
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!
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.
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
- Por ejemplo:
- ¡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.
- Antes de enviar cuestiones, debería mirar si no hay ya información buscando en los recursos para soporte y en los últimos informes del Blog oficial de Linden Lab.
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".
| Viewer (VWR) | Service (SVC) | Website (WEB) | Miscellaneous (MISC) |
|---|---|---|---|
|
|
|
|
- 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.
Who is WorkingOnIt Linden?
When an issue is being worked on, it may be assigned to "WorkingOnIt Linden" to mark its status. Any Linden has access to the account. See User:WorkingOnIt Linden for details.
Found a bug on JIRA itself!
When you found a bug or other problem (including feature request) on the JIRA itself, Lindens want you to file it on the JIRA run by Atlassian (the developer of JIRA software) by yourself, not thgough the SL public JIRA. It is available on http://jira.atlassian.com
Lindens also want you to put a link to the issue you filed here if you do so.
Searching
Parameters
- JIRA searching is easy once you know a bit about the parameters you may use.
- For instructions on searching in JIRA, please visit JIRA query syntax and JIRA quick search.
Perform a search
- First, click on the "Find Issues" link at the top of the screen.
- Next, enter the parameters you wish to search for in the search pane on the left-hand side of the screen.
- As an example, if I wish to search for issues that have not been resolved containing the word "avatar", I would choose the following parameters:
- Project = all projects
- Text search = avatar
- Resolutions = Unresolved
- Another sample search would be for any issues that are fixed in the last week in a particular project. For example, I want to find all bugs in the Second Life Viewer project that were resolved between February 1, 2007 and February 14, 2007. I would enter the following parameters:
- (Optional: Click the "New" link in the search pane to clear settings from any previous searches)
- Project = Second Life Viewer
- Resolution = Fixed
- Updated After = January 31, 2007
- Updated Before = February 15, 2007
Saving a search as a Filter
- A search filter is a saved search that you may share with others.
- After performing a search as described above, you may save it as a filter by clicking the "Save" link in the Search pane.
- Name the filter something meaningful, for example "Unresolved avatar bugs in all projects."
- Now you can access the search and run it at any time by clicking the "Filter" link in the top right-hand side of the page. This saves time and effort, especially if you frequently run the same complex search and want a handy shortcut!
How do I help out?
Glad you asked!
Marking Duplicates
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.
Resolving support issues
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.
Resolving bugs that you can't reproduce
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.
Reproducing 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.
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.