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 (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
@qdp-odoo	Accounting, Accounting reports
@jco-odoo	Stock, MRP
@gde-odoo	Discuss, Web client
@aab-odoo	Discuss, Web client, IM/Livechat v9, Docker images
@tde-odoo	Mail, Porting modules to new API
@jem-odoo	Porting modules to new API, timesheets
@Gorash	Website editor, QWeb assets
@jke-be	CRM, website_(sale|forum|blog|...)
@mart-e	Translations, Access Rights, Documentation, Gamification
@sle-odoo	QWeb assets, Reports, Mobile apps
@qsm-odoo	LESS/CSS themes
@KangOl	Migrations, OAuth
@dbo-odoo	Subscriptions, Online Quotes
@nim-odoo	Sales, timesheets, purchase
@apr-odoo	Usability, on-boarding
@csn-odoo	Accounting, Yodlee/Plaid integration
@rim-odoo	Shipping integration (DHL, Fedex, ...)
@dmo-odoo	Odoo Apps, Website forms
@odony	Security, Authentication, Access Rights, API compatibility, Server binary, command-line parameters
@pimodoo	Point of Sale
@d-fence	Install packages, Docker images
...	... 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.

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.