Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This internal page contains guidelines for outside contributors helping with the management of issues on the bugtracker.
- 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):
|@xmo-odoo||CSV import, Documentation, Python 3 (P3)|
|@qdp-odoo||Accounting, Accounting reports|
|@lap-odoo||Accounting, Localizations (RFC), Logistics|
|@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|
|@jke-be||website _(sale|forum|blog|...), Payment Acquirers|
|@mart-e||Internationalization, Access Rights, Documentation, Gamification|
|@sle-odoo||Logistics, MRP, Reports|
|@qsm-odoo||LESS/CSS themes, Web Editor|
|@nim-odoo||Sales, Timesheets, Purchase|
|@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...|
- 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.