Update support md

CODE_OF_CONDUCT.md

@@ -1,5 +1,5 @@
 <!--
-SPDX-FileCopyrightText: 2017-2021 Alliander N.V. <openstef@lfenergy.org>
+SPDX-FileCopyrightText: 2026 Contributors to the OpenSTEF project <openstef@lfenergy.org>
 
 SPDX-License-Identifier: MPL-2.0
 -->

CONTRIBUTING.md

@@ -1,5 +1,5 @@
 <!--
-SPDX-FileCopyrightText: 2017-2021 Alliander N.V. <openstef@lfenergy.org>
+SPDX-FileCopyrightText: 2026 Contributors to the OpenSTEF project <openstef@lfenergy.org>
 
 SPDX-License-Identifier: MPL-2.0
 -->
@@ -12,36 +12,36 @@ just a few small guidelines you need to follow before making a change.
 
 ## Filing bugs and change requests
 
-You can file bugs against and change request for the project via github issues. Consult [GitHub Help](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/creating-an-issue) for more
-information on using github issues.
+You can file bugs against and change requests for the project via GitHub issues. Consult [GitHub Help](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/creating-an-issue) for more
+information on using GitHub issues.
+
+For more information on how to get help, report bugs, or suggest features, please refer to [SUPPORT.md](./SUPPORT.md).
 
 ## Community Guidelines
 
 This project follows the following [Code of Conduct](https://github.com/OpenSTEF/.github/blob/main/CODE_OF_CONDUCT.md).
 
 ## Style guide
 
-This project uses the PEP 8 Style Guide for Python Code. For all details about the various conventions please refer to:
-
-[PEP 8](https://www.python.org/dev/peps/pep-0008)
-
-Tip: Use autopep8 to automatically format your Python code to conform to the PEP 8 style guide.
+This project follows [PEP 8](https://peps.python.org/pep-0008/) as enforced by [Ruff](https://docs.astral.sh/ruff/). For the full style guide, including naming conventions, type hints, documentation standards, and more, please refer to the [OpenSTEF Code Style Guide](https://openstef.github.io/openstef/contribute/code_style_guide.html).
 
-Furthermore the following conventions apply:
+Key formatting rules:
 
 * Maximum line length: 88 characters
-* Double quotes for strings, keys etc.
-    * Except when double quotes in the middle of a string are required.
+* Indentation: 4 spaces (no tabs)
+* Double quotes for strings
+* Trailing commas required in multi-line constructs
+* Import sorting: alphabetical within sections
+
+Most style issues are automatically handled by our development tools. Run `poe all` to fix formatting and catch style violations automatically.
 
 ## Git branching
 
 This project uses the [GitHub flow Workflow](https://guides.github.com/introduction/flow/) and branching model. The `main` branch always contains the latest release. New feature branches are branched from `main`. When a feature is finished it is merged back into `main` via a [Pull Request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#:~:text=Pull%20requests%20let%20you%20tell,merged%20into%20the%20base%20branch.).
 
-This project also uses [Jira](https://www.atlassian.com/software/jira) for its [Scrum](https://en.wikipedia.org/wiki/Scrum_software_development) planning. In order to connect git branches to Jira it is prefpreferred that the user story `id` (e.g. KTP-753) is added to the branch name.
-
-The following convention will be used for feature branches: 'Feature [jiraticketnumber] [descripttion]' or 'Feature [name feature]' when no Jiraticketnumber is avialable.  So for example:  `Feature ktp 753 unittest all schedulers` or `Feature unittest all schedulers`.
+The following convention will be used for feature branches: `feature/description`. For example: `feature/unittest-all-schedulers`.
 
-The following convention will be used for bugfix branches: 'Bugfix [jiraticketnumber] [descripttion]' or 'Bugfix [name feature]' when no Jiraticketnumber is avialable.  So for example:  `Bugfix ktp 1425 use training days` or `Bugfix use training days`.
+The following convention will be used for bugfix branches: `bugfix/description`. For example: `bugfix/use-training-days`.
 
 ## Signing the Developer Certificate of Origin (DCO)
 This project utilize a Developer Certificate of Origin (DCO) to ensure that each commit was written by the author or that the author has the appropriate rights necessary to contribute the change. Specifically, we utilize [Developer Certificate of Origin, Version 1.1](http://developercertificate.org/),  which is the same mechanism that the Linux® Kernel and many other communities use to manage code contributions. The DCO is considered one of the simplest tools for sign-offs from contributors as the representations are meant to be easy to read and indicating signoff is done as a part of the commit message.
@@ -58,6 +58,16 @@ There are other great tools out there to manage DCO signoffs for developers to m
 * Additionally, it is possible to use shell scripting to automatically apply the sign-off. For an example for bash to be put into a `.bashrc` file, see [the documentation provided by LF Energy](https://wiki.lfenergy.org/display/HOME/Contribution+and+Compliance+Guidelines#ContributionandComplianceGuidelines-Contributionsignoff). 
 * Alternatively, you can add `prepare-commit-msg hook` in .git/hooks directory. For an example, see [here](https://github.com/Samsung/ONE-vscode/wiki/ONE-vscode-Developer's-Certificate-of-Origin).
 
+## Testing policy
+
+All major new functionality **must** be accompanied by tests added to the automated test suite. This ensures that new features work as expected and prevents regressions in future changes. Bug fixes should also include a test that reproduces the issue and verifies the fix.
+
+Tests are run automatically via `poe tests`. All tests must pass before a pull request can be merged. For details on test naming conventions and structure, see the [OpenSTEF Code Style Guide](https://openstef.github.io/openstef/contribute/code_style_guide.html).
+
+## Warning flags
+
+This project enforces maximally strict warnings. All linting warnings from [Ruff](https://docs.astral.sh/ruff/) and type checking warnings from [Pyright](https://github.com/microsoft/pyright) must be resolved before merging. Run `poe all --check` to verify there are no outstanding warnings.
+
 ## Code reviews
 
 All patches and contributions, including patches and contributions by project members, require review by one of the maintainers of the project. We
@@ -71,8 +81,8 @@ Contributions should be submitted as Github pull requests. See [Creating a pull
 The process for a code change and pull request you should follow:
 
 1. Create a topic branch in your local repository, following the naming format
-"feature-KTP-###". For more information see the Git branching guideline.
-1. Make changes, compile, and test thoroughly. Ensure any install or build dependencies are removed before the end of the layer when doing a build. Code style should match existing style and conventions, and changes should be focused on the topic the pull request will be addressed. For more information see the style guide.
+`feature/description` or `bugfix/description`. For more information see the Git branching guideline.
+1. Make changes, compile, and test thoroughly. Major new functionality **must** include tests in the automated test suite. Ensure any install or build dependencies are removed before the end of the layer when doing a build. Code style should match existing style and conventions, and changes should be focused on the topic the pull request will be addressed. For more information see the style guide.
 1. Push commits to your fork.
 1. Create a Github pull request from your topic branch.
 1. Signing the Developer Certificate of Origin (DCO)
@@ -86,6 +96,10 @@ Every new Pull Request merged to main triggers a new automatic github release wi
 1. Major (**1**.0.0) or minor (0.**1**.0) version need to be bumped besides patch version: do this yourself in the feature branch in the setup.py.
 2. Pre-release needs to be made: do this yourself in the feature branch with new pre-release version in setup.py and manual pre-release in github GUI.
 
+## How to report a security vulnerability
+
+Please refer to [SECURITY.md](./SECURITY.md) for details on reporting a security vulnerability.
+
 ## Attribution
 
 This Contributing.md is adapted from Google

PROJECT_GOVERNANCE.md

@@ -1,5 +1,5 @@
 <!--
-SPDX-FileCopyrightText: 2017-2021 Contributors to the OpenSTF project <openstef@lfenergy.org>
+SPDX-FileCopyrightText: 2026 Contributors to the OpenSTEF project <openstef@lfenergy.org>
 
 SPDX-License-Identifier: MPL-2.0
 -->

SUPPORT.md

@@ -1,34 +1,36 @@
 <!--
-SPDX-FileCopyrightText: 2017-2024 Alliander N.V. <openstef@lfenergy.org>
+SPDX-FileCopyrightText: 2026 Contributors to the OpenSTEF project <openstef@lfenergy.org>
 
 SPDX-License-Identifier: MPL-2.0
 -->
-# Getting help
+
+# Getting Help
 
 There are a few ways to connect with the OpenSTEF project:
 
 * Join the **#openstef Slack channel**, which is part of the [LF Energy Slack workspace](https://slack.lfenergy.org/).
   * Depending on your work e-mail address, you may need to be invited in order to join the Slack workspace. If this is the case, please e-mail <openstef@lfenergy.org>. We are happy to invite you.
-* Send a **direct message** to one of the most recent [contributors](https://github.com/OpenSTEF/openstef/graphs/contributors).
-* Submit an [**issue**](https://github.com/OpenSTEF/openstef/issues).
+* Submit an [**issue**](https://github.com/OpenSTEF/openstef/issues) in the individual repository.
 * Join the four-weekly **community meeting**. You can find information, including meeting invite links, on [our wiki page](https://wiki.lfenergy.org/display/OS/Four-weekly+community+meeting).
 
-## How to ask for help
+## How to ask for help, suggest a feature, or give recommendations
+
+If you have trouble installing, building, or using OpenSTEF,
+but there's not yet reason to suspect you've encountered a genuine bug,
+start by posting a question to the **#openstef Slack channel**.
 
-If you have trouble installing, building, or using OpenSTEF, but there's no reason yet to suspect you have encountered a genuine bug,
-start by posting a question to the **Slack channel**.
-This is the place for question such has "How do I...".
+If you have an idea for a new feature or some recommendations for existing features or documentation,
+you can also propose it in the **Slack channel** or submit an [issue](https://github.com/OpenSTEF/openstef/issues).
 
-## How to report a bug or request an enhancement
+## How to report a bug
 
-This project manages bug and enhancement using the [GitHub issue tracker](https://github.com/OpenSTEF/openstef/issues).
-The issue template will guide you on making an effective report.
+This project manages bug and enhancement using the GitHub issue tracker.
+The various issue templates will guide you on making an effective report.
 
 ## How to report a security vulnerability
 
-If you think you have found a potential vulnerability in this project,
-please e-mail <openstef@lfenergy.org> to responsibly disclose it.
+Please refer to [SECURITY.md](./SECURITY.md) for details on reporting a security vulnerability.
 
 ## Contributing a fix
 
-Please refer to [CONTRIBUTING.md](CONTRIBUTING.md) to make a project contribution.
+Please refer to [CONTRIBUTING.md](./CONTRIBUTING.md) to make a project contribution.

profile/README.md

@@ -1,3 +1,9 @@
+<!--
+SPDX-FileCopyrightText: 2026 Contributors to the OpenSTEF project <openstef@lfenergy.org>
+
+SPDX-License-Identifier: MPL-2.0
+-->
+
 # OpenSTEF - Open Short Term Energy Forecasting
 [![License: MPL2.0](https://img.shields.io/badge/License-MPL2.0-informational.svg)](https://github.com/openstef/openstef/blob/main/LICENSE)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/5585/badge)](https://bestpractices.coreinfrastructure.org/projects/5585)
@@ -19,15 +25,15 @@ OpenSTEF provides automated machine learning pipelines to deliver accurate and e
 - [Python package](https://pypi.org/project/openstef/);
 - [Project website](https://www.lfenergy.org/projects/openstef/);
 - [Dashboard documentation](https://raw.githack.com/OpenSTEF/.github/main/profile/html/openstef_dashboard_doc.html);
-- [Linux Foundation project page](https://openstef.github.io/openstef/index.html);
+- [Linux Foundation project page](https://www.lfenergy.org/projects/openstef/);
 - [Video about OpenSTEF](https://www.lfenergy.org/forecasting-to-create-a-more-resilient-optimized-grid/);
-- [OpenSTEF Slack channel](https://app.slack.com/huddle/TLU68MTML/C04P56MSM40). 
+- [OpenSTEF Slack channel](https://slack.lfenergy.org/). 
 
 
 ## Description
 The energy transition poses new challenges to all parties within the energy sector. Grid operators, grappling with the upsurge in renewable energy and heightened electrification, find their grid capacities nearing physical limitations. Therefore, it is imperative to forecast grid load in the upcoming hours to days, enabling the anticipation of local congestion and thereby optimal utilization of existing assets.  
 
-OpenSTEF provides a complete software stack specifically engineered to forecast the load on the electricity grid for the next hours to days. Given a timeseries of measured (net) load or generation, a fully automated machine learning pipeline is executed which delivers a probabilistic forecast of future load. This is applicable to energy consumption, renewable generation, or a combination of the two. OpenSTEF does not stop at forecating: it validates input data, combines measurements with external predictors such as weather data and market prices, trains any scikit-learn compatible machine learning model, and delivers the forecast via both an API and an (expert) graphical user interface. The entire stack, crafted on open-source technology and adhering to standards, is organized in a microservice architecture optimized for cloud-deployment.
+OpenSTEF provides a complete software stack specifically engineered to forecast the load on the electricity grid for the next hours to days. Given a timeseries of measured (net) load or generation, a fully automated machine learning pipeline is executed which delivers a probabilistic forecast of future load. This is applicable to energy consumption, renewable generation, or a combination of the two. OpenSTEF does not stop at forecasting: it validates input data, combines measurements with external predictors such as weather data and market prices, trains any scikit-learn compatible machine learning model, and delivers the forecast via both an API and an (expert) graphical user interface. The entire stack, crafted on open-source technology and adhering to standards, is organized in a microservice architecture optimized for cloud-deployment.
 
 The Dutch DSO Alliander started the Short-Term-Forecasting project to anticipate congestion in the distribution grid, to allow for grid safety analysis in the transmission grid and to enable smart grid innovations to locally balance supply and demand within the constraints of the grid. The objective of opensourcing the stack is two-fold: provide an industry standard for generating and evaluating forecasts in the operational time-domain, as well as allow for structured collaboration.
 ![Forecast highligts](https://user-images.githubusercontent.com/18208480/127109029-77e09c97-8d06-4158-8789-4c1d5ecede61.png "Example of the OpenSTEF dashboard")
@@ -40,7 +46,7 @@ OpenSTEF has different repositories.
 
 [OpenSTEF-reference](https://github.com/OpenSTEF/openstef-reference): Deploy the entire OpenSTEF stack on your machine. Provides a reference implementation of the OpenSTEF stack including datamodels, databases and UI.  
 
-[OpenSTEF-offline-example](https://github.com/OpenSTEF/openstef-offline-example): Provides Jupyter Notebooks showing how to use OpenSTEF and apply it's functionality to your usecase.
+[OpenSTEF-offline-example](https://github.com/OpenSTEF/openstef-offline-example): Provides Jupyter Notebooks showing how to use OpenSTEF and apply its functionality to your usecase.
 
 ## Framework features 
 - Prediction job: input configuration for a task or pipeline. It contains for example the location and forecasting horizon.
@@ -55,7 +61,7 @@ OpenSTEF has different repositories.
 This project is licensed under the Mozilla Public License, version 2.0.
 
 ## Contributing
-Please read [CODE_OF_CONDUCT.md](https://github.com/OpenSTEF/.github/blob/main/CODE_OF_CONDUCT.md), [CONTRIBUTING.md](https://github.com/OpenSTEF/.github/blob/main/CONTRIBUTING.md) and [PROJECT_GOVERNANACE.md](https://github.com/OpenSTEF/.github/blob/main/PROJECT_GOVERNANCE.md) for details on the process for submitting pull requests to us.
+Please read [CODE_OF_CONDUCT.md](https://github.com/OpenSTEF/.github/blob/main/CODE_OF_CONDUCT.md), [CONTRIBUTING.md](https://github.com/OpenSTEF/.github/blob/main/CONTRIBUTING.md) and [PROJECT_GOVERNANCE.md](https://github.com/OpenSTEF/.github/blob/main/PROJECT_GOVERNANCE.md) for details on the process for submitting pull requests to us.
 
 ## Contact
 Please read [SUPPORT.md](https://github.com/OpenSTEF/.github/blob/main/SUPPORT.md) for how to connect and get into contact with the OpenSTEF project