Skip to content

Commit 063cf29

Browse files
Create new-component-baseline-review.md
1 parent e67e32b commit 063cf29

File tree

1 file changed

+39
-0
lines changed

1 file changed

+39
-0
lines changed
Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# Review checklist #1
2+
## For reviewing a newly-added component applying for status `Baseline completed`
3+
4+
A component's status should be updated to `Baseline completed` when the core functionality for the component has been completed and it is ready for use in prototyping.
5+
6+
`Baseline completed` components have not necessarily passed review for responsive design, accessibility, progressive enhancement and real-use testing.
7+
8+
Therefore, developers should be prepared that these components may be modified in the future. Where modifications occur, a new version of the component library will be published and a description of the updates will be included in the change log.
9+
10+
### 1. Merging and pull requests
11+
12+
- [ ] Are there merge conflicts with the `Main` branch? <br>
13+
(developers should check for conflicts before submitting a pull request by merging `Main` into their branch.)
14+
15+
- [ ] Does the pull request clearly detail new dependencies and features, and list any specific checks which they want the review to focus on?
16+
17+
### 2. Is the component self-contained?
18+
19+
- [ ] Does the component have a simple and specific function? <br>
20+
(if the component's function is broad, the developer should consider splitting it into smaller child components.)
21+
22+
- [ ] Does the component fulfil its function without reference to external code or other components? <br>
23+
24+
### 3. Is the component fully-functional and resuable?
25+
26+
- [ ] List the different use cases for the component. Can all of these use cases be realised by adjusting the components props? <br>
27+
(if a use cases requires adjusting props in an opaque way, that use case should be demonstrated as an example.)
28+
29+
### 4. Are the component props well constructed?
30+
31+
- [ ] Are component props sorted into intuitive categories in the demo UI?
32+
33+
- [ ] Have component props been given names which accurately and succintly describe what they do?
34+
35+
- [ ] Have component props been given reasonable default values where appropriate? <br>
36+
(generally, props should have default values unless they are derived from the data pipeline)
37+
38+
- [ ]
39+

0 commit comments

Comments
 (0)