sebgroup
🚨 Before creating a new issue
Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
Using the issue tracker
The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests, but please respect the following restrictions:
- Do not include any form of sensitive or confidential data, in text or in screenshots.
- Use Teams for personal help requests, or if sharing of sensitive data is required.
Bug reports
A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!
Guidelines for bug reports:
-
Use the GitHub issue search — check if the issue has already been reported.
-
Check if the issue has been fixed — Check if it is mentioned in the latest releases or try to reproduce it using the latest
mainbranch in the repository. -
Isolate the problem — create a reduced test case and a live example if possible.
A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs.
Feature requests
Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. The best approach is to book a Green coaching session to describe and discuss your needs with the Design System team.
Creating issues
Labels: Please add multiple labels:
Component names - Comp: Button, Comp: Dropdown, and so on. Library - Lib: Core, Lib: React, Lib: Angular, Lib: Chlorophyll, and so on. Other types like: Documentation (usually Storybook), seb.se (the website), a11y (Accessibility related), and more. See a list of all of them here: https://github.com/seb-oss/green/issues/labels
Title: Please first put the name of the component that is affected and then a colon and a short sentence saying what type of issue. Don't describe everything in here (max length around 80 characters). Just write it so you can understand what sort of trouble it is. The description then comes inside the issue. Multiple components can be listed with a comma and then colon. But only if it's the same problem. If the issue could be split into two different types of problems, please do that. If no specific component is involved, try to find what is the main subject instead, like "Storybook".
Do:
"Button: Missing key input animation" "Dropdown, Datepicker: The popover uses too little of screen space on mobile" Don't:
"If you press enter on buttons, you will not see anything visually happen, so you don't know if something happened when you are using the keyboard" (too long & not starting with component) "Dropdown, Datepicker: Dropdown have too little contrast in darkmode and Datepicker is too small on mobiles (can be split in 2 issues & too long)
Pull requests
Good pull requests - patches, improvements, new features - are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
Please ask first before embarking on any significant pull request (e.g. implementing features, refactoring code, etc), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
Please adhere to the coding conventions used throughout a project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).
Make sure you understand the architecture, coding guidelines and what's what.
Please read the Contribution Guidelines before submitting a Pull Request.
Labels: Please add multiple labels:
- Component names - Comp: Button, Comp: Dropdown, and so on.
- Library - Lib: Core, Lib: React, Lib: Angular, Lib: Chlorophyll, and so on.
- Other types like: Documentation (usually Storybook), seb.se (the website), a11y (Accessibility related), and more.
See a list of all of them here: https://github.com/seb-oss/green/issues/labels
Title: Please first put the name of the component that is affected and then a colon and a short sentence saying what type of issue. Don't describe everything in here (max length around 80 characters). Just write it so you can understand what sort of trouble it is. The description then comes inside the issue. Multiple components can be listed with a comma and then colon. But only if it's the same problem. If the issue could be split into two different types of problems, please do that. If no specific component is involved, try to find what is the main subject instead, like "Storybook".
Do:
- "Button: Missing key input animation"
- "Dropdown, Datepicker: The popover uses too little of screen space on mobile"
Don't:
- "If you press enter on buttons, you will not see anything visually happen, so you don't know if something happened when you are using the keyboard" (too long & not starting with component)
- "Dropdown, Datepicker: Dropdown have too little contrast in darkmode and Datepicker is too small on mobiles (can be split in 2 issues & too long)
