chore: update README and add code-conduct and contribution files (dig…

…dir#1012)

Co-authored-by: Michael Marszalek <[email protected]>

.storybook/manager-head.html

@@ -30,11 +30,11 @@
     align-items: center;
     justify-content: space-between;
     width: 100%;
-    padding: 0 33px;
+    padding: 0 32px;
   }
 
   .header__logo {
-    height: 30px;
+    height: 34px;
     width: auto;
   }
 
@@ -164,7 +164,7 @@
         class="header__logo-link"
         ><img
           class="header__logo"
-          src="logo_designsystemet-dark.svg"
+          src="logo_designsystemet.svg"
           alt="Designsystem forside"
       /></a>
     </div>

CODE_OF_CONDUCT.md

@@ -0,0 +1,116 @@
+# Code of Conduct - Designsystemet
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we at the Design System Team
+pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or
+  advances
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate,
+threatening, offensive, or harmful.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will
+communicate reasons for moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at <[email protected]>.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org/), version
+[1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct/code_of_conduct.md) and
+[2.0](https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md),
+and was generated by [contributing-gen](https://github.com/bttger/contributing-gen).

CONTRIBUTING.md

@@ -0,0 +1,228 @@
+# Contributing to Designsystemet
+
+First off, thanks for taking the time to contribute! ❤️
+
+All types of contributions are encouraged and valued. See the [Table of Contents](#table-of-contents) for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉
+
+> And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
+>
+> - Star the project
+> - Refer this project in your project's readme
+> - Mention the project at local meetups and tell your friends/colleagues
+
+## Table of Contents
+
+- [Code of Conduct](#code-of-conduct)
+- [Share your feedback and report issues](#share-your-feedback-and-report-issues)
+- [I Want To Contribute](#i-want-to-contribute)
+  - [Getting involved with development](#getting-involved-with-development)
+  - [Getting started with development](#getting-started-with-development)
+  - [Pull requests](#pull-requests)
+- [Styleguides](#styleguides)
+  - [Commit Messages](#commit-messages)
+  - [How to write and structure your code](#how-to-write-and-structure-your-code)
+- [Publishing NPM packages](#publishing-npm-packages)
+
+---
+
+## Code of Conduct
+
+This project and everyone participating in it is governed by the
+[Designsystemet Code of Conduct](./CODE_OF_CONDUCT.md).
+By participating, you are expected to uphold this code. Please report unacceptable behavior
+to <[email protected]>.
+
+---
+
+## Share your feedback and report issues
+
+You can report bugs and suggest new features by going to our [Github Issue Templates](https://github.com/digdir/designsystem/issues/new/choose).
+
+If you have any questions you can contact us at <[email protected]> or in our [Slack](https://join.slack.com/t/designsystemet/shared_invite/zt-2438eotl3-a4266Vd2IeqMWO8TBw5PrQ) channel.
+
+---
+
+## I Want To Contribute
+
+### Getting involved with development
+
+It's fantastic that you want to join in and help with our development efforts!
+We have established two contribution levels to suit task size: the first level for smaller tasks and the second for larger ones. The main difference is how involved you will be with the Design System Team.
+
+Unsure which level to choose? Send us an email at <[email protected]> and we will get back to you as soon as we can!
+You can also join our [Slack](https://join.slack.com/t/designsystemet/shared_invite/zt-2438eotl3-a4266Vd2IeqMWO8TBw5PrQ) and ask questions there.
+
+We suggest creating a draft pull request as soon as you start working on something. This ensures that different people aren't working on the same task.
+
+Before you start coding also take a look at [how to get started with development](#getting-started-with-development) and our [coding standards](#how-to-write-and-structure-your-code).
+
+#### Addressing minor bugs and handling smaller feature requests
+
+Spotted a bug you would like to help fix? Easy! Just fork this repository and submit a [pull request](#pull-requests).
+A person from the design system team will follow up from there.
+
+Do the same for smaller feature requests. We cannot guarantee that the new feature will be implemented, but we will try our best to make it happen!
+
+#### Developing new components and handling larger tasks
+
+Your team needs a new component that doesn't exist in the the design system and want to help develop it?
+Great news! We have created a process to handle just this use case!
+
+1. Submit a [feature request](https://github.com/digdir/designsystem/issues/new/choose) detailing your requirements, and indicate your interest in contributing to the development of this component.
+2. The design system team will review the feature request and assess its compatibility with the design system.
+3. If the component fits within the scope of the design system we will follow you up from there.
+
+Developing components for the design system requires that developers are closely connected to the design system team. We will invite you to participate in our daily check-ins throughout the development process to ensure that the component adheres to our coding standards and seamlessly integrates with our design system.
+
+### Getting started with development
+
+Follow these steps to get up and running with storybook and the storefront.
+
+Run the commands from the root of your project.
+
+#### 1. Install Node 16+ and Yarn 3
+
+Make sure `node` and `yarn` is installed by running: `node --version && yarn --version`
+
+#### 2. Install dependencies
+
+`yarn install`
+
+This will install all the dependancies.
+
+#### 3. Build packages
+
+`yarn build`
+
+This is required to make sure dependencies between local packages are available. You only need to run this once.
+
+#### 4. Start local development servers
+
+`yarn storybook | storefront`
+
+You can now start developing for storybook and the storefront.
+
+### Pull requests
+
+When creating a pull request for the design system, there are a few things to keep in mind:
+
+- When you create your pull request for the first time make sure to mark it as a [draft](https://github.blog/2019-02-14-introducing-draft-pull-requests/). This is mainly to prevent unnecessary notifications for reviewers during the development process. If you forget then no problem!
+- We utilize automated code checks to verify that pull requests align with our established standards. These checks must be successful for the pull request to be merged into the main branch. You don't need to worry about this during development.
+  - The pull request title must adhere to the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) standard.
+  - We run linting and formatting checks on all the code.
+- When you are done with development you can mark the pull request as ready for review by clicking on the button at the bottom. A person from the design system team will then review your code and comment if there are things that need to be changed. Once the pull request is approved it will be merged into the main branch.
+
+---
+
+## Styleguides
+
+### Commit Messages
+
+This project uses Lerna with the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
+specification in order to generate changelogs.
+
+The [Semantic Versioning 2.0](https://semver.org/) specification is used for versioning.
+
+To include commits in the changelog, please ensure that you include the following keywords:
+
+- Start the commit with `fix:` to trigger a patch (0.0.x) version.
+- Start the commit with `feat:` to trigger a minor (0.x.0) version.
+
+#### Scope
+
+To make commit messages and the changelog more specific and readable, you have the option to scope your commits by adding a keyword in parentheses that indicates the area or aspect you are working on. This practice helps provide clearer context and organization to the commit history.
+
+##### Examples:
+
+- Adding a new component: `feat(Button): added a new Button component`.
+- Adding documentation for icons: `docs(icons): added new documentation for the icons package`.
+
+#### When to use what keywords
+
+It is crucial to understand the distinctions between the two sections mentioned below. If you wish for commit messages to be included in the changelog, please use `fix:` or `feat:` as keywords. These keywords indicate changes that impact the users of our NPM packages and are therefore significant to highlight. For any other types of changes that do not directly affect the end user, please utilize a different keyword. If you are uncertain about which keyword to use and the changes are non-user-facing, you can use `chore:` as a default keyword.
+
+##### Added to changelog
+
+- `fix:` Patches a bug in the codebase. Nothing new is introduced in terms of functionality.
+- `feat:` Introduces a new feature to the codebase. A new component is an often use case.
+
+##### Not added to changelog
+
+- `build:` Changes that affect the build system or external dependencies (example scopes: rollup, stylelint, npm)
+- `chore:` Other changes that don't modify src or test files
+- `docs:` Documentation only changes
+- `style:` Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- `test:` Adding missing tests or correcting existing tests
+- `refactor:` A code change that neither fixes a bug nor adds a feature
+- `revert:` Reverts a previous commit
+- `perf:` A code change that improves performance
+
+### How to write and structure your code
+
+To ensure a consistent and enjoyable coding experience for everyone, we have established guidelines for writing our code.
+
+#### Styling with CSS Modules
+
+We use CSS modules to style our components. This prevents naming conflicts by adding a unique prefix to all components.
+A CSS module file is created by adding `.module.css` to the end of the CSS file.
+
+#### Use of design tokens
+
+When styling our components we try to always use semantic tokens from the `@digdir/design-system-tokens` package when available.
+Using hard-coded values is not reusable and we therefore try to avoid this.
+To learn more about what tokens are available visit our [documentation page](https://www.designsystemet.no/grunnleggende/designelementer/design-tokens).
+
+#### Formatting and linting
+
+In this project, we employ [Prettier](https://prettier.io/) for code formatting. It is advisable to configure your code editor to automatically format files upon saving. This practice will prove beneficial when merging your changes into the main branch. It's worth noting that we enforce rigorous code checks in pull requests, emphasizing the importance of consistent code formatting.
+
+TypeScript and CSS files have been configured with linting, which means that the project will scan these files for potential problems or issues. Linting helps maintain code quality by detecting errors, enforcing coding conventions, and promoting best practices. You have to fix all errors and warnings before the code can be merged into the main branch.
+
+We use [Editorconfig](https://editorconfig.org/) for defining rules and formatting for the IDE.
+
+#### Use of TypeScript files
+
+In code contributions for this project, we do not permit JavaScript files. The use of TypeScript ensures the safety and testability of our code.
+
+---
+
+## Publishing NPM packages
+
+The following documentation outlines the process for releasing new versions of the NPM packages. Please note that in order to release, you must have an NPM account that is connected to the Digdir organization on NPM. Make sure you are in the `main` branch before proceeding further. Publishing from other branches may lead to issues with the changelog.
+
+### 1. Build distribution files
+
+`yarn build`
+
+Build distribution files for all the packages. Make sure they all run successfully before proceeding to next step.
+
+### 2. Prepare new version
+
+`yarn lerna:version`
+
+This step does a few things:
+
+- Suggests a new version based on the latest commits. Make sure the version is correct before clicking enter. A user error with a commit message might suggest a version that is wrong.
+- Creates a new tag with the latest version number.
+- Commits the changes.
+- Pushes the changes to github.
+
+### 3. Make sure you are logged in to NPM
+
+`npm whoami`
+
+This command will return if you are logged in or not.
+
+### 4. Publish to NPM
+
+`yarn lerna:publish`
+
+Your account also has to be added to the Digdir organisation on NPM.
+
+### 5. Paste the latest changelog entry into the design system Slack channel
+
+You can copy markdown from the changelog in storybook to get nice styling and commit links.
+
+Please ensure that the appearance closely matches the image below. Consistency plays a vital role when interacting with our end users.
+
+![te](https://i.imgur.com/Uw0qA1O.png)