Recent changes to Contribution Guidelines

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:51 -0000

--- v11
+++ v12
@@ -50,14 +50,14 @@
 Module properties should be named exactly like this: \<modulename\>Props. This will be used in automation very soon


-# Step to Contribute to apraPipes :- External Contributers
+# Step to Contribute to ApraPipes :- External Contributors

 * Make your own [fork](https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/about-forks)
 * Create a new branch for every feature/module
 * Fetch from [main](https://github.com/Apra-Labs/ApraPipes/) repo and merge to new branch
 * Push new branch to your fork
 * Make new [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) from the branch

-# Step to Contribute to apraPipes :- Apra Labs Contributers
+# Step to Contribute to ApraPipes :- Apra Labs Contributors

 * Contact code owners to be added as a collaborator
 * Pick up an issue / create an issue and assign it to your self
 * Create a branch from [main](https://github.com/Apra-Labs/ApraPipes/) repo and push your changes in the branch
</modulename\>

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:51 -0000

--- v10
+++ v11
@@ -93,8 +93,6 @@
     */
    int add(int num1, int num2);


-   -
-
 * **Documenting Variables**:
    - Use Doxygen-style comments to document important variables, especially if their purpose is not immediately clear from their name or context.
    - Describe the variable's purpose, data type, and any relevant details.
@@ -119,5 +117,5 @@
   - Create a markdown file on the topic you want to add to the documentation.
   - Add the `.md` file inside `data/gh-pages-assets/pages` .
   - Append the path `./data/gh-pages-assets/pages/<your-filename>.md` at the end of the `INPUT` tag in the `Doxyfile`.
-  - Rebuild the documenation.
+  - Rebuild the documentation using the `build_documentation.sh` script.

</your-filename>

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:51 -0000

--- v9
+++ v10
@@ -114,3 +114,10 @@

 * **References**:
   - Please refer to the following [link](https://www.doxygen.nl/manual/docblocks.html) for more examples.
   - Also refer to the [H264DecoderV4L2Helper](https://github.com/Apra-Labs/ApraPipes/blob/main/base/src/H264DecoderV4L2Helper.cpp) for a complete module example.
+
+* **Add custom pages to the doxygen documentation**:
+  - Create a markdown file on the topic you want to add to the documentation.
+  - Add the `.md` file inside `data/gh-pages-assets/pages` .
+  - Append the path `./data/gh-pages-assets/pages/<your-filename>.md` at the end of the `INPUT` tag in the `Doxyfile`.
+  - Rebuild the documenation.
+ 
</your-filename>

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:51 -0000

--- v8
+++ v9
@@ -64,3 +64,53 @@

 * Create pull request from the new branch and assign a reviewer.
 * Update branch from main whenever needed
 * After all checks pass feel free to merge your changes to main
+
+# Doxygen Documentation Guidelines
+* Doxygen [Official Documentation](https://www.doxygen.nl/manual/docblocks.html)
+
+* **Commenting Basics**:
+   - Comment should be written using the Doxygen style.
+   - Use descriptive and meaningful comments to explain the purpose of functions, classes, variables, and complex logic.
+   - Comments should be concise but informative, providing enough context for someone unfamiliar with the code to understand its functionality.
+   - If any generative AI is used to create the comments, use it as a base to setup and then edit / clean up. Usually gen AI comments are local / superficial, so you will have to make sure the idea is described clearly.
+   - Make use of Doxygen tags for all functions and classes. This should not be skipped.
+
+* **Doxygen Tags**:
+   - Doxygen uses special tags to recognize comments and generate documentation. Some common tags include:
+       - `/** ... */` for documenting functions, classes, and variables.
+       - `@brief` for providing a brief description of the item being documented.
+       - `@param` to describe function parameters.
+       - `@return` to describe the return value of a function.
+       - `@code ... @endcode` to include code snippets within comments.
+       - `@note` for additional notes or remarks.
+   - Begin each function with a Doxygen-style comment block. For example -
+   ```cpp
+   /**
+    * @brief Calculate the sum of two numbers.
+    * @param num1 First number.
+    * @param num2 Second number.
+    * @return Sum of num1 and num2.
+    */
+   int add(int num1, int num2);
+
+   -
+
+* **Documenting Variables**:
+   - Use Doxygen-style comments to document important variables, especially if their purpose is not immediately clear from their name or context.
+   - Describe the variable's purpose, data type, and any relevant details.
+
+   ```cpp
+   /// Radius of the circle.
+   double radius;
+
+* **Contributors Responsibilities**:
+   - Raising a PR for a New Module:
+      - Provide an overview comment at the beginning of the module file, describing the purpose and functionality of the module.
+      - Add brief comments for each member functions and member variables.
+      - Follow the above guidelines and add comments for all the necessary functions and variables.
+   - Raising a PR for an Existing Module:
+      - Add comments for updated as well as existing functions.
+      - Follow the above guidelines and add comments for all the necessary functions and variables.
+* **References**:
+  - Please refer to the following [link](https://www.doxygen.nl/manual/docblocks.html) for more examples.
+  - Also refer to the [H264DecoderV4L2Helper](https://github.com/Apra-Labs/ApraPipes/blob/main/base/src/H264DecoderV4L2Helper.cpp) for a complete module example.

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:46 -0000

--- v7
+++ v8
@@ -3,6 +3,7 @@
 ### Module Properties

 * No hardcoding
 * Dynamic support to change properties
+

 ### Style

 * Core logic should be in Detail class
@@ -29,15 +30,25 @@
 * Unit test should not have sleep

 ## Naming conventions
-Name classes and modules as follows
-[Name][Src/Xform/Sink]{_OptionalPlatform} e.g.
-AudioRecordSrc
-AffineXform_NPPI
-etc.
+
+**Name modules classes as follows**
+
+[Name][Src/Xform/Sink]{_OptionalPlatform} 
+
+e.g.
+* AudioRecordSrc
+* AffineXform_NPPI
+* etc.
+
 A platform variant should be created in very rare scenario. As far as possible we should try to 
-1. Consolidate all platform variants into a single Module 
-2. Offer a common interface 
-3. Learn the users intentions via input/output pins or have explicit option about which variant to use.
+1. Consolidate all platform variants into a single module
+1. Offer a common interface
+1. Learn the users intentions via input/output pins or have explicit option about which variant to use.
+
+**Name modules properties as follows**
+
+Module properties should be named exactly like this: \<modulename\>Props. This will be used in automation very soon
+

 # Step to Contribute to apraPipes :- External Contributers

 * Make your own [fork](https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/about-forks)
</modulename\>

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:46 -0000

--- v6
+++ v7
@@ -1,3 +1,44 @@
+# Coding style and naming conventions
+## Code style and Checks before raising PRs
+### Module Properties
+* No hardcoding
+* Dynamic support to change properties
+
+### Style
+* Core logic should be in Detail class
+* No declarations in .h file - only base class methods overriding is allowed
+* Use mCamelCase
+* Format the code using ctrl+shift+I
+* No unused variables, unused header files
+* No Commented Codes
+* If any Detail class variable has to be accessed in module, don't use set, get - make the variables public
+
+### Performance
+* No memcopy unless it is unavoidable
+* Initialize everything in init
+* Destroy everything in term
+* Use object pool for temporary variables
+
+### Unit Tests
+* Test for each supported color format
+* If output is image - use saveorcompare
+* Always use FileReader as input for transform modules
+* Use step rather than pipeline.run_all_threaded()
+* Test for dynamic change of props and validation
+* Use external sink module wherever applicable
+* Unit test should not have sleep
+
+## Naming conventions
+Name classes and modules as follows
+[Name][Src/Xform/Sink]{_OptionalPlatform} e.g.
+AudioRecordSrc
+AffineXform_NPPI
+etc.
+A platform variant should be created in very rare scenario. As far as possible we should try to 
+1. Consolidate all platform variants into a single Module 
+2. Offer a common interface 
+3. Learn the users intentions via input/output pins or have explicit option about which variant to use.

+ 
 # Step to Contribute to apraPipes :- External Contributers
 * Make your own [fork](https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/about-forks)
 * Create a new branch for every feature/module

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:46 -0000

--- v5
+++ v6
@@ -11,3 +11,4 @@

 * Create a branch from [main](https://github.com/Apra-Labs/ApraPipes/) repo and push your changes in the branch
 * Create pull request from the new branch and assign a reviewer.
 * Update branch from main whenever needed
+* After all checks pass feel free to merge your changes to main

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:46 -0000

--- v4
+++ v5
@@ -1,6 +1,13 @@
-Step to Contribute to apraPipes :-
+# Step to Contribute to apraPipes :- External Contributers

 * Make your own [fork](https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/about-forks)
 * Create a new branch for every feature/module
-* Fetch from [main](https://github.com/kumaakh/ApraPipes/) repo and merge to new branch
+* Fetch from [main](https://github.com/Apra-Labs/ApraPipes/) repo and merge to new branch
 * Push new branch to your fork
 * Make new [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) from the branch
+
+# Step to Contribute to apraPipes :- Apra Labs Contributers
+* Contact code owners to be added as a collaborator
+* Pick up an issue / create an issue and assign it to your self
+* Create a branch from [main](https://github.com/Apra-Labs/ApraPipes/) repo and push your changes in the branch
+* Create pull request from the new branch and assign a reviewer.
+* Update branch from main whenever needed

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:46 -0000

--- v3
+++ v4
@@ -1,5 +1,5 @@
 Step to Contribute to apraPipes :-
-* Make your own fork
+* Make your own [fork](https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/about-forks)

 * Create a new branch for every feature/module
 * Fetch from [main](https://github.com/kumaakh/ApraPipes/) repo and merge to new branch
 * Push new branch to your fork

Contribution Guidelines modified by Aslam Hirani

Aslam Hirani — Tue, 12 May 2026 05:47:46 -0000

--- v2
+++ v3
@@ -3,4 +3,4 @@

 * Create a new branch for every feature/module
 * Fetch from [main](https://github.com/kumaakh/ApraPipes/) repo and merge to new branch
 * Push new branch to your fork
-* Make new PR from the branch
+* Make new [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PR) from the branch