{"id":640,"date":"2026-07-22T08:16:48","date_gmt":"2026-07-22T08:16:48","guid":{"rendered":"https:\/\/matforge.org\/?p=640","raw":"https:\/\/matforge.org\/?p=640"},"modified":"2026-07-22T08:16:48","modified_gmt":"2026-07-22T08:16:48","slug":"feature-requests-vs-bug-reports-knowing-the-difference","status":"publish","type":"post","link":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/","title":{"rendered":"Solicitudes de funciones frente a informes de errores: conocer la diferencia","raw":"Solicitudes de funciones frente a informes de errores: conocer la diferencia"},"content":{"rendered":"Reading Time: <\/span> 7<\/span> minutes<\/span><\/span>

En el software cient\u00edfico y de ingenier\u00eda, la mayor parte de la frustraci\u00f3n no proviene de problemas dif\u00edciles: proviene de declaraciones de problemas poco claras. Un ticket que \u00absuena mal\u00bb en realidad podr\u00eda describir una capacidad faltante. Una solicitud de una \u00abpeque\u00f1a mejora\u00bb podr\u00eda estar enmascarando un defecto que da\u00f1a los resultados. Cuando los equipos clasifican err\u00f3neamente las entradas, pierden el tiempo: los desarrolladores investigan los errores fantasmas, los investigadores esperan las caracter\u00edsticas que nunca fueron de alcance y las prioridades se desviaron.<\/p>\n

Esta gu\u00eda lo ayuda a decidir r\u00e1pidamente si algo es un informe de error o una solicitud de funci\u00f3n, y muestra c\u00f3mo escribir cada uno para que el equipo pueda actuar en consecuencia. El objetivo es simple: menos comentarios de ida y vuelta, triaje m\u00e1s r\u00e1pido y menos sorpresas en los lanzamientos.<\/p>\n

Por qu\u00e9 es importante la distinci\u00f3n<\/h2>\n

Los informes de errores y las solicitudes de funciones se manejan de manera diferente en la mayor\u00eda de los flujos de trabajo (trac, jira, problemas de github, redmine, etc.). Tienen una urgencia diferente, diferentes criterios de aceptaci\u00f3n y diferentes formas de probar y cerrar el bucle.<\/p>\n

    \n
  • Un informe de error generalmente tiene una expectativa de correcci\u00f3n: el software viola su propio contrato, documentaci\u00f3n o comportamiento establecido.<\/li>\n
  • Una solicitud de funci\u00f3n solicita un nuevo comportamiento: algo que el software no promete hacer actualmente, incluso si ser\u00eda \u00fatil.<\/li>\n<\/ul>\n

    Cuando etiqueta el ticket correctamente, el triaje se vuelve m\u00e1s f\u00e1cil: los mantenedores pueden reproducir, priorizar y asignar trabajo sin adivinar qu\u00e9 \u00abdeber\u00eda\u00bb suceder.<\/p>\n

    Las definiciones centrales<\/h2>\n

    \u00bfQu\u00e9 es un informe de error?<\/h3>\n

    Un error es cuando el sistema se comporta incorrectamente en comparaci\u00f3n con un punto de referencia acordado. Ese punto de referencia puede ser:<\/p>\n

      \n
    • Documentaci\u00f3n o una interfaz publicada (contrato API)<\/li>\n
    • Comportamiento estable anterior (una regresi\u00f3n)<\/li>\n
    • Correcci\u00f3n cient\u00edfica (por ejemplo, leyes de conservaci\u00f3n, invariantes esperados, consistencia unitaria)<\/li>\n
    • Requisitos claramente establecidos (incluyendo pruebas o especificaciones)<\/li>\n<\/ul>\n

      En resumen: un informe de error describe un error que debe solucionarse para restaurar la correcci\u00f3n.<\/p>\n

      \u00bfQu\u00e9 es una solicitud de funci\u00f3n?<\/h3>\n

      Una solicitud de funci\u00f3n propone una capacidad o mejora que har\u00eda que el sistema sea m\u00e1s \u00fatil, flexible o eficiente, pero no se requiere para la correcci\u00f3n del comportamiento actual. Los ejemplos incluyen:<\/p>\n

        \n
      • Apoyar un nuevo tipo de condici\u00f3n de contorno<\/li>\n
      • Agregar un exportador para un nuevo formato de archivo<\/li>\n
      • Mejorar el rendimiento m\u00e1s all\u00e1 de los objetivos actuales<\/li>\n
      • Agregar opciones de UI\/CLI que a\u00fan no existen<\/li>\n<\/ul>\n

        En resumen: una solicitud de funci\u00f3n describe algo nuevo que el sistema deber\u00eda hacer.<\/p>\n

        Lista de verificaci\u00f3n de decisi\u00f3n r\u00e1pida<\/h2>\n

        Si solo recuerdas una regla, usa esta:<\/p>\n

          \n
        • Si el software rompe una promesa, es un error.<\/li>\n
        • Si quieres una nueva promesa, es una caracter\u00edstica.<\/li>\n<\/ul>\n

          H\u00e1gase estas preguntas:<\/p>\n

            \n
          1. \u00bfAlguna vez funcion\u00f3 antes en el mismo escenario? En caso afirmativo, probablemente un error (posiblemente una regresi\u00f3n).<\/li>\n
          2. \u00bfHay documentaci\u00f3n que indique que el comportamiento deber\u00eda funcionar? Si es as\u00ed, error.<\/li>\n
          3. \u00bfEl comportamiento es ambiguo y est\u00e1s proponiendo lo que deber\u00eda ser? probablemente una caracter\u00edstica (o una aclaraci\u00f3n de especificaciones primero).<\/li>\n
          4. \u00bfEl problema es que no puedes hacer algo en absoluto, pero nada est\u00e1 \u00abincorrecto\u00bb con las salidas existentes? probablemente una caracter\u00edstica.<\/li>\n
          5. \u00bfProduce resultados incorrectos, fallas, datos da\u00f1ados o viola las restricciones f\u00edsicas? bicho<\/li>\n<\/ol>\n

            Comparaci\u00f3n lado a lado<\/h2>\n\n\n\n\n\n\n\n\n
            Aspecto<\/th>\nInforme de error<\/th>\nPetici\u00f3n de funci\u00f3n<\/th>\n<\/tr>\n
            Significado<\/td>\nalgo est\u00e1 mal en comparaci\u00f3n con el comportamiento esperado<\/td>\nse desea algo nuevo o mejorado<\/td>\n<\/tr>\n
            punto de referencia<\/td>\nDocumentos, pruebas, versiones anteriores, criterios de correcci\u00f3n<\/td>\nNecesidades del usuario, objetivos de investigaci\u00f3n, mejoras de usabilidad<\/td>\n<\/tr>\n
            Evidencia t\u00edpica<\/td>\nPasos de reproducci\u00f3n, registros, salida incorrecta, rastreo de bloqueo<\/td>\nCaso de uso, beneficio, comportamiento propuesto, criterios de aceptaci\u00f3n<\/td>\n<\/tr>\n
            Conductores de prioridad<\/td>\nGravedad, alcance, frecuencia, riesgo a los resultados<\/td>\nImpacto, demanda, hoja de ruta estrat\u00e9gica, esfuerzo<\/td>\n<\/tr>\n
            C\u00f3mo est\u00e1 \u201checho\u201d<\/td>\nsoluci\u00f3n verificada; pases de prueba; Regresi\u00f3n evitada<\/td>\nespecificaci\u00f3n implementada; documentado; de extremo a extremo utilizable<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            Ejemplos en Computaci\u00f3n Cient\u00edfica<\/h2>\n

            Ejemplo 1: Resultados incorrectos debido a la falta de coincidencia de unidades<\/h3>\n

            Ejecuta una simulaci\u00f3n y observa que un par\u00e1metro documentado como \u00abmetros\u00bb se trata como \u00abmil\u00edmetros\u00bb, cambiando los resultados en 1000 \u00d7. Si la documentaci\u00f3n y el c\u00f3digo no est\u00e1n de acuerdo, y las salidas son incorrectas para el uso documentado, ese es un informe de error. Su boleto debe incluir el par\u00e1metro, donde est\u00e9 documentado, un caso m\u00ednimo y evidencia de desajuste.<\/p>\n

            Ejemplo 2: necesita un nuevo t\u00e9rmino PDE o acoplamiento<\/h3>\n

            Desea agregar un t\u00e9rmino de electromigraci\u00f3n a un modelo de transporte existente. El c\u00f3digo actual funciona seg\u00fan lo dise\u00f1ado; Simplemente no incluye esa f\u00edsica. Esa es una solicitud de funci\u00f3n. Su ticket debe explicar la ecuaci\u00f3n de gobierno, las entradas esperadas y c\u00f3mo la validar\u00eda (referencias o l\u00edmites anal\u00edticos).<\/p>\n

            Ejemplo 3: \u00abEs demasiado lento\u00bb<\/h3>\n

            El rendimiento puede ser cualquiera. Si el c\u00f3digo sol\u00eda ejecutarse en 5 minutos y ahora toma 50 minutos en la misma configuraci\u00f3n, eso es un error (una regresi\u00f3n de rendimiento). Si el c\u00f3digo siempre ha tomado 50 minutos y desea que tome 5, esa es una solicitud de funci\u00f3n (funcionamiento de optimizaci\u00f3n), a menos que la lentitud provenga de un comportamiento no deseado (como un solucionador atascado debido a un problema de convergencia).<\/p>\n

            Ejemplo 4: Mensaje de error confuso<\/h3>\n

            Un mensaje de error confuso suele ser una solicitud de funci\u00f3n (mejora UX), a menos que el mensaje sea incorrecto o enmascara el error real de una manera que impida el diagn\u00f3stico. En muchos equipos, \u00abmejorar mensaje de error\u00bb se rastrea como una mejora, no como un error.<\/p>\n

            Clasificaciones err\u00f3neas comunes y c\u00f3mo solucionarlas<\/h2>\n

            Clasificaci\u00f3n err\u00f3nea: \u00abse bloquea\u00bb (pero solo con entrada no v\u00e1lida)<\/h3>\n

            Si el software se bloquea cuando se le da una entrada no v\u00e1lida, podr\u00eda ser un error si el programa falla con gracia (error claro, no hay archivos da\u00f1ados). Si se espera bloquear porque la entrada est\u00e1 fuera de las restricciones admitidas y la herramienta ya lo documenta, podr\u00eda ser una solicitud de mejora para mejorar la validaci\u00f3n y los mensajes.<\/p>\n

            Clasificaci\u00f3n err\u00f3nea: \u00abEl resultado se ve mal\u00bb (pero las expectativas no est\u00e1n claras)<\/h3>\n

            Si el ticket no define lo que significa \u00abcorrecto\u00bb, los mantenedores no pueden decidir el error frente a la funci\u00f3n. En ese caso, escriba el boleto como una pregunta m\u00e1s una expectativa propuesta y adjunte pruebas. A menudo, el mejor primer paso es: \u00abaclarar el comportamiento esperado\u00bb, luego volver a presentarlo como error o caracter\u00edstica una vez confirmado.<\/p>\n

            Clasificaci\u00f3n err\u00f3nea: \u00abPor favor agregue la opci\u00f3n X\u00bb (pero el c\u00f3digo ya lo admite)<\/h3>\n

            Esto no es una caracter\u00edstica ni un error en el comportamiento central; puede ser una brecha de documentaci\u00f3n. Si la capacidad existe pero es dif\u00edcil de descubrir, cree un ticket de documento (o una mejora centrada en la usabilidad).<\/p>\n

            C\u00f3mo escribir un informe de error de alta calidad<\/h2>\n

            Un buen informe de error facilita la reproducci\u00f3n, el diagn\u00f3stico y la verificaci\u00f3n de la soluci\u00f3n.<\/p>\n

            Plantilla de informe de error<\/h3>\n
              \n
            • Resumen: Una oraci\u00f3n que describe el comportamiento incorrecto<\/li>\n
            • Entorno: OS, versi\u00f3n de Python\/C++, versi\u00f3n de paquete\/commit, versiones de MPI\/Solver si es relevante<\/li>\n
            • Pasos para reproducir: pasos m\u00ednimos, archivos de entrada m\u00ednimos, fragmento de c\u00f3digo m\u00ednimo<\/li>\n
            • Resultado esperado: qu\u00e9 deber\u00eda suceder y por qu\u00e9 (docs\/pruebas\/comportamiento anterior)<\/li>\n
            • Resultado real: lo que sucede en su lugar (registros, seguimiento de pila, capturas de pantalla, diferencial de salida)<\/li>\n
            • Impacto: Gravedad (Crash, Ciencias Incorrectas, IU Menor), Frecuencia, Soluci\u00f3n Si la tiene<\/li>\n<\/ul>\n

              Ejemplo de informe de error (corto)<\/h3>\n

              Resumen: El ejemplo de difusi\u00f3n falla con Dirichlet BC en la cuadr\u00edcula 3D.<\/p>\n

                \n
              • Esperado: La simulaci\u00f3n se ejecuta y produce valores de campo estables como en 2D.<\/li>\n
              • Actual: Solver diverge despu\u00e9s de n pasos; Los valores se convierten en NaN.<\/li>\n
              • Evidencia: Proporcione un script m\u00ednimo, valores de par\u00e1metros y salida de registro.<\/li>\n<\/ul>\n

                C\u00f3mo escribir una solicitud de funci\u00f3n s\u00f3lida<\/h2>\n

                Una fuerte solicitud de funci\u00f3n se lee como un mini dise\u00f1o. Nota: explica por qu\u00e9 la capacidad es importante, c\u00f3mo se ve \u00abhecho\u00bb y c\u00f3mo lo verificar\u00e1.<\/p>\n

                Plantilla de solicitud de funci\u00f3n<\/h3>\n
                  \n
                • Declaraci\u00f3n del problema: lo que no puedes hacer hoy<\/li>\n
                • Caso de uso: qui\u00e9n lo necesita y por qu\u00e9 (flujo de trabajo de investigaci\u00f3n, m\u00f3dulo de ense\u00f1anza, canalizaci\u00f3n de producci\u00f3n)<\/li>\n
                • Soluci\u00f3n propuesta: comportamiento de alto nivel, cambios de interfaz de usuario\/API, valores predeterminados<\/li>\n
                • Criterios de aceptaci\u00f3n: lo que debe ser cierto para considerarlo completo<\/li>\n
                • Validaci\u00f3n: c\u00f3mo probar (benchmarks, tests unit, soluciones anal\u00edticas, suite de regresi\u00f3n)<\/li>\n
                • Alternativas consideradas: soluciones alternativas u otros enfoques<\/li>\n<\/ul>\n

                  Ejemplo de solicitud de funci\u00f3n (corto)<\/h3>\n

                  Solicitud: agregue una opci\u00f3n para exportar el estado de simulaci\u00f3n a un formato de visualizaci\u00f3n estandarizado a intervalos configurables.<\/p>\n

                    \n
                  • Caso de uso: grandes ejecuciones en HPC donde se necesita una visualizaci\u00f3n intermedia para el monitoreo.<\/li>\n
                  • Aceptaci\u00f3n: Obras de exportaci\u00f3n para redes 2D\/3D; Incluye metadatos (paso de tiempo, unidades); Sin ralentizaci\u00f3n importante.<\/li>\n
                  • Validaci\u00f3n: comparar campos exportados con matrices en memoria; Aseg\u00farese de que la recarga reproduce el estado dentro de la tolerancia.<\/li>\n<\/ul>\n

                    Cuando un boleto debe convertirse en dos<\/h2>\n

                    Muchos problemas del mundo real mezclan errores y caracter\u00edsticas. Dividirlos a menudo acelera el progreso.<\/p>\n

                      \n
                    • Si hay un accidente (error) y tambi\u00e9n un deseo de un mensaje m\u00e1s agradable (caracter\u00edstica), presente dos boletos.<\/li>\n
                    • Si hay un problema de correcci\u00f3n (BUG) y tambi\u00e9n una solicitud para respaldar un nuevo r\u00e9gimen, separe el \u00abcomportamiento actual\u00bb de la \u00abcapacidad de extensi\u00f3n\u00bb.<\/li>\n
                    • Si la solicitud es \u00abhacerlo m\u00e1s r\u00e1pido\u00bb pero sospecha una regresi\u00f3n, presente un error para la regresi\u00f3n y una funci\u00f3n para una mayor optimizaci\u00f3n.<\/li>\n<\/ul>\n

                      Dividir boletos permite a los equipos cerrar el error r\u00e1pidamente y programar la mejora con sensatez.<\/p>\n

                      Consejos de triaje para mantenedores y clientes potenciales<\/h2>\n

                      Use etiquetas y un comentario de decisi\u00f3n corta<\/h3>\n

                      Cuando un ticket llegue ambiguo, agregue un breve comentario que bloquee la clasificaci\u00f3n:<\/p>\n

                        \n
                      • \u201cClasificando como error porque el comportamiento contradice la secci\u00f3n de documentaci\u00f3n X\u201d.<\/li>\n
                      • \u00abClasificaci\u00f3n como solicitud de funci\u00f3n porque esto agrega una nueva capacidad de solucionador que no es compatible actualmente\u00bb.<\/li>\n<\/ul>\n

                        Requieren criterios m\u00ednimos de aceptaci\u00f3n para las caracter\u00edsticas<\/h3>\n

                        Las solicitudes de funci\u00f3n fallan cuando \u00abhecho\u00bb no est\u00e1 claro. Pregunte por los criterios de aceptaci\u00f3n temprano: qu\u00e9 salida, qu\u00e9 interfaz, qu\u00e9 pruebas, qu\u00e9 ejemplo. Una caracter\u00edstica sin criterios de aceptaci\u00f3n es efectivamente un elemento de la lista de deseos.<\/p>\n

                        Convierta las preguntas recurrentes en tareas de documentaci\u00f3n<\/h3>\n

                        Si m\u00faltiples \u00absolicitudes de funciones\u00bb son en realidad solicitudes de orientaci\u00f3n (\u00ab\u00bfC\u00f3mo hago yo…?\u00bb), Capture las como mejoras en los documentos. Esto es especialmente com\u00fan en las bibliotecas cient\u00edficas donde existen capacidades pero no son obvias.<\/p>\n

                        Plantillas pr\u00e1cticas que puedes copiar en tickets<\/h2>\n

                        Clasificador de una sola l\u00ednea<\/h3>\n

                        Use esto como la primera l\u00ednea de su descripci\u00f3n de su boleto:<\/p>\n

                          \n
                        • ERROR: \u201cEl comportamiento observado contradice el comportamiento esperado definido por [docs\/test\/previous version]\u201d.<\/li>\n
                        • Caracter\u00edstica: \u00abNueva capacidad necesaria para admitir [use case], no disponible actualmente\u00bb.<\/li>\n<\/ul>\n

                          Criterios de aceptaci\u00f3n Set de inicio para funciones<\/h3>\n
                            \n
                          • API: nueva opci\u00f3n\/par\u00e1metro documentado con valores predeterminados<\/li>\n
                          • Ejemplo: Ejemplo de trabajo m\u00ednimo incluido en documentos\/ejemplos<\/li>\n
                          • Pruebas: al menos una prueba automatizada cubre el comportamiento principal<\/li>\n
                          • Compatibilidad con versiones anteriores: los scripts existentes contin\u00faan ejecut\u00e1ndose sin cambios (o pasos de migraci\u00f3n documentados)<\/li>\n<\/ul>\n

                            Conclusi\u00f3n<\/h2>\n

                            Los informes de errores restauran la confianza; Las solicitudes de funciones expanden la capacidad. Ambos son esenciales en el software cient\u00edfico, pero solo tienen \u00e9xito cuando est\u00e1n escritos con la intenci\u00f3n y la evidencia correctas. Si vincula los errores a un punto de referencia y vincula las caracter\u00edsticas a un caso de uso claro con criterios de aceptaci\u00f3n, reducir\u00e1 la fricci\u00f3n de clasificaci\u00f3n, acelerar\u00e1 el desarrollo y har\u00e1 que las versiones sean m\u00e1s predecibles, lo que en \u00faltima instancia mejora la velocidad de investigaci\u00f3n y la fiabilidad de los resultados.<\/p>\n","protected":false,"raw":"

                            En el software cient\u00edfico y de ingenier\u00eda, la mayor parte de la frustraci\u00f3n no proviene de problemas dif\u00edciles: proviene de declaraciones de problemas poco claras. Un ticket que \"suena mal\" en realidad podr\u00eda describir una capacidad faltante. Una solicitud de una \"peque\u00f1a mejora\" podr\u00eda estar enmascarando un defecto que da\u00f1a los resultados. Cuando los equipos clasifican err\u00f3neamente las entradas, pierden el tiempo: los desarrolladores investigan los errores fantasmas, los investigadores esperan las caracter\u00edsticas que nunca fueron de alcance y las prioridades se desviaron.<\/p>\n

                            Esta gu\u00eda lo ayuda a decidir r\u00e1pidamente si algo es un informe de error o una solicitud de funci\u00f3n, y muestra c\u00f3mo escribir cada uno para que el equipo pueda actuar en consecuencia. El objetivo es simple: menos comentarios de ida y vuelta, triaje m\u00e1s r\u00e1pido y menos sorpresas en los lanzamientos.<\/p>\n

                            Por qu\u00e9 es importante la distinci\u00f3n<\/h2>\n

                            Los informes de errores y las solicitudes de funciones se manejan de manera diferente en la mayor\u00eda de los flujos de trabajo (trac, jira, problemas de github, redmine, etc.). Tienen una urgencia diferente, diferentes criterios de aceptaci\u00f3n y diferentes formas de probar y cerrar el bucle.<\/p>\n

                              \n
                            • Un informe de error generalmente tiene una expectativa de correcci\u00f3n: el software viola su propio contrato, documentaci\u00f3n o comportamiento establecido.<\/li>\n
                            • Una solicitud de funci\u00f3n solicita un nuevo comportamiento: algo que el software no promete hacer actualmente, incluso si ser\u00eda \u00fatil.<\/li>\n<\/ul>\n

                              Cuando etiqueta el ticket correctamente, el triaje se vuelve m\u00e1s f\u00e1cil: los mantenedores pueden reproducir, priorizar y asignar trabajo sin adivinar qu\u00e9 \"deber\u00eda\" suceder.<\/p>\n

                              Las definiciones centrales<\/h2>\n

                              \u00bfQu\u00e9 es un informe de error?<\/h3>\n

                              Un error es cuando el sistema se comporta incorrectamente en comparaci\u00f3n con un punto de referencia acordado. Ese punto de referencia puede ser:<\/p>\n

                                \n
                              • Documentaci\u00f3n o una interfaz publicada (contrato API)<\/li>\n
                              • Comportamiento estable anterior (una regresi\u00f3n)<\/li>\n
                              • Correcci\u00f3n cient\u00edfica (por ejemplo, leyes de conservaci\u00f3n, invariantes esperados, consistencia unitaria)<\/li>\n
                              • Requisitos claramente establecidos (incluyendo pruebas o especificaciones)<\/li>\n<\/ul>\n

                                En resumen: un informe de error describe un error que debe solucionarse para restaurar la correcci\u00f3n.<\/p>\n

                                \u00bfQu\u00e9 es una solicitud de funci\u00f3n?<\/h3>\n

                                Una solicitud de funci\u00f3n propone una capacidad o mejora que har\u00eda que el sistema sea m\u00e1s \u00fatil, flexible o eficiente, pero no se requiere para la correcci\u00f3n del comportamiento actual. Los ejemplos incluyen:<\/p>\n

                                  \n
                                • Apoyar un nuevo tipo de condici\u00f3n de contorno<\/li>\n
                                • Agregar un exportador para un nuevo formato de archivo<\/li>\n
                                • Mejorar el rendimiento m\u00e1s all\u00e1 de los objetivos actuales<\/li>\n
                                • Agregar opciones de UI\/CLI que a\u00fan no existen<\/li>\n<\/ul>\n

                                  En resumen: una solicitud de funci\u00f3n describe algo nuevo que el sistema deber\u00eda hacer.<\/p>\n

                                  Lista de verificaci\u00f3n de decisi\u00f3n r\u00e1pida<\/h2>\n

                                  Si solo recuerdas una regla, usa esta:<\/p>\n

                                    \n
                                  • Si el software rompe una promesa, es un error.<\/li>\n
                                  • Si quieres una nueva promesa, es una caracter\u00edstica.<\/li>\n<\/ul>\n

                                    H\u00e1gase estas preguntas:<\/p>\n

                                      \n
                                    1. \u00bfAlguna vez funcion\u00f3 antes en el mismo escenario? En caso afirmativo, probablemente un error (posiblemente una regresi\u00f3n).<\/li>\n
                                    2. \u00bfHay documentaci\u00f3n que indique que el comportamiento deber\u00eda funcionar? Si es as\u00ed, error.<\/li>\n
                                    3. \u00bfEl comportamiento es ambiguo y est\u00e1s proponiendo lo que deber\u00eda ser? probablemente una caracter\u00edstica (o una aclaraci\u00f3n de especificaciones primero).<\/li>\n
                                    4. \u00bfEl problema es que no puedes hacer algo en absoluto, pero nada est\u00e1 \"incorrecto\" con las salidas existentes? probablemente una caracter\u00edstica.<\/li>\n
                                    5. \u00bfProduce resultados incorrectos, fallas, datos da\u00f1ados o viola las restricciones f\u00edsicas? bicho<\/li>\n<\/ol>\n

                                      Comparaci\u00f3n lado a lado<\/h2>\n\n\n\n\n\n\n\n
                                      Aspecto<\/th>\nInforme de error<\/th>\nPetici\u00f3n de funci\u00f3n<\/th>\n<\/tr>\n
                                      Significado<\/td>\nalgo est\u00e1 mal en comparaci\u00f3n con el comportamiento esperado<\/td>\nse desea algo nuevo o mejorado<\/td>\n<\/tr>\n
                                      punto de referencia<\/td>\nDocumentos, pruebas, versiones anteriores, criterios de correcci\u00f3n<\/td>\nNecesidades del usuario, objetivos de investigaci\u00f3n, mejoras de usabilidad<\/td>\n<\/tr>\n
                                      Evidencia t\u00edpica<\/td>\nPasos de reproducci\u00f3n, registros, salida incorrecta, rastreo de bloqueo<\/td>\nCaso de uso, beneficio, comportamiento propuesto, criterios de aceptaci\u00f3n<\/td>\n<\/tr>\n
                                      Conductores de prioridad<\/td>\nGravedad, alcance, frecuencia, riesgo a los resultados<\/td>\nImpacto, demanda, hoja de ruta estrat\u00e9gica, esfuerzo<\/td>\n<\/tr>\n
                                      C\u00f3mo est\u00e1 \u201checho\u201d<\/td>\nsoluci\u00f3n verificada; pases de prueba; Regresi\u00f3n evitada<\/td>\nespecificaci\u00f3n implementada; documentado; de extremo a extremo utilizable<\/td>\n<\/tr>\n<\/tbody><\/table>\n

                                      Ejemplos en Computaci\u00f3n Cient\u00edfica<\/h2>\n

                                      Ejemplo 1: Resultados incorrectos debido a la falta de coincidencia de unidades<\/h3>\n

                                      Ejecuta una simulaci\u00f3n y observa que un par\u00e1metro documentado como \"metros\" se trata como \"mil\u00edmetros\", cambiando los resultados en 1000 \u00d7. Si la documentaci\u00f3n y el c\u00f3digo no est\u00e1n de acuerdo, y las salidas son incorrectas para el uso documentado, ese es un informe de error. Su boleto debe incluir el par\u00e1metro, donde est\u00e9 documentado, un caso m\u00ednimo y evidencia de desajuste.<\/p>\n

                                      Ejemplo 2: necesita un nuevo t\u00e9rmino PDE o acoplamiento<\/h3>\n

                                      Desea agregar un t\u00e9rmino de electromigraci\u00f3n a un modelo de transporte existente. El c\u00f3digo actual funciona seg\u00fan lo dise\u00f1ado; Simplemente no incluye esa f\u00edsica. Esa es una solicitud de funci\u00f3n. Su ticket debe explicar la ecuaci\u00f3n de gobierno, las entradas esperadas y c\u00f3mo la validar\u00eda (referencias o l\u00edmites anal\u00edticos).<\/p>\n

                                      Ejemplo 3: \"Es demasiado lento\"<\/h3>\n

                                      El rendimiento puede ser cualquiera. Si el c\u00f3digo sol\u00eda ejecutarse en 5 minutos y ahora toma 50 minutos en la misma configuraci\u00f3n, eso es un error (una regresi\u00f3n de rendimiento). Si el c\u00f3digo siempre ha tomado 50 minutos y desea que tome 5, esa es una solicitud de funci\u00f3n (funcionamiento de optimizaci\u00f3n), a menos que la lentitud provenga de un comportamiento no deseado (como un solucionador atascado debido a un problema de convergencia).<\/p>\n

                                      Ejemplo 4: Mensaje de error confuso<\/h3>\n

                                      Un mensaje de error confuso suele ser una solicitud de funci\u00f3n (mejora UX), a menos que el mensaje sea incorrecto o enmascara el error real de una manera que impida el diagn\u00f3stico. En muchos equipos, \"mejorar mensaje de error\" se rastrea como una mejora, no como un error.<\/p>\n

                                      Clasificaciones err\u00f3neas comunes y c\u00f3mo solucionarlas<\/h2>\n

                                      Clasificaci\u00f3n err\u00f3nea: \"se bloquea\" (pero solo con entrada no v\u00e1lida)<\/h3>\n

                                      Si el software se bloquea cuando se le da una entrada no v\u00e1lida, podr\u00eda ser un error si el programa falla con gracia (error claro, no hay archivos da\u00f1ados). Si se espera bloquear porque la entrada est\u00e1 fuera de las restricciones admitidas y la herramienta ya lo documenta, podr\u00eda ser una solicitud de mejora para mejorar la validaci\u00f3n y los mensajes.<\/p>\n

                                      Clasificaci\u00f3n err\u00f3nea: \"El resultado se ve mal\" (pero las expectativas no est\u00e1n claras)<\/h3>\n

                                      Si el ticket no define lo que significa \"correcto\", los mantenedores no pueden decidir el error frente a la funci\u00f3n. En ese caso, escriba el boleto como una pregunta m\u00e1s una expectativa propuesta y adjunte pruebas. A menudo, el mejor primer paso es: \"aclarar el comportamiento esperado\", luego volver a presentarlo como error o caracter\u00edstica una vez confirmado.<\/p>\n

                                      Clasificaci\u00f3n err\u00f3nea: \"Por favor agregue la opci\u00f3n X\" (pero el c\u00f3digo ya lo admite)<\/h3>\n

                                      Esto no es una caracter\u00edstica ni un error en el comportamiento central; puede ser una brecha de documentaci\u00f3n. Si la capacidad existe pero es dif\u00edcil de descubrir, cree un ticket de documento (o una mejora centrada en la usabilidad).<\/p>\n

                                      C\u00f3mo escribir un informe de error de alta calidad<\/h2>\n

                                      Un buen informe de error facilita la reproducci\u00f3n, el diagn\u00f3stico y la verificaci\u00f3n de la soluci\u00f3n.<\/p>\n

                                      Plantilla de informe de error<\/h3>\n
                                        \n
                                      • Resumen: Una oraci\u00f3n que describe el comportamiento incorrecto<\/li>\n
                                      • Entorno: OS, versi\u00f3n de Python\/C++, versi\u00f3n de paquete\/commit, versiones de MPI\/Solver si es relevante<\/li>\n
                                      • Pasos para reproducir: pasos m\u00ednimos, archivos de entrada m\u00ednimos, fragmento de c\u00f3digo m\u00ednimo<\/li>\n
                                      • Resultado esperado: qu\u00e9 deber\u00eda suceder y por qu\u00e9 (docs\/pruebas\/comportamiento anterior)<\/li>\n
                                      • Resultado real: lo que sucede en su lugar (registros, seguimiento de pila, capturas de pantalla, diferencial de salida)<\/li>\n
                                      • Impacto: Gravedad (Crash, Ciencias Incorrectas, IU Menor), Frecuencia, Soluci\u00f3n Si la tiene<\/li>\n<\/ul>\n

                                        Ejemplo de informe de error (corto)<\/h3>\n

                                        Resumen: El ejemplo de difusi\u00f3n falla con Dirichlet BC en la cuadr\u00edcula 3D.<\/p>\n

                                          \n
                                        • Esperado: La simulaci\u00f3n se ejecuta y produce valores de campo estables como en 2D.<\/li>\n
                                        • Actual: Solver diverge despu\u00e9s de n pasos; Los valores se convierten en NaN.<\/li>\n
                                        • Evidencia: Proporcione un script m\u00ednimo, valores de par\u00e1metros y salida de registro.<\/li>\n<\/ul>\n

                                          C\u00f3mo escribir una solicitud de funci\u00f3n s\u00f3lida<\/h2>\n

                                          Una fuerte solicitud de funci\u00f3n se lee como un mini dise\u00f1o. Nota: explica por qu\u00e9 la capacidad es importante, c\u00f3mo se ve \"hecho\" y c\u00f3mo lo verificar\u00e1.<\/p>\n

                                          Plantilla de solicitud de funci\u00f3n<\/h3>\n
                                            \n
                                          • Declaraci\u00f3n del problema: lo que no puedes hacer hoy<\/li>\n
                                          • Caso de uso: qui\u00e9n lo necesita y por qu\u00e9 (flujo de trabajo de investigaci\u00f3n, m\u00f3dulo de ense\u00f1anza, canalizaci\u00f3n de producci\u00f3n)<\/li>\n
                                          • Soluci\u00f3n propuesta: comportamiento de alto nivel, cambios de interfaz de usuario\/API, valores predeterminados<\/li>\n
                                          • Criterios de aceptaci\u00f3n: lo que debe ser cierto para considerarlo completo<\/li>\n
                                          • Validaci\u00f3n: c\u00f3mo probar (benchmarks, tests unit, soluciones anal\u00edticas, suite de regresi\u00f3n)<\/li>\n
                                          • Alternativas consideradas: soluciones alternativas u otros enfoques<\/li>\n<\/ul>\n

                                            Ejemplo de solicitud de funci\u00f3n (corto)<\/h3>\n

                                            Solicitud: agregue una opci\u00f3n para exportar el estado de simulaci\u00f3n a un formato de visualizaci\u00f3n estandarizado a intervalos configurables.<\/p>\n

                                              \n
                                            • Caso de uso: grandes ejecuciones en HPC donde se necesita una visualizaci\u00f3n intermedia para el monitoreo.<\/li>\n
                                            • Aceptaci\u00f3n: Obras de exportaci\u00f3n para redes 2D\/3D; Incluye metadatos (paso de tiempo, unidades); Sin ralentizaci\u00f3n importante.<\/li>\n
                                            • Validaci\u00f3n: comparar campos exportados con matrices en memoria; Aseg\u00farese de que la recarga reproduce el estado dentro de la tolerancia.<\/li>\n<\/ul>\n

                                              Cuando un boleto debe convertirse en dos<\/h2>\n

                                              Muchos problemas del mundo real mezclan errores y caracter\u00edsticas. Dividirlos a menudo acelera el progreso.<\/p>\n

                                                \n
                                              • Si hay un accidente (error) y tambi\u00e9n un deseo de un mensaje m\u00e1s agradable (caracter\u00edstica), presente dos boletos.<\/li>\n
                                              • Si hay un problema de correcci\u00f3n (BUG) y tambi\u00e9n una solicitud para respaldar un nuevo r\u00e9gimen, separe el \"comportamiento actual\" de la \"capacidad de extensi\u00f3n\".<\/li>\n
                                              • Si la solicitud es \"hacerlo m\u00e1s r\u00e1pido\" pero sospecha una regresi\u00f3n, presente un error para la regresi\u00f3n y una funci\u00f3n para una mayor optimizaci\u00f3n.<\/li>\n<\/ul>\n

                                                Dividir boletos permite a los equipos cerrar el error r\u00e1pidamente y programar la mejora con sensatez.<\/p>\n

                                                Consejos de triaje para mantenedores y clientes potenciales<\/h2>\n

                                                Use etiquetas y un comentario de decisi\u00f3n corta<\/h3>\n

                                                Cuando un ticket llegue ambiguo, agregue un breve comentario que bloquee la clasificaci\u00f3n:<\/p>\n

                                                  \n
                                                • \u201cClasificando como error porque el comportamiento contradice la secci\u00f3n de documentaci\u00f3n X\u201d.<\/li>\n
                                                • \"Clasificaci\u00f3n como solicitud de funci\u00f3n porque esto agrega una nueva capacidad de solucionador que no es compatible actualmente\".<\/li>\n<\/ul>\n

                                                  Requieren criterios m\u00ednimos de aceptaci\u00f3n para las caracter\u00edsticas<\/h3>\n

                                                  Las solicitudes de funci\u00f3n fallan cuando \"hecho\" no est\u00e1 claro. Pregunte por los criterios de aceptaci\u00f3n temprano: qu\u00e9 salida, qu\u00e9 interfaz, qu\u00e9 pruebas, qu\u00e9 ejemplo. Una caracter\u00edstica sin criterios de aceptaci\u00f3n es efectivamente un elemento de la lista de deseos.<\/p>\n

                                                  Convierta las preguntas recurrentes en tareas de documentaci\u00f3n<\/h3>\n

                                                  Si m\u00faltiples \"solicitudes de funciones\" son en realidad solicitudes de orientaci\u00f3n (\"\u00bfC\u00f3mo hago yo...?\"), Capture las como mejoras en los documentos. Esto es especialmente com\u00fan en las bibliotecas cient\u00edficas donde existen capacidades pero no son obvias.<\/p>\n

                                                  Plantillas pr\u00e1cticas que puedes copiar en tickets<\/h2>\n

                                                  Clasificador de una sola l\u00ednea<\/h3>\n

                                                  Use esto como la primera l\u00ednea de su descripci\u00f3n de su boleto:<\/p>\n

                                                    \n
                                                  • ERROR: \u201cEl comportamiento observado contradice el comportamiento esperado definido por [docs\/test\/previous version]\u201d.<\/li>\n
                                                  • Caracter\u00edstica: \"Nueva capacidad necesaria para admitir [use case], no disponible actualmente\".<\/li>\n<\/ul>\n

                                                    Criterios de aceptaci\u00f3n Set de inicio para funciones<\/h3>\n
                                                      \n
                                                    • API: nueva opci\u00f3n\/par\u00e1metro documentado con valores predeterminados<\/li>\n
                                                    • Ejemplo: Ejemplo de trabajo m\u00ednimo incluido en documentos\/ejemplos<\/li>\n
                                                    • Pruebas: al menos una prueba automatizada cubre el comportamiento principal<\/li>\n
                                                    • Compatibilidad con versiones anteriores: los scripts existentes contin\u00faan ejecut\u00e1ndose sin cambios (o pasos de migraci\u00f3n documentados)<\/li>\n<\/ul>\n

                                                      Conclusi\u00f3n<\/h2>\n

                                                      Los informes de errores restauran la confianza; Las solicitudes de funciones expanden la capacidad. Ambos son esenciales en el software cient\u00edfico, pero solo tienen \u00e9xito cuando est\u00e1n escritos con la intenci\u00f3n y la evidencia correctas. Si vincula los errores a un punto de referencia y vincula las caracter\u00edsticas a un caso de uso claro con criterios de aceptaci\u00f3n, reducir\u00e1 la fricci\u00f3n de clasificaci\u00f3n, acelerar\u00e1 el desarrollo y har\u00e1 que las versiones sean m\u00e1s predecibles, lo que en \u00faltima instancia mejora la velocidad de investigaci\u00f3n y la fiabilidad de los resultados.<\/p>\n"},"excerpt":{"rendered":"

                                                      Reading Time: <\/span> 7<\/span> minutes<\/span><\/span>En el software cient\u00edfico y de ingenier\u00eda, la mayor parte de la frustraci\u00f3n no proviene de problemas dif\u00edciles: proviene de declaraciones de problemas poco claras. Un ticket que \u00absuena mal\u00bb en realidad podr\u00eda describir una capacidad faltante. Una solicitud de una \u00abpeque\u00f1a mejora\u00bb podr\u00eda estar enmascarando un defecto que da\u00f1a los resultados. Cuando los equipos […]<\/p>\n","protected":false,"raw":""},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"es_ES","_original_post":"https:\/\/new.matforge.org\/?p=50","iawp_total_views":0,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-640","post","type-post","status-publish","format-standard","hentry","category-issue-tracking-tickets-technical-requests","es-ES"],"yoast_head":"\nSolicitudes de funciones frente a informes de errores: conocer la diferencia (con ejemplos)<\/title>\n<meta name=\"description\" content=\"Aprenda c\u00f3mo indicar las solicitudes de funciones de los informes de errores, escribir mejores tickets y acelerar el triaje con ejemplos pr\u00e1cticos, una tabla de comparaci\u00f3n y plantillas.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/\" \/>\n<meta property=\"og:locale\" content=\"es_ES\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Solicitudes de funciones frente a informes de errores: conocer la diferencia (con ejemplos)\" \/>\n<meta property=\"og:description\" content=\"Aprenda c\u00f3mo indicar las solicitudes de funciones de los informes de errores, escribir mejores tickets y acelerar el triaje con ejemplos pr\u00e1cticos, una tabla de comparaci\u00f3n y plantillas.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/\" \/>\n<meta property=\"og:site_name\" content=\"matforge.org\" \/>\n<meta property=\"article:published_time\" content=\"2026-07-22T08:16:48+00:00\" \/>\n<meta name=\"author\" content=\"Priya Nair\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Escrito por\" \/>\n\t<meta name=\"twitter:data1\" content=\"Priya Nair\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tiempo de lectura\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\"},\"author\":{\"name\":\"Priya Nair\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"headline\":\"Solicitudes de funciones frente a informes de errores: conocer la diferencia\",\"datePublished\":\"2026-07-22T08:16:48+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\"},\"wordCount\":2142,\"commentCount\":0,\"articleSection\":[\"Seguimiento de problemas, tickets & Solicitudes T\u00e9cnicas\"],\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\",\"url\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\",\"name\":\"Solicitudes de funciones frente a informes de errores: conocer la diferencia (con ejemplos)\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\"},\"datePublished\":\"2026-07-22T08:16:48+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"description\":\"Aprenda c\u00f3mo indicar las solicitudes de funciones de los informes de errores, escribir mejores tickets y acelerar el triaje con ejemplos pr\u00e1cticos, una tabla de comparaci\u00f3n y plantillas.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#breadcrumb\"},\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/matforge.org\\\/es\\\/feature-requests-vs-bug-reports-knowing-the-difference\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/matforge.org\\\/es\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Solicitudes de funciones frente a informes de errores: conocer la diferencia\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\",\"url\":\"https:\\\/\\\/matforge.org\\\/\",\"name\":\"matforge.org\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/matforge.org\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"es\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\",\"name\":\"Priya Nair\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"caption\":\"Priya Nair\"},\"sameAs\":[\"http:\\\/\\\/matforge.org\"],\"url\":\"https:\\\/\\\/matforge.org\\\/author\\\/priya-nair\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Solicitudes de funciones frente a informes de errores: conocer la diferencia (con ejemplos)","description":"Aprenda c\u00f3mo indicar las solicitudes de funciones de los informes de errores, escribir mejores tickets y acelerar el triaje con ejemplos pr\u00e1cticos, una tabla de comparaci\u00f3n y plantillas.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/","og_locale":"es_ES","og_type":"article","og_title":"Solicitudes de funciones frente a informes de errores: conocer la diferencia (con ejemplos)","og_description":"Aprenda c\u00f3mo indicar las solicitudes de funciones de los informes de errores, escribir mejores tickets y acelerar el triaje con ejemplos pr\u00e1cticos, una tabla de comparaci\u00f3n y plantillas.","og_url":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/","og_site_name":"matforge.org","article_published_time":"2026-07-22T08:16:48+00:00","author":"Priya Nair","twitter_card":"summary_large_image","twitter_misc":{"Escrito por":"Priya Nair","Tiempo de lectura":"11 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/#article","isPartOf":{"@id":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/"},"author":{"name":"Priya Nair","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"headline":"Solicitudes de funciones frente a informes de errores: conocer la diferencia","datePublished":"2026-07-22T08:16:48+00:00","mainEntityOfPage":{"@id":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/"},"wordCount":2142,"commentCount":0,"articleSection":["Seguimiento de problemas, tickets & Solicitudes T\u00e9cnicas"],"inLanguage":"es","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/","url":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/","name":"Solicitudes de funciones frente a informes de errores: conocer la diferencia (con ejemplos)","isPartOf":{"@id":"https:\/\/matforge.org\/#website"},"datePublished":"2026-07-22T08:16:48+00:00","author":{"@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"description":"Aprenda c\u00f3mo indicar las solicitudes de funciones de los informes de errores, escribir mejores tickets y acelerar el triaje con ejemplos pr\u00e1cticos, una tabla de comparaci\u00f3n y plantillas.","breadcrumb":{"@id":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/matforge.org\/es\/feature-requests-vs-bug-reports-knowing-the-difference\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/matforge.org\/es\/"},{"@type":"ListItem","position":2,"name":"Solicitudes de funciones frente a informes de errores: conocer la diferencia"}]},{"@type":"WebSite","@id":"https:\/\/matforge.org\/#website","url":"https:\/\/matforge.org\/","name":"matforge.org","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/matforge.org\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Person","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795","name":"Priya Nair","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","caption":"Priya Nair"},"sameAs":["http:\/\/matforge.org"],"url":"https:\/\/matforge.org\/author\/priya-nair\/"}]}},"_links":{"self":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/640","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/comments?post=640"}],"version-history":[{"count":1,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/640\/revisions"}],"predecessor-version":[{"id":649,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/640\/revisions\/649"}],"wp:attachment":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/media?parent=640"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/categories?post=640"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/tags?post=640"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}