Message Threads | The Odoo Community Association

Re: Guidelines for LLM generated contributions

Hi Stefan,

first thanks to bring that forward. As already told you bilaterally, I fully support your thoughts. I think setting and enforcing governance for interacting with AI helps to keep a open-minded, mutual and even improved work mode within the community. That said: Keeping other volunteers busy with unreviewed and unchallenged AI results and / or not respecting basic governance rules of using AI is not acceptable

Best Frederik

Am 18. September 2025 09:41:43 MESZ schrieb Stefan Rijnhart <notifications@odoo-community.org>:

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan


-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

by Frederik Kramer - 10:02 - 18 Sep 2025

Re: Guidelines for LLM generated contributions

+1

Sergio Corato

Il giorno gio 18 set 2025 alle ore 09:47 Stéphane Bidoul <notifications@odoo-community.org> ha scritto:

+100

On Thu, Sep 18, 2025 at 9:41 AM Stefan Rijnhart <notifications@odoo-community.org> wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan




-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Sergio Corato - 09:56 - 18 Sep 2025

Re: Guidelines for LLM generated contributions

+1000

Our contributors time is precious and we have to preserve it in this new LLM hype contexte.

Virginie Dewulf

Executive Director

Odoo Community Association (OCA)

+32 477 64 17 20

Le jeu. 18 sept. 2025, 09:47, Stéphane Bidoul <notifications@odoo-community.org> a écrit :

+100

On Thu, Sep 18, 2025 at 9:41 AM Stefan Rijnhart <notifications@odoo-community.org> wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan




-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Virginie Dewulf - 09:51 - 18 Sep 2025

Re: Guidelines for LLM generated contributions

+1

Can we at least use LLM to review such PR ? 😅

Le jeu. 18 sept. 2025 à 09:47, Stéphane Bidoul <notifications@odoo-community.org> a écrit :

+100

On Thu, Sep 18, 2025 at 9:41 AM Stefan Rijnhart <notifications@odoo-community.org> wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan




-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Houssine BAKKALI - 09:51 - 18 Sep 2025

Slides for OpenUpgrader module for Odoo at OCA Days 2025

Hi all,

as Alexandre did, I share the slides from the talk about an OpenUpgrade automatization tool I did: https://docs.google.com/presentation/d/1671gOwuPqaJD9mfsYzxcp0YgyEf8SUaRwrzSUhGdZvw/edit?usp=sharing

Maybe there is a place to put them in the OCA Website to simplify finding them in the future?

Sergio Corato

by Sergio Corato - 09:51 - 18 Sep 2025

Re: Guidelines for LLM generated contributions

+100

On Thu, Sep 18, 2025 at 9:41 AM Stefan Rijnhart <notifications@odoo-community.org> wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan



-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Stéphane Bidoul - 09:46 - 18 Sep 2025

Guidelines for LLM generated contributions

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan


-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

by Stefan Rijnhart - 09:40 - 18 Sep 2025

Re: OCA/bank-payment-alternative

Dear all,

During OCA days - on behalf of the board - I've taken the chance to find a common ground in this story and - hopefully - bring some clarity on where we are and what we'll do next with this alternative repo.

Both Alexis and Pedro agreed on the following points:

0. There's nothing personal, we are still friends in the community and we are all here because we want to see the community thrive.

1. Both parties, in various ways, failed to maintain the discussion on the right path to keep it productive, polite and neutral (one side being harsh, one side not "listening").

2. Every derivative work based on the alternative should stay in the alternative repo and have a proper name. For instance, an existing module is refactored on top of the alternative; it should be renamed and moved to this repo, while still keeping the original.

3. The alternative repo must have a readme that states clearly where it comes from and where it should go. For instance, it must be clear that:

- it's a fork of v16 and does not contain many improvements from v16 (past or future) nor from v17 or v18

- it should mention pt 2 above regarding derivative work

- it should provide a disclaimer about the future, which is uncertain since quite likely the payment line field is going to be removed in v20

I hope I didn't forget anything :)

Thank you Pedro and Alexis for your time and for your collaborative approach!

Bests

On Mon, Jun 30, 2025 at 8:57 AM Sergio Corato <notifications@odoo-community.org> wrote:

Hi all,

