Feat/fresh bollinger bands factor

.github/Contributor_Guide/Contributing.md

@@ -0,0 +1,37 @@
+# Contribute to <Project_Name>
+
+Thank you for taking the time to contribute to <project_name>! We really appreciate it. 
+
+Before contributing, please make sure to read the [Code of Conduct](../../CODE_OF_CONDUCT.md). We expect you to follow it in all your interactions with the project.
+
+## New to <Project_Name>?
+
+If you are new to <Project_Name>, please take a look at the [documentation](./Project_Tour.md). It is a great place to start.
+
+## New Contributor Guide
+
+To get an overview of the codebase, check out the '[README.md](../../README.md)' file in the root directory.
+
+that will help you understand the structure of the project.
+
+## How to Contribute
+
+### Reporting Bugs
+
+If you find a bug in the source code, you can help us by [submitting an issue](../ISSUE_TEMPLATE/bug_report.yaml).
+
+### Suggesting Enhancements
+
+If you want to suggest an enhancement to <Project_Name>, please [submit an issue](../ISSUE_TEMPLATE/feature_request.yaml).
+
+### Pull Requests
+
+If you want to contribute to <Project_Name>, submit a pull request.
+
+- url: `https://github.com/OPCODE-Open-Spring-Fest/<project_Name>/compare/branch...YOURGITHUBUSERNAME:<project_Name>:BRANCH?quick_pull=1&template=pr.md`
+
+### Requirements
+
+
+### Setup
+

.github/Contributor_Guide/Project_Tour.md

@@ -0,0 +1,12 @@
+# Project Tour
+
+* notes:
+*  > Discuss about your project file structure
+*  > what each folder is responsible
+*  > then go through each file in folders and explain there purpose
+*  > if possible create a doc system ( there are autogen docs available for most of the languages )
+*  > decide coding style , linting style and formatting style and other themes like variable naming etc.
+*  > provide an example for existing function and tests system if possible 
+*  
+
+# MAKE SURE PROJECT MANAGERS UPDATE THIS MD 

.github/Contributor_Guide/commiting.md

