Olivier Dony edited this page Feb 1, 2018 · 28 revisions

This internal page contains guidelines for outside contributors helping with the management of issues on the bugtracker.

Basic rules

  • Don't be afraid to make mistakes when handling issues. Nothing terrible can happen, and it's all fixable anyway.
  • Repositories: never push to the odoo/odoo repository please - this requires explicit permission from core R&D team
  • PRs: never merge PRs yourself (same as previous rule, basically)
  • PRs: closing without merge, tagging/labelling, editing description, setting milestones, assigning is all OK.
  • Issues: closing, reopening, tagging/labelling, editing, assigning, setting milestones is all OK.


  • Labels: the meaning of labels is explained in our contribution guide. Feel free to suggest changes as needed.
    • For now using explicit labels for series (8.0, 9.0, ..) would seem to represent a huge administrative burden and be basically redundant with the current convention in titles. And the convention can be used by every bug reporter.
  • Guidelines for good bug reports are also in the Contributing guide.
  • Issues that are redundant with their PR can be freely closed with an explanation.
  • Issues that are not sufficiently detailed (e.g. no steps to reproduce) can be closed if the poster does not respond to clarification requests - but please ask for info first, with a link to the issue template.
  • Assignation: you can directly assign a responsible Odoo developer if they were the last person to modify the problematic code, or if you know this is their area of expertise. Some examples (may or may not be up-to-date):
Name Topic
@rco-odoo Framework, ORM
@xmo-odoo CSV import, Documentation, Python 3 (P3)
@qdp-odoo Accounting, Accounting reports
@lap-odoo Accounting, Localizations (RFC), Logistics
@jco-odoo Logistics, MRP
@ged-odoo Discuss, Web client / JS Framework, Studio
@aab-odoo Discuss, Web client, IM/Livechat, Studio
@mge-odoo Web client, Studio
@tde-banana-odoo CRM, Mail, Services
@jem-odoo Timesheets, Services
@tivisse Services
@jke-be website _(sale|forum|blog|...), Payment Acquirers
@mart-e Internationalization, Access Rights, Documentation, Gamification
@sle-odoo Logistics, MRP, Reports
@adr-odoo Mobile App
@qsm-odoo LESS/CSS themes, Web Editor
@KangOl Migrations, OAuth
@nim-odoo Sales, Timesheets, Purchase
@fgi-odoo Usability, On-boarding
@csn-odoo Accounting, Yodlee/Plaid integration
@rim-odoo Shipping integration (DHL, Fedex, ...)
@dmo-odoo Odoo Apps, Website forms, IAP
@rar-odoo Odoo Apps, IAP
@odony Security, Authentication, Access Rights, Server binary, command-line parameters
@pimodoo Point of Sale
@d-fence Install packages, Docker images
@amigrave @rim-odoo @icallhimtest @beledouxdenis Odoo.sh
... ... Feel free to amend...

Pull Requests

  • Never merge them, ask the R&D team to do it
  • You can close them without merging, with an explanation. You can suggest retargetting if they are on the wrong branch (e.g. improvements proposed to a stable branch). You can close them if they have zero chance of being ever accepted (e.g they touch hundreds of files for a useless improvement) https://github.com/odoo/odoo/wiki/Contributing#what-does-stable-mean is the reference policy. Some other examples:
    • Coding styles / PEP8 changes should never be the subject of a PR
    • A PR should address one single purpose and should be minimalistic.


Don't hesitate to ask @odony or @mart-e for help if you are unsure about something, as usual. And don't hesitate to act anyway if they don't answer fast enough. You can always drop a note/mention and ask us to review later.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.