I read various emails on this argument (I'm not sure I haven't missed some, so maybe I'm writing an unuseful email) and I'm sad about the way it is going. In Italy we had a similar event in the past, where the decision to fork was made by some people and was a bad moment, however this event made the community stronger.

The usual 'open source way' as I know is that the decision has to be taken in a democratic poll from the responsible people, in this case the PSC, nothing to do with the OCA Board.

The PSC is this one: https://github.com/orgs/OCA/teams/banking-maintainers and has 13 people, my solution should be to take a survey and to do whatever the result is. The people who are not interested to vote are maybe no more interested to be in the PSC too.

Is this option unpracticable?

Sergio Corato

Il giorno sab 28 giu 2025 alle ore 17:42 Juan José 'Peco' San Martín <notifications@odoo-community.org> ha scritto:
Good weekend everyone.

There should be no debate: the PSC must have the final word and full responsibility over the project’s technical direction.
The Board’s role should focus on governance, overseeing overall strategy, and providing support, but not on making technical decisions.

It’s not the right approach to bypass the PSC. They should reconsider and perhaps run for PSC next time.

Anyway, hopefully, we can lower the tone of the discussion and find something positive in all of this.

Regards,
JJ

On Sat, Jun 28, 2025 at 1:51 PM Mignon, Laurent <notifications@odoo-community.org> wrote:
Dear OCA community friends,

I am writing this message because what brings us together is now being tested by tensions that, if we are not careful, could divide us much more than just a technical discussion.

Together, we have built a strong community known and respected for its core values: openness, quality, transparency, and respect for everyone’s work. None of us, alone or as a company, can say we are the OCA by ourselves. Our strength is our diversity.

We are here today because of the many hours everyone has given: writing code, reviewing, documenting, discussing, helping each other, and defending the spirit of open source. We must remember that even when we do not agree, we are all here because we believe that together we can do more than alone.

I am sure that no one here wants to hurt others or create conflict. We all want to move forward and find better solutions. But because we care so much and put so much passion and time into our work, it is normal that sometimes we feel hurt or misunderstood.

The fork that is creating tensions now is not just a technical choice, it shows how we deal with disagreements and experiments in a living community. Sometimes they question how we do things or make us uncomfortable.

Nobody wins if we turn a disagreement into a fight or blame each other. And nobody wants to break the important role of the PSC nor the OCA Board, just as we should not close the door to new ideas. IMO, we need both: clear and respected governance, and the freedom to try new things.

If we want to move forward together, we maybe need clear and shared rules:

What limits do we want for internal forks (or how can we share experiments under the OCA umbrella)?

How do we make sure experiments do not break our common base?

How can everyone share their opinion without ignoring the roles we have decided together?

???

I think we should stop the public tension and speak openly together. It could be a very interesting and constructive debate. Why not organize a clear and respectful meeting at the OCA days on this topic?

We owe it to everyone who built this community, and to those who will join tomorrow, to keep trust and respect strong.

We do not have to agree on everything, but we must stay united. And more than anything, we should never forget what each person brings. Without your time, generosity and passion, the OCA would not exist.

Thank you all for what you have already done ... and for what we will build next, together.
Respect, diversity and unity fuel innovation! That also keeps our community strong.

Kind regards,

Laurent

On Sat, Jun 28, 2025 at 10:07 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
My apologies, I got some details wrong although I still stand by the general message. Certainly was not my intention, but again my apologies. Believe me when I say I do have sympathy for the difficulties here.

tbh I did get sent 2 messages I saw in my notifications on my phone (thanks for the 2am wakups btw), but by the time I got to them they were gone and I have no idea via which platforms they were sent or what they were. I only saw first names and first line but presume it was board members.

On Thu, Jun 26, 2025 at 11:26 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.

Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.

I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.

Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:

Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.

Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.

Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.

In face of the above, and on some comments on the email thread, I need to set the record straight:

Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.

It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.

The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.

Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.

Thank you Daniel

On 25/06/2025 08:58, Jorge Elena Poblet wrote:

Dear all,

I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.

While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.

We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.

If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.

This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.

We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.

Best regards,

On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.

Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.

The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.

It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.

Best wishes,

Stuart.

On 24/06/2025 23:12, Graeme Gellatly wrote:

This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.

Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.

In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.

On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:

There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.

I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.

Regards.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406

Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria

Start for free: Try Odoo Community in the cloud

This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER
>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Simone Orsi

Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.

by Simone Orsi - 07:46 - 17 Sep 2025

Re: Slides for Making Odoo Faster talk at OCA Days 2025

Thanks Alexandre,

very good and insightful talk from you. I enjoyed it very much. I will also directly share it with my team.

Best Frederik

Am 17. September 2025 10:26:46 MESZ schrieb Alexandre Fayolle <notifications@odoo-community.org>:

Hello,

For those interested, the slides for the talk Making Odoo Faster
Analyzing Odoo’s Speed that I gave yesterday are available here:

https://docs.google.com/presentation/d/1HpEGgmxxSUvAhF5r1XWO-1OqiQWPPJF4jPZ-XRg-e4k/edit?slide=id.g29db379d51f_0_3#slide=id.g29db379d51f_0_3

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

by Frederik Kramer - 04:55 - 17 Sep 2025

Re: The Consultant Working Group is looking for you!

Hello Michel,

As discussed in person, the criterias are guides to ensure that people in the WG have enough experience in the OCA processes, tools and modules to help other people. This experience needed is a functional one not a technical one.

I hope you understand better now.

See you!

Le lun. 15 sept. 2025 à 18:30, <mstroom@office-everywhere.com> a écrit :

Dear Julie,

I'm not sure why 3 years of experience is required for non-technical volunteer work in the 'Consultant / Functional Workgroup.' In my opinion, it's actually better for consultants not to have technical knowledge, and those with IT expertise can join other workgroups.

What seems more important is finding people who are enthusiastic, willing to consistently contribute their free time, and committed to staying involved, even without compensation.

Wishing you and the other Consultant / Functional Workgroup members the best in finding the right contributors. I also hope you’ll all consider dropping the 3-year Odoo experience requirement in favor of prioritizing commitment.

Looking forward to seeing all OCA members at OCA Days 2025 in Liège.
Let's have a drink next week, Julie. I’m also curious to hear why the workgroup is asking for 3 years of experience.

Best, Michel.

Office Everywhere
Business Partner Odoo

t: +31 6 53360677
e: mstroom@office-everywhere.com
w: Office-Everywhere.com

On 2025-09-13 10:21, Julie LeBrun (OCA) wrote:

Dear members,
Did you know we have a working group for consultant / functional people?

We are looking for new members in this group so if you are interested, please contact me (Julie) at julie@odoo-community.org.

The "Raison d'être" of the group is to help and attract functional people (non-technical) to contribute to the OCA.

Here are the requirements to be part of this group:
- More than 3 years of experience with OCA tools (GitHub, Weblate...) and modules
- More than 3 years of experience as a Consultant on Odoo
- More than 3 years of experience with Odoo
- Availability (1 wg meeting a month + 4h /month to contribute)
- Approval from the majority of the actual members of the WG

We will meet at the OCA Days on Monday morning so if you are interested, come and meet us (and contact me to let me know).

P.S. In October, we will start a series of Support group meeting for functional / consultant so even if you don't meet the requirements to be part of the group, you can still attend these meetings.

More info here : https://odoo-community.org/event/oca-consultants-support-group-session-2025-10-07-206/register

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Julie LeBrun

Content Creator & Training Manager

Odoo Community Association (OCA)

GitHub : https://github.com/TumbaoJu

by Julie LeBrun (OCA) - 02:56 - 17 Sep 2025

Re: Slides for Making Odoo Faster talk at OCA Days 2025

Thank you !!

--

Yves Goldberg

--

----- Original message -----

From: Alexandre Fayolle <notifications@odoo-community.org>

To: Contributors <contributors@odoo-community.org>

Subject: Slides for Making Odoo Faster talk at OCA Days 2025

Date: Wednesday, September 17, 2025 11:26

Hello,

For those interested, the slides for the talk Making Odoo Faster

Analyzing Odoo’s Speed that I gave yesterday are available here:

https://docs.google.com/presentation/d/1HpEGgmxxSUvAhF5r1XWO-1OqiQWPPJF4jPZ-XRg-e4k/edit?slide=id.g29db379d51f_0_3#slide=id.g29db379d51f_0_3

--

Alexandre Fayolle

Senior Software Engineer and Architect

Camptocamp France SAS

http://www.camptocamp.com

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Yves Goldberg - 10:36 - 17 Sep 2025

Slides for Making Odoo Faster talk at OCA Days 2025

Hello,

For those interested, the slides for the talk Making Odoo Faster
Analyzing Odoo’s Speed that I gave yesterday are available here:

https://docs.google.com/presentation/d/1HpEGgmxxSUvAhF5r1XWO-1OqiQWPPJF4jPZ-XRg-e4k/edit?slide=id.g29db379d51f_0_3#slide=id.g29db379d51f_0_3

--

Alexandre Fayolle
Senior Software Engineer and Architect

Camptocamp France SAS
http://www.camptocamp.com

by Alexandre Fayolle - 10:26 - 17 Sep 2025

Oferta de empleo de Consultor/a Odoo

Buenos días,

Me pongo en contacto con vosotros ya que actualmente disponemos de una oferta de empleo que podría resultar de interés para vuestros/as asociados/as.

Estamos buscando un perfil de Consultor Odoo para Valladolid en modalidad híbrida y me preguntaba si sería posible publicar la oferta en vuestra página web para que pudieran inscribirse las personas interesadas en la misma.

En el siguiente enlace puedes ver todos los detalles de la oferta: https://www.jobfie.es/trabajo/13896540/Valladolid/consultora-erp-odoo-contrato-indefinido

Cualquier duda quedo a vuestra disposición.

Gracias de antemano, un saludo.

--
FIRMA SANDRA RODRIGUEZ

Sandra Rodríguez

Jobfie | Portal de empleo

Responsable de operaciones

sandra.rodriguez@jobfie.es

Valladolid, España

www.jobfie.es

El contenido de este correo electrónico es confidencial y está destinado únicamente al destinatario especificado en el mensaje. Está estrictamente prohibido compartir cualquier parte de este mensaje con terceros, sin el consentimiento por escrito del remitente. Si recibió este mensaje por error, responda a este mensaje y continúe con su eliminación, para que podamos asegurarnos de que ese error no ocurra en el futuro.

Libre de virus.www.avast.com

by "Sandra Rodriguez" <sandra.rodriguez@jobfie.es> - 11:25 - 16 Sep 2025

Re: Application for PSC Role – RMA Repository

Hi Souheil,

You can do a PR there: https://github.com/OCA/repo-maintainer-conf/pulls

Le mar. 16 sept. 2025 à 10:42, Bejaoui, Souheil <notifications@odoo-community.org> a écrit :

Dear contributors,

I would like to apply for the PSC role for the RMA repository.

Over the last months, I have been actively contributing to the RMA repository, working on several improvements to the base module to provide a more flexible and configurable workflow depending on the operation. I have also introduced new modules that add important features, such as RMA reasons, lot/serial number tracking, and I am currently working on the integration between RMA and the repair module.

I believe I can contribute to maintaining and evolving this stack by reviewing, testing, and supporting new contributors.

You can find my PRs here: https://github.com/OCA/rma/pulls/sbejaoui

Best regards,

--
Souheil Bejaoui
Software engineer

Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Zone industrielle 22 | L-8287 Kehlen | Luxembourg

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Denis Roussel - 10:51 - 16 Sep 2025

Re: Application for PSC Role – RMA Repository

Souheil, put the PR directly in https://github.com/OCA/repo-maintainer-conf

Regards.

by Pedro M. Baeza - 10:51 - 16 Sep 2025

Application for PSC Role – RMA Repository

Dear contributors,

I would like to apply for the PSC role for the RMA repository.

Over the last months, I have been actively contributing to the RMA repository, working on several improvements to the base module to provide a more flexible and configurable workflow depending on the operation. I have also introduced new modules that add important features, such as RMA reasons, lot/serial number tracking, and I am currently working on the integration between RMA and the repair module.

I believe I can contribute to maintaining and evolving this stack by reviewing, testing, and supporting new contributors.

You can find my PRs here: https://github.com/OCA/rma/pulls/sbejaoui

Best regards,

--

Souheil Bejaoui

Software engineer

Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium

Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium

Zone industrielle 22 | L-8287 Kehlen | Luxembourg

by Souheil Bejaoui - 10:41 - 16 Sep 2025

OCA Days 2025 Streaming

Hi all,

Here are the links to the OCA Days Streaming:

odoocommunity1 => Mosane 5+6

odoocommunity2 => Mosane 2+3

odoocommunity3 => Mosane 7+8+9

Here is the agenda:

https://odoo-community.org/event/oca-days-2025-liege-2025-09-15-2025-09-18-174/agenda

Have a great day,

Rebecca

--

Rebecca Gellatly

General Secretary

Odoo Community Association

by Rebecca Gellatly (OCA) - 10:20 - 16 Sep 2025

Re: The Consultant Working Group is looking for you!

Dear Julie,

I'm not sure why 3 years of experience is required for non-technical volunteer work in the 'Consultant / Functional Workgroup.' In my opinion, it's actually better for consultants not to have technical knowledge, and those with IT expertise can join other workgroups.

What seems more important is finding people who are enthusiastic, willing to consistently contribute their free time, and committed to staying involved, even without compensation.

Wishing you and the other Consultant / Functional Workgroup members the best in finding the right contributors. I also hope you’ll all consider dropping the 3-year Odoo experience requirement in favor of prioritizing commitment.

Looking forward to seeing all OCA members at OCA Days 2025 in Liège.
Let's have a drink next week, Julie. I’m also curious to hear why the workgroup is asking for 3 years of experience.

Best, Michel.

Office Everywhere
Business Partner Odoo

t: +31 6 53360677
e: mstroom@office-everywhere.com
w: Office-Everywhere.com

On 2025-09-13 10:21, Julie LeBrun (OCA) wrote:

Dear members,
Did you know we have a working group for consultant / functional people?

We are looking for new members in this group so if you are interested, please contact me (Julie) at julie@odoo-community.org.

The "Raison d'être" of the group is to help and attract functional people (non-technical) to contribute to the OCA.

Here are the requirements to be part of this group:
- More than 3 years of experience with OCA tools (GitHub, Weblate...) and modules
- More than 3 years of experience as a Consultant on Odoo
- More than 3 years of experience with Odoo
- Availability (1 wg meeting a month + 4h /month to contribute)
- Approval from the majority of the actual members of the WG

We will meet at the OCA Days on Monday morning so if you are interested, come and meet us (and contact me to let me know).

P.S. In October, we will start a series of Support group meeting for functional / consultant so even if you don't meet the requirements to be part of the group, you can still attend these meetings.

More info here : https://odoo-community.org/event/oca-consultants-support-group-session-2025-10-07-206/register

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Michel Stroom - 06:30 - 15 Sep 2025

OCA AGA Delelgates Campaign open now - till October 3rd

Hello OCA Contributors

I hope this finds you all well.

It is that time of year again for the OCA Annual General Assembly

The 2025 OCA Delegates Campaign is now open. Until October 3rd, you can apply to be an OCA Delegate if you are a current paid Member.
If you are already a Delegate, you don't need to apply again. This is for 10 new Delegates.

Why?
The Delegate Assembly is the Association’s supreme authority. Each Delegate member is entitled to one vote at the Delegate Assembly. Decisions of the Delegate Assembly are taken by a majority vote of the Delegate members present and voting. For further details, please read the Bylaws.

How?
To apply as a candidate, you have to:

sign the CLA (if not already done)
have a valid membership. Make sure to purchase your membership or renew it (you should have received a quotation for your renewal earlier this year).
fill in this survey

If you aren't sure if you have renewed/paid your membership for 2025 please contact me.

The campaign will be closed on October 3rd, 2025.

Then what?
The vote will be open from October 6th - October 17th. Current OCA Delegates will have to vote for 10 new Delegates among the candidates.

The results of the election will be announced on October 20th, 2025.

The 10 new Delegates will then take part with the existing Delegates in :

the 2025 OCA Board Member Campaign from October 20th - October 31st, 2025
the 2025 OCA Financial Auditor Campaign from October 20th - October 31st, 2025
the 2025 General Assembly from November 3rd to November 14th 2025.
2025 Board announced - week beginning November 17th, 2025

If you have any questions please get in touch.

Warmest regards,
Rebecca

--

Rebecca Gellatly

General Secretary

Odoo Community Association

by Rebecca Gellatly (OCA) - 11:25 - 15 Sep 2025

Re: Licence question: using AGPL and Odoo proprietary modules on the same server

One last thing. IMO, throw away any ideas of dual licensing. That is the worst of all the discussion here. For 1 OCA, cannot do it imo, but for 2, Bradley Kuhn has spent the last 10 years chastising the relicense industry and how it is leading free software licensing to even more restrictive copyleft just to protect themselves from these unscrupulous actors hiding behind CLAs to defy authors wishes. And it is hard to disagree with him on this.

Le dim. 14 sept. 2025, 09:05, Graeme Gellatly <graeme@moahub.nz> a écrit :

Sorry on that point. Of course, whatever the original author decides. There is only 3 realistic choices anyway.
For me it is nearly always AGPL. I was not advocating OCA relicense to AGPL by any stretch, just encouraging its use and not to throw it away over some vendor FUD.
Le dim. 14 sept. 2025, 08:37, Joël Grand-Guillaume <notifications@odoo-community.org> a écrit :
Dear community,

I strongly agree with Maxine here. The OCA accept any OSI compliant licences and since the begining it has always left the choice to the contributors among available ones.

I invite you to read our FAQ under chapter licences & CLA: https://odoo-community.org/resources/faq

It explains what's needed. If you feel there is something not clear enough or missing, please write your proposal to: support AT odoo-community.org

Looking forward to meeting you in person at the OCA days, a good place to discuss it if you feel the need for it.

Best regards,

Joël
Le sam. 13 sept. 2025, 22:21, Maxime Chambreuil <notifications@odoo-community.org> a écrit :
Hello,

Since everybody is giving its opinion, here is mine.

I think the license the contributor decides to put in the modules he is contributing to the OCA is his choice and should not be judged. We are a community, not a team or company. We don't necessarily share the same objectives and we don't necessarily aim for the same impact or result when contributing.

The only thing the OCA should do on this topic is educate so contributors make the right choice reflecting their values in complete awareness of the pros and cons. A page or blog post on the oca website comparing the different licenses, with pros and cons, with correct/incorrect legal/illegal behavior.

My 2 cents on the license. More to come on the contributions in the other thread later.

Cheers

--
Maxime Chambreuil

Desde mi móvil

From: Raphaël Valyi <notifications@odoo-community.org>
Sent: Saturday, September 13, 2025 6:36:58 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Licence question: using AGPL and Odoo proprietary modules on the same server
Eventually we could create a simple OCA tutorial that would give an example use case where a company needs customizations that depend both on OCA AGPL and LGPL modules and need to protect some IP. We could give a few guidelines how to split the codebase between AGPL and LGPL derivatives.

Obviously there would always be a grey area where people would carefully craft glue modules to action OCA AGPL code without explicitly depending on it.

But eventually we could still cover the most obvious cases. This could help to:

- limit the FUD about AGPL

- incentivate more actors to publish what should be published

Would it be risky for the OCA to publish such guidelines if a court finally interpret things differently? Should we officially cover the EE case as well?

Finally about AGPL enforcement in general: one thing is the AGPL be violated by some final users. Just like piracy in general, it's hard to avoid indeed.

But at least the AGPL should ideally protect us against massive violation by big SaaS players (because of the legal risks). Without such protection, a big actor (Odoo SA themselves?) would easily put all OCA modules authors out of business by creating superior private derivatives without any attribution, much like some open source editors complained GAFAM like companies created unfriendly forks of their products.

Notice however that if the OCA starts selling double license exceptions, we will not even be sure we could name and shame or even sue some company who is obviously extending an OCA module without publishing it back. So I think it would just incentivate piracy, not a net positive for me...
On Sat, Sep 13, 2025, 8:47 AM Frederik Kramer <notifications@odoo-community.org> wrote:
Hi Greame,

there is amble debate on when an AGPL licenced software is actually made 
publicly available. To cases where it is pretty clear (to me and most 
people that i know do academic research on the matter):

1.) Your company is actually consisting of more then one legal entities 
collaborating on the same system (e.g. holding structure)

