Sistema de bugs

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!.     ( y otras páginas pendientes)

La detección y seguimiento de bugs es un proceso continuo de control de calidad. A diferencia de muchas aplicaciones propietarias, el envío y seguimiento de información sobre bugs está abierto a todo el mundo. El sistema de seguimiento de bugs de Moodle se llama Tracker.

Si es un nuevo usuario del Tracker, realice el proceso de alta aquí. Es recomendable que utilice como nombre de usuario, el mismo que el que tiene en el sitio moodle.org. Si su cuenta de acceso al Tracker no funciona, por favor intente recuperar la contraseña aquí.

"Fallos" no sólo incluye fallos de software de las versiones actuales de Moodle, sino también nuevas ideas, mejoras e incluso crítica constructiva de las actuales características.

La belleza del código abierto radica en que cualquiera puede participar de alguna manera y ayudar a la creación de un producto mejor para que todos disfrutemos de él. ¡En este proyecto sus ideas son muy bienvenidas!

Report a bug

1. Once you have loged in and are at the Moodle Tracker home page
2. Select "Create New Issue" from the menu under the Moodle Tracker logo
3. On Step 1, from the dropdown menu select the "Issue type": Bug, New Feature, Task or Improvement
4. On Step 2, you will see a series of dropdown and blank content areas.
   1. Summary: A headline summary of the problem. Try to make it as precise as possible without making it too long. "It doesn't work" is completely useless. Think about keywords people might type into the search box if looking for this issue, and try to include them.
   2. Components: Use the Ctrl key with a mouse click to select one or more areas in Moodle. For example, you might have found an issue with a question that impacts: Lesson, Quiz and Question components
   3. Select the Version but if it is not listed, put it in the description
   4. Environment is for Operating Systems and other stuff. See general guidlines below
   5. Description tells what is the issue. See general guidelines below for the best description
   6. Database, if it is not listed put it in environment with its version number

General reporting guidelines

The best bug reports contain these elements in the form:

1. Steps to reproduce. That is, a detailed sequence of steps a developer can follow to see the problem. It is very hard to fix a bug that is not reproducible. If possible, provide a URL so we can see the problem with one click.
2. What I expected to happen. Again, provide as much detail as possible. Your expectation might mean that our instructions need to be improved or our interface should be changed.
3. What actually happened (with detail).

Here is an example of a good bug report in browse view, and here is another.

• If you have an error message, or information in your PHP or web server logs, copy and paste it into the bug report. If you can, turn on "debug" in your Admin configuration page and reproduce the problem to get the best possible error message.
• Screen shots are very helpful for some bugs, but please write a textual description of the problem too.
• Make sure we know everything we need to know about your setup including operating system, database, etc. If you run out of room in the environment section, add more detail in the description. The full set of information that might be relevant is:
  • Server operating system type and version number
  • Web server type and version number
  • PHP version number (and whether you are using an accellerator)
  • Database type and version number
  • Moodle version (there is a dropdown menu on the top of the form, if that does not have what you want, add it in the description)
  • Client-side operating system type and version number
  • Web browser type and version number

You don't need to give all those details all the time. For example, for a layout rendering problem, you need to give only the client-side OS and browser info, and if it is a server-side problem you only need to describe the setup there. Use your judgement. Here are some examples:

I see this bug with the latest Moodle HEAD running on PHP5.1.2/Apache 2.2.3 on Linux. My database is Postgres 8.1.

This rendering problem happens using Internet Explorer 6.0 on Windows XP.

In summary stick with facts and present enough facts so someone else can duplicate the problem.

What the priority levels mean

Bugs can be assigned to one of five priority levels. Here is some guidance as to which one to use:

Blocker

This bug completely breaks Moodle, and the next release must be considered "blocked" until this is done.

Critical

This bug is causing data loss, serious visible errors for uses, or major parts of Moodle to cease to function.

Major

Somthing is broken and there is no way round it, although it is not a serious as a Critical bug, we can't live with it for long.

Minor

Something is wrong, but it is possible to live with it for a while, maybe because there is a workaround.

Trivial

Something is wrong, and should be fixed eventually when someone has the time, but it is not a big deal to live with it.

Tracking progress of bugs you have reported

You will receive email reports of updates to bugs you report.

Tracking bugs reported by others

You can monitor, or "watch" bugs reported by others. To do this, open the bug, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your bug, open the bug, select the option "Watching" from the left hand navigation panel. These people will recevie email notification when updates are made to this bug.

Comentarios de los desarrolladores

"¿Cuál es la parte más complicada de un bug?": La mayoría de las ocasiones, solucionar el bug es la parte más sencilla. Normalmente la parte más difícil es reproducir el bug en los equipos de desarrollo. El programador necesita confirmar cómo afecta el bug antes de ser capaz de arreglarlo. Y si no es capaz de reproducir el problema no pordrá estar seguro de que lo ha solucionado.

Las buenas notificaciones de bugs deben incluir tanta información como sea posible y ser específicas. Generalizar o incluir valoraciones subjetivas en un bug no sirve de ayuda y, en muchas ocasiones, resulta contraproducente.

Por ejemplo, un bug que dice "Los canales RSS no soportan UTF-8" no sirve de gran ayuda. El desarrollador sabe que RSS y UTF-8 son compatibles. Además no tiene ninguna información sobre lo que la persona está viendo o la razón por la que envió el bug. En estos casos se impone más comunicación (que es tiempo) para determinar que ha sucedido realmente.

Por ello es recomendable crear el bug con información más específica como "El canal RSS XYZ muestra caracteres incorrectos desde Internet Explorer".

Ver también

• Using Moodle: Discusión sobre cómo manipular a los desarrolladores de Moodle (en inglés)
• Aquí hay una definición de un bug (en inglés) y en castellano.