BugManagement

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.

Issues

• 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 (11.0, 12.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	ORM
@xmo-odoo	CSV import, Documentation, Python 3 (P3)
@qdp-odoo	Accounting, Accounting reports
@jco-odoo	Localizations
@ged-odoo	Discuss, Web client / JS Framework, Studio
@aab-odoo	Web client, IM/Livechat, Studio
@aku-odoo	Discuss
@tde-banana-odoo	Sale/Marketing (CRM, Mail, mass_mailing, e-learning)
@tivisse	Services (project, timesheet, planning)
@tivisse	HR (hr_*, lunch, ...)
@jke-be	website _(sale|forum|blog|...)
@mart-e	Internationalization, Access Rights, Documentation, Gamification
@amoyaux	Logistics, MRP, Reports
@adr-odoo	Mobile App
@qsm-odoo	LESS/CSS themes, Web Editor
@KangOl	Migrations, OAuth
@csn-odoo	Accounting, Yodlee/Plaid integration
@rim-odoo	Shipping integration (DHL, Fedex, ...)
@pimodoo	Point Of Sale
@dmo-odoo	Odoo Apps, Website forms, IAP
@rar-odoo	Odoo Apps, IAP
@odony	Security, Authentication, Access Rights, Server binary, command-line parameters
@d-fence	Install packages, Docker images
@amigrave @rim-odoo @icallhimtest @beledouxdenis	Odoo.sh
@qle-odoo	IoT
...	... 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 minimalist.

Help

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.