[17.0][IMP+FIX+I18N] l10n_es_vat_prorate: Feedback from v16 backport #4288
Conversation
- account.move~with_special_vat_prorate can't depend on company prorate modifications, or this will trigger the line check computation, marking/unmarking all the existing invoices. - Remove double assignation vat_prorate = False. - Terms homogenized. - Make prorate tree editable again. - Better text for invoice line column. - Translations.
pedrobaeza
force-pushed
the
17.0-imp-l10n_es_aeat_vat_prorrate-special
branch
from
32a46f6 to
90645e5
Compare
|
/ocabot merge patch |
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at bb77097. Thanks a lot for contributing to OCA. ❤️ |
|
¿Se mezcla esto sin que nadie lo revise? @OCA/local-spain-maintainers ? Por favor revisa @EmilioPascual :-) muchas gracias 😃 Ruego que se cumplan los mismos criterios de revisión para todos los PRs. Y no haya agrarios comparativos. Gracias |
|
Está ya revisado en #4287, y obviamente por el alcance de los cambios y mi potestad como PSC representative de OCA/l10n-spain, puedo hacerlo con las reglas en la mano. El agravio comparativo sería que sin importar el número de contribuciones hechas y del esfuerzo por sincronizar todas las ramas adecuadamente, se bloqueen cosas. |
|
@rafaelbn que los 3 mayores contribuidores (además de compañías distintas) del repositorio desde 2024 lo hubieramos hablado en el PR original, dos aprobando y uno haciendo el código y en el propio PR original se le pedía el forward port no te parecen suficientes buenas prácticas? No sé, parece que no se valora suficiente el trabajo transversal que es hacer backports y forwardports, pero es una parte crítica de la comunidad. Personalmente, estoy harto de ver mejoras en módulos que se quedan en una branch y no se portan (tanto en este repo como en otros). Si quieres nos dedicamos a buscar ejemplos... Lo mismo que los PRs endogámicos, en los que tienes 5 reviews pero todos son de la misma empresa. Al final, la parte comunitaria implica reviews externos, no de tus compañeros, ya que eso da riqueza y feedback completamente externo, en mi opinión, lo contrario es engañarse a si mismo y a los clientes.... Sé que cuesta conseguir reviews externos, pero aquí entra el tema de hacer reviews externos para que te los hagan a ti... Y ojo que no es una crítica a nada y a nadie, simplemente mostrar que no entiendo la queja cuando ha sido un caso perfecto de colaboración. |
|
Gracias por vuestras respuestas. Este caso ha sido un ejemplo de colaboración ágil y bien llevada, y lo celebramos. Precisamente por eso, y con espíritu constructivo, creemos que vale la pena abrir una reflexión más amplia sobre la dinámica de revisiones en la localización española de Odoo. En paralelo a este PR (mismo módulo), hay otras contribuciones validadas, revisadas y funcionando en producción desde hace meses que siguen bloqueadas: Algunas incluso cuentan con aprobación de PSC, pero no terminan de avanzar. Este contraste —un PR mergeado en menos de una hora frente a otros parados durante meses— genera desánimo en quienes quieren aportar desde fuera del núcleo habitual. Y lo que más preocupa no es el ritmo, sino el criterio: ¿Está la comunidad valorando el contenido o el remitente del PR? Desde Moduon contribuimos activamente al ecosistema Odoo y OCA, y revisamos aportes independientemente de la empresa que los envíe. Porque así entendemos el software libre: abierto, plural y con foco en el impacto. Nos preocupa que la comunidad se vuelva endogámica, donde la colaboración real solo fluye si viene "de los de siempre". Y esto no es una crítica personal, sino una llamada a cuidar lo que hace grande al Open Source: la diversidad técnica y la justicia procesal. Si esta reflexión sirve para desbloquear alguna de esas contribuciones —y para que más personas sientan que pueden participar de verdad—, ya habrá merecido la pena. Un saludo a todos los que empujan con honestidad. |
|
@rafaelbn voy a dedicarte 2 minutos para responderte.... de los 3 PRs que hablas, 2 tienen changes requested no resueltos y en uno yo no lo aprobé por que me gustaria revisiones externas y, además, no lo bloqueé. No entiendo tanta queja. La mayoria de susodichas reviews son internas, personalmente, son importantes, pero premian las externas, y sin externas, yo no mergearía módulos que no mantenéis (ni aquí ni en otros repositorios). Fijate que yo podría mergear muchas cosas y no lo hago por respeto, aunque me moleste dejar PRs abiertos por todos lados. Antes de levantar la voz y llamar a una mejora de la colaboración, os recomendaria que os miraseis a vosotros mismos y evaluaseis si yo puedo cambiar algo para conseguir el cambio. El cambio del que tanto habláis no es de la comunidad, es de todos los que estamos dentro (incluidos vosotros). Mirando datos del 2024, veo que hacéis muchas reviews, pero son mayoritariamente de vuestros propios PRs. Yo os recomendaría cambiar eso y a partir de allí ver si la forma de hacer cambia. Y para acabar, ¿los PSCs se revisan el origen del PR? Si, generalmente si, por que depende de quien esté delante aceptará de mejor o de peor grado las reviews, los comentarios o incluso el bloqueo de un PR. Además, hay muchas personas que no aceptan hacer los forwardports con excusas como "El cliente no lo paga". Lo entendemos, pero es una comunidad y ser parte de una implica aceptar como es y jugar según sus propias normas. Cuando eres PSC, tienes una gran responsabilidad, no es solo mergear PRs o mis PRs solamente, que eso lo hemos visto en otros repositorios, en los que "grandes" colaboradores son PSCs para mergear sólamente lo suyo y saltandose por la torera todas las reglas que hay. En cualquier caso, esto es un cuento para otro momento. Espero que mi reflexión ayude para intentar comprender los PSCs, su importancia y que antes de empezar a pedir cambios, miremos que podemos cambiar nosotros para mejorarlo. |
|
Gracias Enric por sacar ese tiempo —dos minutos bien aprovechados, como dirías tú 😉— para compartir tu reflexión. No buscamos tener razón. Buscamos mejorar entre todos algo en lo que creemos. Lo que nos mueve no es una queja puntual, sino una percepción repetida: a veces cuesta entender por qué algunos PRs avanzan rápido y otros se quedan meses sin respuesta, pese a estar validados y en uso real. Esa falta de claridad, más que el fondo técnico, es lo que desanima. En este caso, tres contribuidores distintos, todos ellos entre los más activos del repositorio desde 2024, han colaborado en un PR que se ha mergeado en menos de una hora. Fantástico. Pero justo por eso, llama la atención que otros PRs —también con alta participación, funcionales en producción desde hace meses, validados por PSCs e incluso con cambios solicitados resueltos— sigan bloqueados. Esta disparidad no la mencionamos por crítica personal, sino porque refleja una necesidad sistémica de consistencia. Si el criterio para mergear no es técnico sino relacional —como tú mismo sugieres al decir que "los PSCs revisan quién está delante"—, entonces conviene abrir el debate, dado que esto es subjetivo y no técnico. Porque una comunidad de código abierto se basa en pluralidad, mérito, revisión imparcial y sostenibilidad del conocimiento compartido. No lo decimos nosotros: lo dice DHH, creador de Ruby on Rails, cuando explica que una comunidad sana se construye sobre reglas previsibles, feedback respetuoso y estándares que se aplican igual para todos, sean conocidos o no. Gracias de nuevo por la respuesta. Seguimos construyendo. |
|
@rafaelbn Si no te importa, seré sincero y directo, para evitar ambiguedades, por que no quiero dejar esto corriendo y generando debate que, en mi opinión, no tiene ningún sentido. Me gustaría cerrarlo de forma clara. Primero, ¿puedes no comparar ambos casos? En los PRs que has pasado hay ejemplos como: Bloqueos puestos por que es mal uso de la herramienta, muchas reviews, pero todas de Moduon sobre un módulo hecho por moduon... Así que no sé, no veo muy claro el por que de la parrafada intentando convencer de lo otro... parece demagogia para convencernos que lo hacéis muy bien y el resto somos los malos por (según vuestro parecer) ignoraros. Por desgracia esto es una comunidad y todos tenemos bastante curro. Además, como bien señalas, hay una parte muy importante de mérito en las comunidades OSS. El mérito se consigue haciendo código y revisiones de calidad en todo la comunidad. Como ya te he comentado antes, creo que eso os falta, por que, desde mi punto de vista, las reviews internas están muy bien y en ocasiones están bien definidas, pero en general se usan para rellenar y obtener los approvals necesarios. Cuando un equipo optar por no revisar el resto, lo normal es que los PSCs opten por no darle prioridad, principalmente por que no devuelven el esfuerzo realizado. Recordemos que los PSCs y mantenedores no cobran de nadie por hacer ese trabajo hacia la comunidad, así que no vengamos con temas de es su obligación... También están en su derecho de enviarnos a la mierda si deben perder demasiado tiempo en hacer ese trabajo no remunerado o ven que el coste supera de largo el beneficio. Hagámoslo sencillo para ellos y demostremos que el beneficio está muy por encima del coste. Por último, si, yo también estoy cansado de muchas cosas de la comunidad. Sobretodo de comentarios al estilo:
Y ojo, que yo tampoco soy un santo y a veces se me ha ido la mano en algunos momentos y por ello he tenido que pedir disculpas (OCA/account-reconcile#658 (comment)). A lo dicho, antes de empezar a quejarse o dar lecciones, revisa internamente que hacéis para mejorar la comunidad. |
|
Gracias, Enric, por tomarte el tiempo de compartir tu opinión con tanta franqueza. No vamos a entrar en valoraciones personales ni en comparaciones. No creemos que eso ayude a construir comunidad. Solo una idea final, que quizá compartimos: si todos estamos cansados de ciertas dinámicas, lo importante no es señalar culpables, sino abrir espacio para mejorar. Y si esa mejora se da —más allá de nombres, empresas o prioridades— estaremos ahí para contribuir con código, con ideas y con respeto. Seguimos construyendo. |
|
Rafa, ¿y cuál es tu propuesta de mejora concreta que no implique que los demás hagamos trabajo para ti de gratis y encima sin reprocidad? Creo que uno de los enlaces compartidos por Enric es de especial relevancia, ya que refleja el espíritu de vuestro equipo, que es "solo soy comunitario si me interesa": OCA/multi-company#760 (comment) Son por actitudes como ésta por lo que los que hacemos trabajo de PSC tenemos nuestras prioridades sobre qué PRs atender. Cuando nos quitéis ese sentimiento de falta de reprocidad con vuestras acciones, entonces volvemos a hablar. Y creo que aún así, no os podéis quejar de falta de reviews por parte de otros revisores que no son de vuestra empresa (otra cosa es que se fusione o no si hay discrepancias precisamente en la review). ¿Quieres que saquemos estadísticas de los que os hemos revisado Enric o yo frente a los que habéis revisado vosotros nuestros? Seguimos contribuyendo. |
|
Gracias, Pedro y Enric, por compartir también este cierre. No queremos alargar más la conversación, pero sí dejar constancia de una reflexión serena. La OCA es una comunidad basada en la meritocracia, y valoramos profundamente el esfuerzo de quienes más contribuyen. También nosotros somos humildes contribuidores —como tantos otros— que intentamos sumar desde el respeto y la colaboración. Precisamente por eso, creemos que el mérito no debería vivirse como un derecho a imponer opinión, sino como una responsabilidad que se ejerce con equidad. Una comunidad sana no se mide solo por cuánto código generan unos pocos, sino por cuánta diversidad es capaz de sostener, revisar y cuidar entre todos. Y esa diversidad se construye —también— desde la igualdad de trato, la revisión imparcial, el respeto mutuo… y el cumplimiento del código de conducta de la OCA. No nos corresponde juzgar si en esta conversación se han cumplido siempre esos principios. Pero sí queremos expresar, con honestidad, que algunas formas pueden desincentivar la participación, y eso afecta al conjunto de la comunidad. Porque construir comunidad no es lo mismo que contribuir a ella. Lo primero implica dar forma al clima, a las reglas y a los espacios de diálogo. Y eso, entre todos, también se cuida. Si esta conversación sirve para que más personas puedan contribuir sin miedo a bloqueos subjetivos o valoraciones desiguales, habrá merecido la pena. Seguimos construyendo. Con principios, con equipo y con mirada larga. Rafa Nota: ¿Qué hacen unos contribuidores cuando sus contribuciones no avanzan por una opinión? ¿Qué se debe hacer? Aceptamos de agrado todas las recomendaciones. @OCA/local-spain-maintainers |
|
Gracias por dar tu opinión. Creo que hemos dado algunas respuestas a tus preguntas. Al final esto es un quid pro quo, para recibir hay que dar. Piensa que incluso entre los mayores contribuidores hay diferencias de opinión, aun así lo importante es llegar a un puntonde consenso. En cualquier caso, creo que es momento de cerrar este thread ya Seguimos construyendo. |
@Tecnativa