Skip to content

Commit 56728fd

Browse files
authored
docs: Adjust CONTRIBUTING.md to template repo (#4071)
1 parent f47e9f4 commit 56728fd

File tree

1 file changed

+1
-33
lines changed

1 file changed

+1
-33
lines changed

CONTRIBUTING.md

Lines changed: 1 addition & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -1,35 +1,3 @@
11
# Contributing
22

3-
To contribute to this project, follow the general [Contributing Rules](https://github.com/kyma-project/community/blob/main/docs/contributing/02-contributing.md) documented in the `community` repository.
4-
5-
## UX DoD Requirements
6-
7-
### General information
8-
9-
UI developed within Busola should be compliant with [Fiori Design Guidelines](https://experience.sap.com/fiori-design-web/).
10-
11-
### Additional guidelines for modals
12-
13-
- User should be able to close the modal (without saving changes, if any) by clicking anywhere outside of it.
14-
- Modal should support keyboard control:
15-
- User should always be able to navigate the modal using only a keyboard. While the modal is opened, focus should not leave the modal window.
16-
- If the modal contains input fields, the first of them should be automatically focused on opening the modal. In some cases, we can set focus on the most important element instead (e.g. the incorrect one).
17-
- Main actions, such as **Confirm**, **Save**, **Apply**, should use the [emphasized style](https://experience.sap.com/fiori-design-web/button).
18-
- If the content of the modal is dynamic, avoid resizing the modal. Modals width should be consistent across the application.
19-
- Follow the [ARIA](https://www.w3.org/WAI/standards-guidelines/aria/) attributes.
20-
21-
## Code Guidelines
22-
23-
- Keep functions small.
24-
- Modularize - functions and components should be doing just one task.
25-
- Functions shouldn't have too many arguments.
26-
- Avoid heavy nesting.
27-
- Maintain a single layer of abstraction at a time.
28-
- Use intention revealing and searchable names.
29-
- Don't use comments when you can use a variable.
30-
- You must be able to explain your code in a simple language (understand the algorithm).
31-
- Don't use the `any` type, this is the last resort.
32-
- Try to keep the pull request (PR) small if possible. Split big PRs into smaller ones, keep it civil for a reviewer.
33-
- Use translations instead of a simple string.
34-
- Organise files related to the same component in one folder.
35-
- Write tests for new components.
3+
To contribute to this project, follow the general [Contributing Rules](https://github.com/kyma-project/community/blob/main/docs/contributing/02-contributing.md).

0 commit comments

Comments
 (0)