2.) If you use E-Commerce ar any means of direct user acces (like portal 
functions)

3.) If you let externals to your company access to the software (even 
with a VPN), e.g. freelancer use cases, suppliers, customers

Furthermore as soon as you modify anything you implicitely agree to the 
license liabilities

See 
https://www.reddit.com/r/opensource/comments/1hh25a0/agpl_for_software_hosted_internally/ 
for a little bit of debate on the matter

Best Frederik

Am 13.09.25 um 13:02 schrieb Graeme Gellatly:




>




> The simplest way is to just not accept the license and not propagate 




> the AGPL licensed work. As long as you are using it unmodified, there 




> is no requirement to accept. Clause 9 is quite clear. 




> Conveyance/propagation as a combined work is easily avoided.





-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Graeme Gellatly - 11:16 - 13 Sep 2025

Archives

Contributors

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Slides for OpenUpgrader module for Odoo at OCA Days 2025

Re: Guidelines for LLM generated contributions

Guidelines for LLM generated contributions

Re: OCA/bank-payment-alternative

Re: Slides for Making Odoo Faster talk at OCA Days 2025

Re: The Consultant Working Group is looking for you!

Re: Slides for Making Odoo Faster talk at OCA Days 2025

Slides for Making Odoo Faster talk at OCA Days 2025

Oferta de empleo de Consultor/a Odoo

Re: Application for PSC Role – RMA Repository

Re: Application for PSC Role – RMA Repository

Application for PSC Role – RMA Repository

OCA Days 2025 Streaming

Re: The Consultant Working Group is looking for you!

OCA AGA Delelgates Campaign open now - till October 3rd

Re: Licence question: using AGPL and Odoo proprietary modules on the same server

Follow us