Add new pull request template

.github/pull_request_template.md

@@ -1,29 +1,67 @@
 ## Summary
 
-> Developers should provide a summary of the proposed changes here and include "closes #<ISSUE NUMBER>" if this addresses an open issue.
+> Provide a concise description of the proposed changes.  
+> Include "closes #<ISSUE_NUMBER>" if this addresses an open issue <br>
+> **Note:** Validation tests and plots should **not** be added to the PR; they should be documented in the dedicated issue instead.
 
-## Validation Test Reports
 
-> Developers should include training and metrics validation test reports demonstrating that all tests passed.
+## What’s changed
+
+> Describe the main changes introduced by this PR.  
+> Focus on user-visible changes, bug fixes, performance improvements, or internal changes.
+
+- Example bullet 1
+- Example bullet 2
+
+
+## How to test / verify
+
+> Outline steps for reviewers or maintainers to validate the changes.  
+> Include commands, scripts, or datasets if relevant.  
+> Full validation results should be referenced in the associated issue, not pasted here.
+
+- Step 1
+- Step 2
+
+
+## Scope
+
+> Indicate the type of PR:
+
+- [ ] Feature  
+- [ ] Bug fix  
+- [ ] Hotfix  
+- [ ] Documentation / process change  
+- [ ] Internal / refactor  
+
+> Optionally, note if this PR is part of a larger milestone or set of related PRs.
+
+
+## Changelog
+
+> Did this PR introduce user-visible changes?  
+> If yes, a **Scriv changelog fragment** must be added and committed.
+
+- [ ] Changelog fragment added (if applicable)
 
-(Copy and paste the output of validation tests report here in markdown.)
 
 ## Reviewer Checklist
 
-> Reviewers should tick the following boxes before approving and merging the PR.
+> Reviewers should confirm the following before approving and merging:
 
 - [ ] The PR targets the `develop` branch
 - [ ] The PR is assigned to the developer
-- [ ] The PR has appropriate labels
-- [ ] The PR is included in appropriate projects and/or milestones
-- [ ] The PR includes a clear description of the proposed changes
-- [ ] If the PR addresses an open issue the description includes "closes #<ISSUE NUMBER>"
-- [ ] The code and documentation style match the current standards
-- [ ] Documentation has been added/updated consistently with the code
-- [ ] All CI tests are passing
-- [ ] API docs have been built and checked at least once (if relevant)
-- [ ] All changed files have been checked and comments provided to the developer
-- [ ] All of the reviewer's comments have been satisfactorily addressed by the developer
-- [ ] All Validation tests for the reported error are passing
-- [ ] Changelog fragment added (if applicable)
-- [ ] I have reviewed the CI log to verify if any files require formatting with Black. If any files are found to be improperly formatted, I have provided comments indicating the need for formatting.
+- [ ] Appropriate labels are applied
+- [ ] The PR is included in relevant projects and/or milestones
+- [ ] Description clearly explains what has changed
+- [ ] Issue references included, if applicable
+- [ ] Code and documentation adhere to current standards (`ruff`)
+- [ ] Documentation updates included, if relevant
+- [ ] CI tests are passing
+- [ ] All reviewer comments have been addressed
+
+
+## Next Steps / Notes (if applicable)
+
+> Any follow-up actions, known issues, or reminders for maintainers.
+

docs/source/configuration.md

@@ -71,7 +71,6 @@ data:
 
 Controls the training pipeline, including model selection, hyperparameters, optional metrics evaluation, and data loading behavior.
 
----
 
 ### 2. General Notes
 
@@ -210,11 +209,11 @@ training_hparams:
     n_epochs_non_params: [100, 120]
 ```
 
+
 (metrics_config)=
 ## `metrics_config.yaml`  — Metrics Configuration
 
 ### 1. Purpose
-
 Defines how a trained PSF model is evaluated. This configuration specifies which metrics to compute, which model weights to use, and how ground truth stars are obtained. It allows you to:
 - Select a fully trained PSF model or a checkpoint for evaluation.
 - Specify which training cycle’s weights to evaluate.
@@ -439,14 +438,12 @@ This configuration instructs the plotting pipeline to load the metrics from each
 ## Master Configuration
 
 ### 1. Purpose
-
 The `configs.yaml` file is the _master controller_ for WaveDiff.
 It defines **which pipeline tasks** should be executed (training, metrics evaluation, plotting) and in which order.
 
 Each task points to a dedicated YAML configuration file—allowing WaveDiff to run multiple jobs sequentially using a single entry point.
 
 ### 2. Example: Multiple Training Runs
-
 To launch a sequence of training runs (models 1…n), list each task and its corresponding configuration file:
 
 ```yaml
@@ -482,6 +479,7 @@ wf-outputs-20231119151932213823/
 
 To evaluate metrics and generate plots for each trained model, include the corresponding configuration files:
 
+
 ```
 config/
 ├── configs.yaml