Merge pull request #84 from Amsterdam/release/241209

Release/241209

CHANGELOG.md

@@ -1,5 +1,7 @@
 
 
+## [0.1.4](https://github.com/Amsterdam/ee-docs/compare/v0.1.3...v0.1.4) (2024-12-09)
+
 ## [0.1.3](https://github.com/Amsterdam/ee-docs/compare/v0.1.2...v0.1.3) (2024-12-05)
 
 

docs/frontend/accessibility.md

@@ -45,14 +45,15 @@ The law is applicable to all government websites and applications, including int
 - [ ] Apply the provided CSS snippet and confirm that all elements are still rendered correctly, adhering to WCAG 1.4.12. In Chrome, you can utilize the Stylus plugin for easy implementation.
 
 ```css
-*{
+* {
   line-height: 1.5 !important;
   letter-spacing: 0.12em !important;
   word-spacing: 0.16em !important;
-} p
-  {
+} 
+
+p {
   margin-bottom: 2em !important;
- }
+}
 ```
 
 ### on a mobile app?

docs/frontend/languages-and-frameworks.md

@@ -13,9 +13,9 @@ For all frontend projects within the Municipality of Amsterdam we work with [NPM
 
 ## React Frameworks
 
-- [next](https://nextjs.org/) - Full stack React Framework build on top of Node JS.
-- [remix](https://remix.run/) - Full stack React Framework using the WEB API.
+- [Next.js](https://nextjs.org/) - Full stack React Framework build on top of Node JS.
+- [Remix](https://remix.run/) - Full stack React Framework using the WEB API.
 
 ## CSS
 
-_To Be Defined_
+- [CSS Modules](https://github.com/css-modules/css-modules)

docs/frontend/shared-components.md

@@ -8,4 +8,4 @@ Amsterdam has developed a couple of components that are being used
 
 ## Demos/examples
 
-- For developing with maps, there are demos and examples of common use-cases of maps at [https://maps.developers.amsterdam](https://maps.developers.amsterdam).
+- For developing with maps, there are demos and examples of common use-cases of maps at [maps.developers.amsterdam](https://maps.developers.amsterdam).

docs/frontend/third-party-dependencies.md

@@ -23,5 +23,6 @@ Maintaining a list of third-party frontend packages is too complex, therefore, w
 
 * [Vite](https://github.com/vitejs/vite) - Next Generation Frontend Tooling
   * [Vite community templates](https://github.com/vitejs/awesome-vite#templates) - Vite based project templates
-* [Webpack](https://github.com/vitejs/vite) - Next Generation Frontend Tooling
 * [esbuild](https://esbuild.github.io/) - Next Generation Frontend Tooling
+
+You may also be interested in [Languages and Frameworks (frontend)](./languages-and-frameworks.md).

docs/general/using-git.md

@@ -3,31 +3,31 @@
 
 ## What is the standard for using Git?
 The city of Amsterdam uses Git to push its code to GitHub.
-The city of Amsterdam maintains minimal requirements for the work flow, branches and commits.    
+The city of Amsterdam maintains minimal requirements for the work flow, branches and commits.
 
 ## When and for whom is this standard applicable?
 This standard applies to all developers.<br/>
 This standard must be applied to all new projects of the city of Amsterdam (new since June 2024).
 
 ## What is required?
 ### Work flow
-- [ ] Utilise the branch 'main' as a stable production-ready version of your project. Utilise the branch 'develop' as the integration branch for features and bug fixes.
+- [ ] Utilise the branch `main` as a stable production-ready version of your project. Utilise the branch `develop` as the integration branch for features and bug fixes.
 - [ ] Set up and document your team work flow. As part of your work flow you must do the following:
   - [ ] Set `develop` as the default branch and set the branch protection rules as follows:
     - [ ] Enable "Require a pull request before merging".
     - [ ] Enable "Require approvals".
-    - [ ] Set "Required number of approvals before merging" to at least 1. 
+    - [ ] Set "Required number of approvals before merging" to at least 1.
   - [ ]  Create a new branch every time you're implementing a feature, bug fix or other task.
   - [ ] Test before you push.
 
 ### Branches
 - [ ] Branch names must include 
-  - [ ] a prefix, which can be either: 
-    - [ ] feature,
-    - [ ] chore,
-    - [ ] bugfix,
-    - [ ] hotfix or
-    - [ ] docs.
+  - [ ] a prefix, which can be either:
+    - [ ] `feature/branch-name`
+    - [ ] `chore/branch-name`
+    - [ ] `bugfix/branch-name`
+    - [ ] `hotfix/branch-name`
+    - [ ] `docs/branch-name`
   - [ ] a ticket number that references the PBI (product backlog item) if applicable.
   - [ ] a short name to indicate the branch purpose.
 
@@ -58,4 +58,3 @@ please refer to this [blog post](https://initialcommit.com/blog/git-commit-messa
 
 ## Acknowledgements
 Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra)
-

docs/intro.md

@@ -3,29 +3,26 @@ sidebar_position: 1
 ---
 # Collaborating on standards
 
-> This page was last reviewed on April 18th, 2024. It needs to be reviewed again on January 18th, 2025.
+> This page was last reviewed on October 28th, 2024. It needs to be reviewed again on July 28th, 2025.
 
 ## Empowering Contribution: Your Guide to Success
 
 We're thrilled you're interested in contributing to our development community! The Engineering Enablement team is dedicated to supporting you throughout your journey. Should you ever feel daunted by the contribution process, don't hesitate to take a breather, and we'll be ready to assist you further. Your involvement is valued, and we're here to help.
 
-
-## Proces
+## Process
 
 Feel free to refine or introduce standards according to your vision – it's a straightforward and positive proces. Just follow these steps:
 
-1. Begin by shaping your proposal using [this format](#standard_format). Share your proposal by submitting a pull request in the [the repository development-standards](https://github.com/Amsterdam/development-standards).
+1. Begin by shaping your proposal using [this format](#standard_format). Share your proposal by submitting a pull request in the [the repository development-standards](https://github.com/Amsterdam/development-standards). To align with the Fork and Pull model, please be sure to fork the repository before submitting a pull request.
 2. Expect a positive collaboration! The Engineering Enablement team will get in touch to refine and enhance your proposal. We'll also appreciate it if you can identify other developers who share a positive view on your proposal for an initial review.
 3. Your proposal will be brought to the Guild for a constructive discussion. Your thoughtful participation in the conversation is warmly encouraged.
 4. If your proposal receives positive acknowledgment, the Engineering Enablement team will tag participating developers in the pull request and give it a positive approval.
 5. Embrace constructive feedback! Developers offering insights will be asked to share their thoughts on Github or contribute positively to the pull request. Whether it's the Engineering Enablement team or yourself, let's work together positively to incorporate feedback until it's a refined piece. Once perfected, the pull request will receive a positive approval.
 6. Celebrate the introduction! The updated or new standard will be published with a positive outlook. After 9 months, the Engineering Enablement team will reach out to those tagged, including you and the proposal approver, to confirm that the standard still holds its positive impact.
 
-
-
 ## Format of standard {#standard_format}
-When drafting standards, aim for brevity and clarity in your language. If you need guidance, don't hesitate to check out [the RFC-editor](https://www.rfc-editor.org/rfc/rfc2119). Here's how we break down our standards:
 
+When drafting standards, aim for brevity and clarity in your language. If you need guidance, don't hesitate to check out [the RFC-editor](https://www.rfc-editor.org/rfc/rfc2119). Here's how we break down our standards:
 
 - **Title of standard**
 
@@ -42,9 +39,12 @@ When drafting standards, aim for brevity and clarity in your language. If you ne
 
 - **Considerations**
 
-- **Further reading**
+- **Further reading***
+
+- **Acknowledgments***
 
-- **Acknowledgments**
+## Further reading
 
+- Want to know more about the Fork and Pull model? We recommend you read [the Github Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model).
 
-<small>\* Is not mandatory</small>
+<small>\* This section is beneficial but not mandatory</small>

package.json

@@ -1,6 +1,6 @@
 {
   "name": "docusaurus",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "private": true,
   "scripts": {
     "docusaurus": "docusaurus",
@@ -28,7 +28,7 @@
     "@docusaurus/preset-classic": "^3.5.2",
     "@mdx-js/react": "^3.0.0",
     "clsx": "^2.0.0",
-    "ee-docs-importer": "github:amsterdam/ee-docs-importer#v0.0.2",
+    "ee-docs-importer": "github:amsterdam/ee-docs-importer#v0.0.4",
     "prism-react-renderer": "^2.3.0",
     "raw-loader": "^4.0.2",
     "react": "^18.0.0",