@@ -0,0 +1,73 @@
+# Commiting Guidelines
+
+## Commit Structure
+
+- **Make Commits Atomic**: Each commit should represent a single logical change. Avoid mixing multiple changes in a single commit. If a change affects multiple files, ensure it constitutes one "logical" change.
+
+### Writing Commit Messages
+
+- **Clear Subject Line**: Start the commit message with a clear and concise description of the change. It should be no more than 50 characters, start with a capital letter, and be in imperative mood.
+
+  - > ```bash
+    > feat: Add function to calculate average
+    > ```
+
+- **Separate Subject from Body**: If further explanation is needed, include it in the body of the commit message, following a blank line after the subject line.
+
+- **Explain the Change**: The body of the commit message should explain why the change was needed and how it was implemented. Keep it wrapped to 72 characters and written in present tense.
+
+  - > ```bash
+    > fix: Resolve issue with login form not submitting on Safari
+    >
+    > This commit fixes a bug where the login form was not submitting on Safari browsers. The issue was caused by an outdated event listener binding, which has been updated to the correct syntax.
+    > ```
+
+- **Avoid "How" Details**: Use the commit message to explain what changes were made and why, not how they were made. Well-written code should be self-explanatory.
+
+- **Reference Issues or Pull Requests**: If the commit is related to an issue or a pull request, include the reference in the commit message. This can be done in the body of the message or at the end.
+
+  - > ```bash
+    > feat: Add user authentication feature
+    >
+    > Closes #123
+    > ```
+
+- **Avoid Unnecessary Punctuation**: Do not end the subject line with a period.
+
+### Commit Message Structure Rules
+
+- **Type Enum**: Ensure your commit type matches one of the predefined values: `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`.
+
+  - `build`: This type is used for changes related to build processes or tools. It includes modifications to build scripts, configuration files, and build-related dependencies.
+
+  - `chore`: Chore changes typically involve tasks related to maintenance or housekeeping. This could include updating dependencies, cleaning up code, or configuring development tools.
+
+  - `ci`: Changes related to Continuous Integration (CI) configuration files and scripts fall under this type. It includes modifications to CI pipelines, configurations for automated testing, and integration with CI services.
+
+  - `docs`: Documentation changes belong to this type. It covers updates to documentation files, such as READMEs, API documentation, or inline code comments.
+
+  - `feat`: This type is for new feature implementations or enhancements to existing features. It signifies significant additions or improvements to the codebase's functionality.
+
+  - `fix`: Use this type for bug fixes or patches. It indicates changes made to address issues or bugs in the codebase.
+
+  - `perf`: Performance-related changes are categorized under this type. It includes optimizations aimed at improving the codebase's performance, such as reducing execution time or memory usage.
+
+  - `refactor`: Refactoring changes fall under this type. It involves restructuring or cleaning up the code without changing its external behavior. Refactoring aims to improve code quality, maintainability, or readability.
+
+  - `revert`: Reverting changes made in a previous commit is indicated by this type. It's used when undoing the effects of a specific commit, often to address unexpected issues or regressions introduced by the previous change.
+
+  - `style`: Style-related changes belong to this type. It covers modifications to code style, formatting, or whitespace, without affecting the code's functionality.
+
+  - `test`: Test-related changes are categorized under this type. It includes additions or modifications to test cases, test suites, or testing infrastructure to ensure code correctness and reliability.
+
+- **Type Case**: Use lowercase for commit types.
+
+- **Subject Not Empty**: The subject line should not be empty.
+
+- **Subject Case**: Use sentence case for the subject line.
+
+- **Subject Length**: Keep the subject line under 100 characters.
+
+- **Body Leading Blank**: Ensure there's a leading blank line in the commit body.
+
+- **Body Max Line Length**: Keep each line in the commit body under 100 characters.

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -0,0 +1,75 @@
+name: Bug Report
+description: File a bug report
+title: "[Bug]: "
+labels: ["Issue:bug"]
+assignees:
+  - <project_manager>
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this bug report!
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: Description
+      description: Also tell us, what did you expect to happen?
+      placeholder: Tell us what you see!
+      value: "Describe the issue happened"
+    validations:
+      required: true
+  - type: textarea
+    id: error-message
+    attributes:
+      label: Error message
+      description: If applicable, please provide the error message you received.
+      placeholder: Copy and paste the error message here
+    validations:
+      required: false
+  - type: dropdown
+    id: severity
+    attributes:
+      label: Severity
+      description: How severe is the bug?
+      options:
+        - Low
+        - Medium
+        - High
+        - Critical
+  - type: textarea
+    id: steps
+    attributes:
+      label: Steps to reproduce
+      description: Please provide detailed steps for reproducing the issue.
+      placeholder: Tell us how to reproduce the issue
+      value: "1. 2. 3."
+    validations:
+      required: true
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: Please provide details about your environment.
+      placeholder: Tell us about your environment
+      value: "OS: \nBrowser: \nVersion: \nLanguage:..."
+  - type: textarea
+    id: screenshots
+    attributes:
+      label: Screenshots
+      description: If applicable, add screenshots to help explain your problem.
+      placeholder: Drag and drop your screenshots here
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
+      render: shell
+  - type: checkboxes
+    id: terms
+    attributes:
+      label: Code of Conduct
+      description: By submitting this issue, you agree to follow our [Code of Conduct](../Code_of_Conduct.md)
+      options:
+        - label: I agree to follow this project's Code of Conduct
+          required: true

.github/ISSUE_TEMPLATE/feature_request.yaml

