Only Modules
All feature requests are implemented as modules.
This includes:
- View modifications.
- New functionality.
- Website/E-Commerce UI changes.
Before Coding
You receive a functional requirement from a Business Process Consultant.
- Check if an OCA module exists to partially or fully satisfy the requirement.
- Check the same on O-Appstore.
- If you determine that you to code a new module, write a readme.md with following sections. You can use writers like ChatGPT.
-
- What is the problem that this module solves?
- Solution description, including if necessary with Figma UI/UX.
- Pre-requisites
- Usage
- Known Issues
Coding
When coding a solution, your module follow following versions:
- Alpha – It's feature complete and you can demonstrate on your local.
- Beta – Minimal testing is successful and it is deployed on the online demo server.
- Minimum Viable Product (MVP) is achieved by further bugfixes and enhancements. Module is released on production.
- Based on customer feedback, Minimum Remarkable Product (MRP) is defined and released.
Committing Code
Follow these steps to commit code for a specific feature:
- Fork the repo.
- Code your module on any environment of your choice.
- Submit Pull Request (PR) to demo branch.
- A Reviewer/Maintainer reviews (r) your code.
-
- If it's good, it will be merged (m) into demo branch.
- Else changes are requested by Maintainer on Github/repo/pulls.
- Maintainer pulls (p) code on a demo server. More testing on demo.
- If tests are successful, PR is created for main branch.
- Feature is deployed on production.
- We aim zero-quality-rejections from customer on
-
- feature-completion,
- code-quality
Test Processes
We employ 3 levels of testing for features and fixes.
Developer Testing
Done by developer who wrote the code himself, possibly using low data volumes, in non-contextual use-cases. This is the lowest level of testing, by nature unreliable.
Project Manager Testing
Done by PM in broader contextual use-cases, potentially still with limited data-sets.
Customer + PM Testing
PM and customer together test the feature, to ensure full use-case coverage, potentially on live database.
GitHub Issues
GH Issues are used for defining enhancements, bug-reports and new modules.
RFQ & RFC
- When an Issue is prefixed RFQ, it means an effort-estimation is expected before coding.
- When an Issue is prefixed RFC, it means further discussion/ideation is necessary.
Submodules
If the functionality of a repo builds on top of a different module, include the base module as a GitHub submodule.
Implementation Schedule
Implementation dates (1, 2), effort estimation (4) and project association (3) are maintained on the GitHub-Issue itself.
Git Cheatsheet from GitHub
Types of Work
As an experienced Odoo developer, you will work on following types of work:
- Version upgrades (currently v16, v17). Upgrade modules and use OpenUpgrade for database upgrades.
- Production support / go-live support.
- New module conception, documentation and programming.
- Refactoring existing modules.
- Enhancements to existing modules.
Tool Fluency
As an Odoo developer, you will demonstrate 2+ years of fluency in the following tools:
- GitHub
- Linux – NGINX webserver
- Docker
- Odoo Technical Framework
Documentation
“Code is more often read than written.”
We write inline code documentation. Guidelines for writing documentation are:
- Explain WHY the class/method. (What the it does is then easy to understand by reading the code).
“Code tells you how; Comments tell you why.” – Jeff Atwood
- Mention references to UI where this code impacts.
- Mention to-dos for future developers to fix or enhance the code if necessary.