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 Before Coding Coding Submitting Features Test Processes GitHub Issues Billing & Bonuses Types of Work Tool Fluency Documentation

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.

Submitting Features

Merged by Maintainer

If you are new to our team and setup, someone will review, merge and deploy your code. Follow these steps to submit your features:

  1. Fork the repo.
  2. Code your module on any environment of your choice, preferably Linux or MacOS.
  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.
  6. Maintainer pulls (p) code on a demo server. More testing on demo.
  7. If tests are successful, PR is created for main branch.
  8. Feature is deployed on production.

Self Merging

If you have written a substantial amount of code of Simplify-ERP™ and/or PowerOn™ setups, you can merge and deploy your own code.

  1. Follow above steps.
  2. Merge (m) your code.
  3. Deploy (git pull) your code.
  4. Post an update on the original Issue on Github carrying following details.
  5. If tests are successful, PR is created for main branch.
  6. Feature is deployed on production.

Transferring to Customer/Owner

Following have to be submitted no matter if you self-merge or your code is merged by a Maintainer.

URL for testing:
https://myproject.simplify-erp.de/test-case/..

How to test:
Link to README file in code-base.

Link to code: 
https://github.com/euroblaze/myproject/tree/main/odoo-code.

Programmers must be mindful that we aim zero-quality-rejections from customer on 

  • Scope-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.

Owner Testing

Done by the "Owner" that originally requested the coding-task, 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.

Issue Description

If you describe an Issue on Github for a new features, ensure structure it into these 3 sections:

  • Business Requirement
  • Logical Solution
  • Odoo Technical Solution

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

https://education.github.com/git-cheat-sheet-education.pdf

vor 2 Tagen

Billing & Bonuses

No matter if you are an internal developer or supporting externally, some rules apply.

Estimations
  1. Estimate the time you need to implement the issue.
  2. Estimate the day you aim to deliver the issue.
  3. The start_date is the day you are requested to estimate.
  4. Commit maximum to your weekly available time-budget.
Billing
  1. Issues can be passed on to billing/bonus when deployed on prod and it is submitted to customer by email. This is marked by the status "Done" on the GH-Issue.

Types of Work

As an experienced Odoo developer, you will work on following types of work:

  1. Version upgrades (currently v16, v18). 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.