Merge remote-tracking branch 'origin/main' into vin/-/mytimeline-refa…

…ctor

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -4,7 +4,7 @@ Resolves #
 
 - [x] The PR title is of form 'issue_title #issue_number'
 - [x] If no issue is referenced, my changes are simple and summarized in title - and in max three sentences in the description.  
-      If not please make an issue - so need for change is validated.
+       If not please make an issue - so need for change is validated.
 - [x] I'll be patient as I understand responses can take days.
 - [x] I have formatted according to project guidelines.
 - [x] I have not introduced any new failing lints or tests.

.github/workflows/playwright.yml

@@ -12,15 +12,15 @@ jobs:
       - uses: actions/checkout@v4
       - uses: actions/setup-node@v4
         with:
-          node-version: 18
+          node-version: lts/*
       - name: Install dependencies
         run: npm ci
       - name: Install Playwright Browsers
         run: npx playwright install --with-deps
       - name: Run Playwright tests
         run: npx playwright test
       - uses: actions/upload-artifact@v4
-        if: always()
+        if: ${{ !cancelled() }}
         with:
           name: playwright-report
           path: playwright-report/

SECURITY.md

@@ -0,0 +1,17 @@
+# Security Policy
+
+## Supported Versions
+
+Use this section to tell people about which versions of your project are
+currently being supported with security updates.
+
+| Version | Supported          |
+| ------- | ------------------ |
+| latest  | :white_check_mark: |
+
+## Reporting a Vulnerability
+
+1. Anonymous on https://zinzen.vercel.app/Feedback
+2. Email [email protected]
+3. DM via Signal: ZinZen.01
+4. DM via Matrix: @tijlleenders:matrix.org

documentation/technical/PRGuide.md

@@ -9,37 +9,26 @@ Follow these simple steps to propose changes or fixes to ZinZen:
 ### Keep Your Repositories in Sync
 
 1. Before starting any work, make sure your local project matches ZinZen's latest version:
-    - Switch to your local project's main branch:
-
-        `git checkout main`
-
-    - Get the latest changes from ZinZen's repository (without merging them into your main branch):
-
-        `git fetch upstream`
-
-    - Merge these changes into your main branch:
-
-        `git merge upstream/main`
-
-    - Update your GitHub repository (origin) with these changes:
-
-        `git push origin main`
-
+   - Switch to your local project's main branch:
+     `git checkout main`
+   - Get the latest changes from ZinZen's repository (without merging them into your main branch):
+     `git fetch upstream`
+   - Merge these changes into your main branch:
+     `git merge upstream/main`
+   - Update your GitHub repository (origin) with these changes:
+     `git push origin main`
 
 ### Setup a feature branch
 
-1. Make a new branch in your local project for your fixes or features (called a "feature branch"). 
+1. Make a new branch in your local project for your fixes or features (called a "feature branch").
 2. Follow [branch naming conventions](./conventions/git.md):
 
    `[developer shortcut]/[issue number]/[meaningful name]`
-    - To create and switch to a new branch locally:
-
-        `git checkout -b vin/01/my-fix-branch`
-
-    - Push this branch to your GitHub repository:
-
-        `git push origin vin/01/my-fix-branch`
-
+
+   - To create and switch to a new branch locally:
+     `git checkout -b vin/01/my-fix-branch`
+   - Push this branch to your GitHub repository:
+     `git push origin vin/01/my-fix-branch`
 
 ### Work on Your Changes
 
@@ -87,19 +76,13 @@ ZinZen's main branch must always be error-free. Pull requests that fail tests or
 If your pull request receives feedback, make more commits to your branch and push them to your GitHub repository. They'll be added to the pull request automatically. Follow these steps:
 
 1. Update your local repository:
-    - Switch to the correct branch:
-
-        `git checkout vin/01/my-fix-branch`
-
-    - Get changes from ZinZen:
-
-        `git pull --rebase upstream main`
-
-    - Make the required changes in your branch.
-    - Once satisfied, push them to your GitHub repository to update your pull request:
-
-        `git push origin vin/01/my-fix-branch`
-
+   - Switch to the correct branch:
+     `git checkout vin/01/my-fix-branch`
+   - Get changes from ZinZen:
+     `git pull --rebase upstream main`
+   - Make the required changes in your branch.
+   - Once satisfied, push them to your GitHub repository to update your pull request:
+     `git push origin vin/01/my-fix-branch`
 
 Repeat this process until your changes are accepted and merged.
 

documentation/technical/Setup.md

@@ -9,10 +9,12 @@ The steps outlined in this section are a one-time process necessary for contribu
 Here's how to establish and maintain a fork of ZinZen and make periodic contributions:
 
 1. **Fork ZinZen:**
+
    - To begin, create a fork of the [ZinZen repository](https://github.com/tijlleenders/ZinZen) on GitHub.
    - Click the "Fork" button and choose a suitable GitHub account, such as your personal GitHub account, for the fork.
 
 2. **Clone Your Fork:**
+
    - Access your GitHub account and go to your Fork of ZinZen.
    - Click on the "<> Code" tab located in the upper left corner.
    - Within the dropdown menu that appears, select "HTTPS" (you can choose SSH if preferred, but this tutorial uses HTTPS for simplicity).

documentation/technical/conventions/Readme.md

@@ -1,14 +1,17 @@
 # Getting Started
+
 Before you start contributing to the ZinZen project, it's important to familiarize yourself with our conventions and workflows. This ensures a smooth and consistent development process for everyone involved.
 
 ### Code Conventions
+
 Our [Code Conventions](code.md) document outlines the coding standards, naming conventions, and best practices for maintaining code quality and readability. It's crucial to adhere to these guidelines to ensure consistency across the codebase.
 
 ### Git Conventions
+
 The [Git Conventions](git.md) document provides detailed instructions on the commit process, branching strategy, and pull request guidelines. Following these conventions is essential for efficient collaboration and code integration.
 
 ## Contributing
+
 We welcome contributions from everyone! Please read our contributing guidelines to understand how you can contribute effectively. If you have any questions, feel free to open an issue for discussion.
 
 Thank you for being a part of the ZinZen project!
-

documentation/technical/conventions/code.md

@@ -3,6 +3,7 @@
 This document provides a set of coding standards and best practices for contributing to the ZinZen project. It aims to ensure consistency, readability, and maintainability of the codebase.
 
 ### Naming Conventions
+
 Proper naming enhances code readability:
 
 - **General:** Use clear, descriptive names.
@@ -15,13 +16,15 @@ Proper naming enhances code readability:
 - **Type Names:** Use PascalCase (e.g., `User`).
 
 ### TypeScript Practices
+
 Follow these TypeScript-specific practices:
 
 - **Type Annotations:** Always use type annotations.
 - **Interfaces and Types:** Use interfaces for objects and types for unions.
 - **Avoid `any`:** Minimize the use of `any` for better type checking.
 
 ### Code Quality and Robustness
+
 To ensure the reliability and maintainability of the code:
 
 - **Simplicity:** Write simple and clear code.

documentation/technical/conventions/git.md

@@ -3,15 +3,18 @@
 Before merging code into the main branch, it undergoes a thorough peer review to ensure quality and readiness for deployment. Your code submissions should be crafted for clarity and ease of review.
 
 ## Committing Process
+
 - **Small Commits:** Make commits small and logical, easy to understand and follow.
 - **Review Before Committing:** Before committing, review each file for temporary or test code, warnings, formatting issues, and unnecessary packages.
 - **Frequent Commits:** Commit often to track progress and create a transparent history of your work.
 - **Early Pull Requests:** Make PRs as soon as possible to integrate changes quickly and reduce conflicts.
 
 ## Before Pushing Your Code
+
 - **No Warnings:** Ensure there are no warnings in your code. The development and main branches should be free of warnings to make it easier to spot new issues introduced by recent code changes.
 
 ## Branching Convention
+
 - **Naming Format:** Use the format `[developer shortcut]/[issue number]/[meaningful name]`, like `alice/411/fix-budgets-on-weekends`.
 - **Developer Specific:** Branches should be developed by the assigned developer only to maintain clarity in the development process.
 - **Merging and Deletion:** Once finished, branches should be merged into the main branch after PR review and then deleted.