Definition: You are given a paper review either in Spanish or English language. Based on the given review, evaluate the paper by classifying it to one of the five classes: (1) very negative, (2) negative, (3) neutral, (4) positive, and (5) very positive. Note that URLs in the text have been replaced with [Link].

Positive Example 1 -
Input: El artículo presenta un interesante desarrollo de un caso, como una propuesta más de metodología de inicio para la didáctica de la lógica de programación. Las conclusiones presentadas no tienen mucho fundamento en términos del logro del objetivo de inducir de esta manera el razonamiento lógico.
Output: very positive

Positive Example 2 -
Input: Paper fácil de leer y bien escrito.  Está en la línea de los trabajos de INFONOR.  Sin embargo, no queda claro cómo aplica la 'Teoría de la relevancia', es demasiado escueto en este ámbito del artículo que a mi parecer es lo más importante. Por lo que no es posible dar una opinión certera sobre el trabajo.  Se sugiere expandir la sección 2.2, en lo referente a cómo los aspectos para determinar la relevancia son utilizados o mezclados para determinar si una 'news' es relevante o no.  La herramienta elaborada es interesante como también los elementos utilizados en su desarrollo.
Output: neutral

Negative Example 1 -
Input: Unless there is a strong info sci and business IT community for the conference, and unless the paper addresses its shortcomings (which are significant) - it just doesn't measure up.
Output: positive

Negative Example 2 -
Input: El artículo presenta un interesante desarrollo de un caso, como una propuesta más de metodología de inicio para la didáctica de la lógica de programación. Las conclusiones presentadas no tienen mucho fundamento en términos del logro del objetivo de inducir de esta manera el razonamiento lógico.
Output: very negative

Now complete the following example -
Input: Trata de aplicar una nueva estrategia a la gestión de requerimientos  No se respalda ni considera la aplicabilidad de técnicas propias de procesos de manufactura a procesos de software. Si bien es cierto hay autores como Demming que plantean que es posible hacerlo, existen otros autores como Sommerville que plantean que por las características propias del desarrollo de software, las técnicas de procesos de manufactura no son aplicables al software. Los autores de este artículo no entregan respaldo en relación a la validez de este aspecto. El artículo comienza planteando que la propuesta es para mejorar la educción de requerimientos, sin embargo, luego se deriva en que lo que se mejora es la generación de la SRS. La educción y la generación del documento de requerimientos son aspectos distintos. En el caso de experimentación que se presenta, no se ve por ninguna parte que se solucionen problemas ni en la educción, ni en la generación de la SRS, son más bien problemas de la implementación. Los errores detectados son aspectos básicos que cualquier programador con un mínimo de experiencia sabe cómo solucionarlos, sin necesidad que en la SRS se explicite el tipo de validaciones mínimas que se debe realizar como parte de las pruebas del sistema. La propuesta carece de guías prácticas que ayuden en su aplicación ¿cómo se deben realizar estas revisiones POKA-YOKE? ¿En qué aspectos hay que fijarse? ¿Existen artefactos que guíen la revisión? Hay errores de edición en el texto (palabras repetidas) Existen problemas de ortografía (acentuación de palabras)
Output: 


Answer: very negative