Merge pull request #7 from IntersectMBO/qa

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,6 @@
+blank_issues_enabled: true
+contact_links:
+
+  - name: Consider creating issue via GovTool repository
+    url: https://github.com/IntersectMBO/govtool/issues/new/choose
+    about: To ensure issues are all in one place please make your issue via the GovTool wrapper repository.

.github/pull_request_template.md

@@ -0,0 +1,12 @@
+## List of changes
+
+- Add / Fix / Change / Remove
+
+## Checklist
+
+- [related issue](https://github.com/IntersectMBO/govtool/issues/)
+- [ ] My changes generate no new warnings
+- [ ] My code follows the [style guidelines](https://github.com/IntersectMBO/govtool/tree/main/docs/style-guides) of this project
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the [changelog](https://github.com/IntersectMBO/govtool-voting-pillar/blob/main/CHANGELOG.md)
+- [ ] I have added tests that prove my fix is effective or that my feature works

CODEOWNERS

@@ -1,4 +1,4 @@
-# GovTool Proposal Discussion Backend Project Codeowners
+# GovTool Proposal Pillar Project Codeowners
 
 # These owners will be the default owners for everything in the repository.
-
+* @vpaunovic @teske00

CONTRIBUTING.md

@@ -1,192 +1,5 @@
-# Contributing to the `GovTool Proposal Discussion Backend` project
+# Contributing to the `GovTool` project
 
-Thanks for considering contributing and helping us on creating GovTool Proposal Discussion Backend! 😎
+Thanks for considering contributing and helping us on creating GovTool! 😎
 
-The best way to contribute right now is to try things out and provide feedback, but we also accept contributions to the documentation and the obviously to the code itself.
-
-This document contains guidelines to help you get started and how to make sure your contribution gets accepted, making you our newest GovTool Proposal Discussion Backend contributor!
-
-## Table of Contents
-
-- [Contributing to the `GovTool Proposal Discussion Backend` project](#contributing-to-the-govtool-proposal-discussion-backend-project)
-  - [Table of Contents](#table-of-contents)
-  - [Code of Conduct](#code-of-conduct)
-  - [Ask for Help](#ask-for-help)
-  - [Roles and Responsibilities](#roles-and-responsibilities)
-  - [I Want To Contribute](#i-want-to-contribute)
-      - [Before Submitting a Bug Report](#before-submitting-a-bug-report)
-      - [How Do I Submit a Good Bug Report?](#how-do-i-submit-a-good-bug-report)
-      - [Your First Code Contribution](#your-first-code-contribution)
-  - [Working Conventions](#working-conventions)
-    - [Pull Requests](#pull-requests)
-    - [Branch Naming](#branch-naming)
-    - [Commit Messages](#commit-messages)
-      - [Rationale](#rationale)
-    - [Merge Commit PRs and Rebase Branches on top of Main](#merge-commit-prs-and-rebase-branches-on-top-of-main)
-      - [Rationale](#rationale-1)
-    - [Versioning](#versioning)
-    - [Changelog](#changelog)
-    - [Style Guides](#style-guides)
-      - [React](#react)
-      - [CSS in Javascript](#css-in-javascript)
-      - [CSS / SASS](#css--sass)
-
-## Code of Conduct
-
-This project and everyone participating in it is governed by the [Code of Conduct](./CODE-OF-CONDUCT.md).
-By participating, you are expected to uphold this code.
-
-## Ask for Help
-
-See [`SUPPORT.md`](./SUPPORT.md) should you have any questions or need some help in getting set up.
-
-## Roles and Responsibilities
-
-We maintain a [CODEOWNERS file](./CODEOWNERS) which provides information who should review a contributing PR.
-Note that you might need to get approvals from all code owners (even though GitHub doesn't give a way to enforce it).
-
-## I Want To Contribute
-
-#### Before Submitting a Bug Report
-
-A good bug report shouldn't leave others needing to chase you up for more information.
-Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report.
-Please complete the following steps in advance to help us fix any potential bug as fast as possible.
-
-- Make sure that you are using the latest version.
-- Determine if your bug is really a bug and not an error on your side.
-  e.g. using incompatible environment components/versions.
-  If you are looking for support, you might want to check [this section](#i-have-a-question).
-- To see if other users have experienced (and potentially already solved) the same issue you are having.
-- Also make sure to search the internet (including Stack Overflow)
-  to see if users outside of the GitHub community have discussed the issue.
-- Collect information about the bug:
-  - Stack trace (Traceback)
-  - OS, Platform and Version (Windows, Linux, macOS, x86, ARM)
-  - Version of the interpreter, compiler, SDK, runtime environment, package manager, depending on what seems relevant.
-  - Possibly your input and the output
-  - Can you reliably reproduce the issue? And can you also reproduce it with older versions?
-
-#### How Do I Submit a Good Bug Report?
-
-We use GitHub issues to track bugs and errors. If you run into an issue with the project:
-
-- Open an [Issue](https://github.com/IntersectMBO/GovTool Proposal Discussion Backend/issues/new).
-  (Since we can't be sure at this point whether it is a bug or not, we ask you not to talk about a bug yet and not to label the issue.)
-- Explain the behavior you would expect and the actual behavior.
-- Please provide as much context as possible.
-  Describe the *reproduction steps* that someone else can follow to recreate the issue on their own.
-  This usually includes your code.
-  For good bug reports you should isolate the problem and create a reduced test case.
-- Provide the information you collected in the previous section.
-
-Once it's filed:
-
-- The project team will label the issue accordingly.
-- A team member will try to reproduce the issue with your provided steps.
-  If there are no reproduction steps or no obvious way to reproduce the issue, the team will ask you for those steps.
-  The issue would then be marked as `needs-repro`.
-  Bugs with the `needs-repro` tag will not be addressed until they are reproduced.
-- If the team is able to reproduce the issue, it will be marked `needs-fix`.
-  It may possibly be marked with other tags (such as `critical`).
-  The issue will then be left to be [implemented by someone](#your-first-code-contribution).
-
-#### Your First Code Contribution
-
-TODO
-
-## Working Conventions
-
-### Pull Requests
-
-Thank you for contributing your changes by opening a pull requests!
-
-To get something merged we usually require:
-- Follow the Pull Request template
-- Description of the changes - if your commit messages are great, this is less important
-- Quality of changes is ensured - through new or updated automated tests
-- Change is related to an issue, feature (idea) or bug report - ideally discussed beforehand
-- Well-scoped - we prefer multiple PRs, rather than a big one
-- Add changes to changelog, see [Changelog](#changelog).
-
-Please reuse the branch naming for the pull request naming.
-
-### Branch Naming
-
-- When creating your branches please create informative names.
-- Using prefixes such as `feat/`, `fix/`, `chore/`, `docs/` for branch names are a good start.
-- Using the related issue number after the prefix is required.
-
-Examples:
-- `feat/123-added-ability-for-dreps-to-change-drep-id`
-- `fix/312-fixed-drep-ids-being-reversed`
-- `chore/567-bumped-cardano-node-version-to-9`
-- `docs/88-tweak-contributing-pr-template-codeowners`
-
-### Commit Messages
-
-Please make informative commit messages! 
-It makes it much easier to work out why things are the way they are when you’re debugging things later.
-
-A commit message is communication, so as usual, put yourself in the position of the reader: what does a reviewer, or someone reading the commit message later need to do their job?
-Write it down!
-It is even better to include this information in the code itself, but sometimes it doesn’t belong there (e.g. ticket info).
-
-Also, include any relevant meta-information, such as issue numbers.
-If a commit completely addresses a issue, you can put that in the headline if you want, but it’s fine to just put it in the body.
-
-Here are seven rules for great git commit messages:
-1. Separate subject from body with a blank line
-2. Limit the subject line to 50 characters (soft limit)
-3. Capitalize the subject line
-4. Do not end the subject line with a period
-5. Use the imperative mood in the subject line and suffix with ticket number if applicable
-6. Wrap the body at 72 characters (hard limit)
-7. Use the body to explain what and why vs. how
-
-There is plenty to say on this topic, but broadly the guidelines in [this post](https://cbea.ms/git-commit/) are good.
-
-#### Rationale
-
-Git commit messages are our only source of why something was changed the way it was changed.
-So we better make the readable, concise and detailed (when required).
-
-### Merge Commit PRs and Rebase Branches on top of Main
-
-When closing branches / PRs use merge commits, so we have a history of PRs also in the git history.
-Do not merge main into side branches, instead rebase them on top of main.
-Try to keep branches up-to-date with main (not strict requirement though).
-Once merged to main, please delete the branch.
-
-**Tip:** Use Github's merge button in PRs to merge with commit.
-If a branch is outdated, use the rebase button in PRs to rebase feature branches (NOT update via merge).
-
-#### Rationale
-
-Keeping branches ahead of main not only make the git history a lot nicer to process, it also makes conflict resolutions easier.
-Merging main into a branch repeatedly is a good recipe to introduce invalid conflict resolutions and loose track of the actual changes brought by a the branch.
-
-### Versioning 
-
-Not all releases are declared stable.
-Releases that aren't stable will be released as pre-releases and will append a -pre tag indicating it is not ready for running on production networks.
-
-### Changelog
-
-During development, on every PR;
-- Make sure `CHANGELOG.md` is kept up-to-date with high-level, technical, but user-focused list of changes according to [keepachangelog](https://keepachangelog.com/en/1.0.0/).
-- Bump `UNRELEASED` version in `CHANGELOG.md` according to [semver](https://semver.org/).
-
-### Style Guides
-
-#### React
-
-Please see [React Style Guide](./docs/style-guides/react/).
-
-#### CSS in Javascript
-
-Please see [CSS in Javascript Style Guide](./docs/style-guides/css-in-js/).
-
-#### CSS / SASS
-
-Please see [CSS / SASS Style Guide](./docs/style-guides/css-sass/).
+Please see [Contributing](https://github.com/IntersectMBO/govtool/blob/main/CONTRIBUTING.md) in GovTool wrapper repository.

README.md

@@ -1,23 +1,26 @@
-# 🚀 PDF (Proposal Discussion Forum)
+# GovTool Proposal Pillar
 
-Welcome to the official repository for the PDF backend.
+This is the repository which holds GovTool's Voting Pillar packages.
+
+For further information and documentation see [GovTool](https://github.com/IntersectMBO/govtool).
 
 ## Table of content:
 
-- [Table of content:](#table-of-content)
-- [Introduction](#introduction)
-- [Prerequisites](#prerequisites)
-- [Tech stack:](#tech-stack)
-  - [pdf-ui package](#pdf-ui-package)
-  - [Backend](#backend)
-  - [Database](#database)
-- [Getting started](#getting-started)
-- [Running locally](#running-locally)
-  - [Backend setup](#backend-setup)
-  - [Database configuration](#database-configuration)
-- [Running using docker compose](#running-using-docker-compose)
-- [Overview of services in docker compose:](#overview-of-services-in-docker-compose)
-- [Additional Information](#additional-information)
+- [GovTool Proposal Pillar](#govtool-proposal-pillar)
+  - [Table of content:](#table-of-content)
+  - [Introduction](#introduction)
+  - [Prerequisites](#prerequisites)
+  - [Tech stack:](#tech-stack)
+    - [pdf-ui package](#pdf-ui-package)
+    - [Backend](#backend)
+    - [Database](#database)
+  - [Getting started](#getting-started)
+  - [Running locally](#running-locally)
+    - [Backend setup](#backend-setup)
+    - [Database configuration](#database-configuration)
+  - [Running using docker compose](#running-using-docker-compose)
+    - [Overview of services in docker compose:](#overview-of-services-in-docker-compose)
+    - [Additional Information](#additional-information)
 
 ## Introduction
 

SECURITY.md

@@ -12,4 +12,4 @@ Please provide a clear and concise description of the vulnerability, including:
 * steps that can be followed to exercise the vulnerability,
 * any workarounds or mitigations
 
-If you have developed any code or utilities that can help demonstrate the suspected vulnerability, please mention them in your email but ***DO NOT*** attempt to include them as attachments as this may cause your Email to be blocked by spam filters.
+If you have developed any code or utilities that can help demonstrate the suspected vulnerability, please mention them in your email but ***DO NOT*** attempt to include them as attachments as this may cause your Email to be blocked by spam filters.

SUPPORT.md

@@ -1,13 +1,13 @@
 # Ask for help
 
-Should you have any questions or need some help in getting set up, you can use these communication channels to reach the GovTool Proposal Discussion Backend team and get answers in a way where others can benefit from it as well:
+Should you have any questions or need some help in getting set up, you can use these communication channels to reach the GovTool team and get answers in a way where others can benefit from it as well:
 
-- Github [Discussions](https://github.com/IntersectMBO/govtool-proposal-dicussion)
+- Github [Discussions](https://github.com/IntersectMBO/govtool/discussions)
 
 # Reporting a Vulnerability
 
 See [`SECURITY.md`](SECURITY.md) on how to report a security vulnerability.
 
 # Contributions
 
-See [`CONTRIBUTING.md`](CONTRIBUTING.md) on how to contribute.
+See [`CONTRIBUTING.md`](CONTRIBUTING.md) on how to contribute.

docs/README.md

@@ -0,0 +1,2 @@
+
+### For docs see [GovTool/docs](https://github.com/IntersectMBO/govtool/tree/main/docs)