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	New API, framework/ORM
@xmo-odoo	CSV import, Documentation
@qdp-odoo	Accounting, Accounting reports
@jco-odoo	Stock, MRP
@gde-odoo	Discuss, 9.0 Web client
@aab-odoo	Discuss, 9.0 Web client, IM/Livechat v9, Docker images
@tde-odoo	Mail, Porting modules to new API
@jem-odoo	IM/Livechat v8, Porting modules to new API
@Gorash	Website editor, QWeb assets
@jke-odoo	CRM, website_(sale|forum|blog|...)
@mart-e	Translations, Point of Sale, Access Rights, Documentation, Gamification
@sle-odoo	QWeb assets, Reports, Mobile apps, Install packages, Docker images
@tac-odoo	Awesome timesheets
@qsm-odoo	LESS/CSS themes
@KangOl	Migrations, OAuth
@dbo-odoo	9.0 Subscriptions, Online Quotes
@nim-odoo	9.0 sales, timesheets, purchase
@apr-odoo	Usability, on-boarding
@csn-odoo	Accounting, Yodlee/Plaid integration
@fwi-odoo	Ebay/Amazon integration, VOIP
@rim-odoo	Shipping integration (DHL, Fedex, ...)
@dmo-odoo	Odoo Apps, Website forms
@odony	Security, Authentication, Access Rights, API compatibility
...	... Feel free to amend...

Pull Requests

• Never merge them
• You can close them without merging, with an explanation. You can close them and suggest resubmitting if they target the wrong branch (e.g. improvements proposed to a stable branch), or 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.