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!".
Second Life JIRA FAQ
Caveats
- The JIRA Issue Tracker is not for technical support, so please do not enter issues which would require a response tailored to your individual situation. Examples include:
- "I can't change my tier"
- "I have a question about the land I bought"
- "I lost part of my inventory"
- "I keep crashing!"
- "Someone stole my L$"
- "The sim I'm in is LAGGIN BAD"
- "How do I build a house?"
- More examples of misfiled issues
- The people who use the JIRA usually can't do anything about these kinds of issues, and it will most likely be a waste of time (you'll likely get only a "please contact support" reply). It also makes it harder for your fellow Residents to use the Issue Tracker. If you're looking for personal assistance, please send your message to the right place by contacting Support, and be sure to include useful details to help Linden Lab help you.
- Before reporting issues, you should first see if there is any existing information by searching the support resources, and look for the latest status reports on the Official Linden Blog.
Note: The Second Life Community Standards [LINK: http://secondlife.com/corporate/cs.php] apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker.
Examples of specific behavior or actions which may result in removal from the Issue Tracker:
- Using the Issue Tracker to promote your business, cause, blog, website or anything not directly related to the issue at hand.
- Flaming - The act of posting a message that is intended to incite anger or directly attack a person or persons is called "Flaming" and it not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.
- Private Discussions - Blogging your personal opinions or off-topic rants. Pjira is about finding solutions to issues. We love productive feedback. Please stick to the technical details of the matter at hand.
Logging in
- Visit https://jira.secondlife.com and click the 'Log In' link on the top right of the page
- On the login page, enter your Second Life username and password.
- This will now load the main Jira page you saw before but it will have more options, like "Create Issue", a link to edit your profile, and some pre-defined filters.
Bugs & New Features
- You may wish to look through Bug Reporting 101 for things to try before submitting a bug.
- You can also propose new features through JIRA. (JIRA is the successor the Feature Voting Tool, because it has better search and parallels the way the Lindens internally organize issues. Plus, you can discuss with other Residents.)
User profile
- Each JIRA user has a profile. The profile consists of your Username (SL name), Fullname (in our case, also your SL name), and all of the JIRA groups you belong to. For most people, this means "jira-users."
- The email address associated with your account shall remain anonymous to other users. The address is not visible or configurable at this time. Direct import of your email address from Second Life's database is currently disabled.
- The JIRA profile is not editable because allowing changes would introduce conflicts with your Second Life account. If you wish to edit account information such as your email address, please login to the account management page at secondlife.com.
Customizing preferences
- If you want to show more issues per page or change the language JIRA's displayed in, Update User Preferences after logging in.
Projects and Components
- Projects are used to categorize issues into logical groups.
- Components are used to specify which part of a system the issue affects. In other words, what is the scope of the problem within a project.
| Viewer (VWR) | Service (SVC) | Website (WEB) | Miscellaneous (MISC) |
|---|---|---|---|
|
|
|
|
- Second Life Viewer (VWR)
- Issues pertaining to the Second Life viewer are reported under this project.
- Examples:
- "My avatar clothing is all black after installing a video driver update" (Component = Avatar/Character)
- "Objects in my Inventory do not remain sorted in the correct order after logging out and back in again" (Component = Inventory)
- Second Life Service (SVC)
- Issues pertaining to the Second Life service are reported here.
- Examples:
- "Server performance decreases when several avatars teleport into the region at once" (Component = Performance and/or Teleport)
- "My scripted objects are not able to talk to the outside world after Second Life grid downtime" (Component = Scripts).
- Second Life Website (WEB)
- Issues pertaining to the Second Life website are in this project.
- Examples:
- "Wiki prevents login for users with a dash in their name" (Component = wiki.secondlife.com)
- "jira.secondlife.com always forces me to authenticate even if I save my login information" (Component = jira.secondlife.com).
- Second Life Miscellaneous (MISC)
- Any other type of issue should be reported in the MISC project.
- Example:
- "The TOS does not allow me to edit the viewer source code" (Component = Miscellaneous)
Security Issues -- a.k.a "the missing Fifth Project"
The Security project in Jira is only accessible by Linden employees. However, you can create a new issue there, and the security team will get immediate notification. See security issues page for more information about submitting issues and collecting bounties for responsibly reporting valid security issues.
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.