Developer Guidelines

On this page we document the standard operating procedures for developers to contribute to PowerOn™ – the Odoo based ERP for renewable energy companies.


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.

  1. Check if an OCA module exists to partially or fully satisfy the requirement.
  2. Check the same on O-Appstore.
  3. If you determine that you to code a new module, write a readme.md with following sections. You can use writers like ChatGPT.
    1. What is the problem that this module solves?
    2. Solution description, including if necessary with Figma UI/UX.
    3. Pre-requisites
    4. Usage
    5. Known Issues

Coding

When coding a solution, your module follow following versions:

  1. Alpha – It's feature complete and you can demonstrate on your local.
  2. Beta – Minimal testing is successful and it is deployed on the online demo server.
  3. Minimum Viable Product (MVP) is achieved by further bugfixes and enhancements. Module is released on production.
  4. Based on customer feedback, Minimum Remarkable Product (MRP) is defined and released.

Committing Code

Follow these steps to commit code for a specific feature:

  1. Fork the repo.
  2. Code your module on any environment of your choice.
  3. Submit Pull Request (PR) to demo branch.
  4. A Reviewer/Maintainer reviews (r) your code. 
    1. If it's good, it will be merged (m) into demo branch. 
    2. Else changes are requested by Maintainer on Github/repo/pulls.
  5. Maintainer pulls (p) code on a demo server. More testing on demo.
  6. If tests are successful, PR is created for main branch.
  7. Feature is deployed on production.
  8. We aim zero-quality-rejections from customer on 
    1. feature-completion,
    2. 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:

  1. Version upgrades (currently v16, v17). Upgrade modules and use OpenUpgrade for database upgrades.
  2. Production support / go-live support.
  3. New module conception, documentation and programming.
  4. Refactoring existing modules.
  5. 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.

Standard documentation practices for ace-developers.