@@ -0,0 +1,30 @@
+name: Feature Request 
+description: Request a feature or suggest us what is in your mind!
+title: "[Feature]: "
+labels: "Issue:feature"
+assignees:
+  - <project manager> 
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please explain what is in your mind, we would like to hear it from you! 
+
+
+  - type: textarea
+    id: explaining
+    attributes:
+      label: So, what is it about?
+      description: Please describe what you're requesting for. So, we Quant Team can understand your request better and work on it faster!
+      placeholder: It's about...
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: terms
+    attributes:
+      label: Code of Conduct
+      description: By submitting this issue, you agree to follow our [Code of Conduct](https://github.com/OPCODE-Open-Spring-Fest/template/blob/main/.github/Contributor_Guide/CODE_OF_CONDUCT.md)
+      options:
+        - label: I agree to follow this project's Code of Conduct 
+          required: true

.github/ISSUE_TEMPLATE/good-first-issue-2.md

@@ -14,6 +14,3 @@ Teach `VectorizedBacktest` to rebalance weekly or monthly via a `rebalance_freq`
 
 ### Definition of Done
 - Tests pass; daily default unchanged.
-
-
-

.github/ISSUE_TEMPLATE/good-first-issue-3.md

@@ -16,4 +16,3 @@ Modify CLI backtest command to also save a Plotly HTML chart for PnL.
 - CLI still supports Matplotlib PNG; Plotly HTML added.
 
 
-

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,17 +1,24 @@
-### Summary
-Describe the change and why it’s needed.
 
-### Changes
-- 
+## Description
+
+> Give a brief description of the pull request.
 
 ### Testing
+
 - [ ] `pytest` passes locally
 - [ ] Linting passes (`ruff`, `black`)
 
-### Screenshots (optional)
+## Semver Changes
+
+- [ ] Patch (bug fix, no new features)
+- [ ] Minor (new features, no breaking changes)
+- [ ] Major (breaking changes)
+
+## Issues
 
-### Related Issues
-Fixes #
+> List any issues that this pull request closes.
 
+## Checklist
 
+- [ ] I have read the [Contributing Guidelines](../Contributor_Guide/Contruting.md).
 

.github/workflows/checklabels.yaml

@@ -0,0 +1,21 @@
+name: Label Checker
+
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened, labeled, unlabeled]
+
+jobs:
+  check-labels:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: Set up Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 16
+      - name: Install dependencies
+        run: npm install @actions/github @actions/core
+      - name: Run Label Checker
+        run: node .github/workflows/label-checker.js
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/commitlint.yaml

@@ -0,0 +1,36 @@
+name: CI
+
+on: [push, pull_request]
+
+jobs:
+  commitlint:
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+      - name: Install required dependencies
+        run: |
+          sudo apt update
+          sudo apt install -y sudo
+          sudo apt install -y git curl
+          curl -sL https://deb.nodesource.com/setup_20.x | sudo -E bash -
+          sudo DEBIAN_FRONTEND=noninteractive apt install -y nodejs
+      - name: Print versions
+        run: |
+          git --version
+          node --version
+          npm --version
+          npx commitlint --version
+      - name: Install commitlint
+        run: |
+          npm install conventional-changelog-conventionalcommits
+          npm install commitlint@latest
+
+      - name: Validate current commit (last commit) with commitlint
+        if: github.event_name == 'push'
+        run: npx commitlint --from HEAD~1 --to HEAD --verbose
+
+      - name: Validate PR commits with commitlint
+        if: github.event_name == 'pull_request'
+        run: npx commitlint --from ${{ github.event.pull_request.head.sha }}~${{ github.event.pull_request.commits }} --to ${{ github.event.pull_request.head.sha }} --verbose

.github/workflows/label-checker.js

@@ -0,0 +1,42 @@
+import { getOctokit, context } from '@actions/github';
+import { setFailed } from '@actions/core';
+
+async function run() {
+  try {
+    const token = process.env.GITHUB_TOKEN;
+    const octokit = new getOctokit(token);
+
+    const pullRequest = context.payload.pull_request;
+    const owner = pullRequest.base.repo.owner.login;
+    const repo = pullRequest.base.repo.name;
+    const pullNumber = pullRequest.number;
+
+    const { data: labels } = await octokit.rest.issues.listLabelsOnIssue({
+      owner,
+      repo,
+      issue_number: pullNumber,
+    });
+
+    const labelNames = labels.map((label) => label.name);
+
+    const requiredLabels = [
+      ['Type:Easy', 'Type:Medium', 'Type:Hard'],
+      ['Semver:major', 'Semver:minor', 'Semver:patch'],
+      ['PR:Accept'],
+    ];
+
+    const hasRequiredLabels = requiredLabels.every((labelGroup) =>
+      labelGroup.some((label) => labelNames.includes(label))
+    );
+
+    if (!hasRequiredLabels) {
+      setFailed(
+        'This pull request must have at least one label from each of the following groups: Type (Easy, Medium, Hard), Semver (Major, Minor, Patch), and PR:Accept.'
+      );
+    }
+  } catch (error) {
+    setFailed(error.message);
+  }
+}
+
+run();