Merge latest develop -> main

CODEOWNERS

@@ -0,0 +1 @@
+* @Amsterdam/engineering-enablement

docs/general/storing-source-code.md

@@ -2,7 +2,10 @@
 > This page was last reviewed May 7th 2024. It needs to be reviewed again on February 7th, 2025.
 
 ## How to store projects on Github?
-All projects must have their repo on GitHub in the account of the city of Amsterdam and should be public, see the section "Public or private" for allowed exemptions. You must use Git to store your code on GitHub. Secure your repo by enabling these branch protection rules:
+All projects must have their repository on GitHub in the account of the city of Amsterdam and should be public,
+see the section "Public or private" for allowed exemptions.
+You must use Git to store your code on GitHub.
+Secure your repository by enabling these branch protection rules:
 - Require a pull request before merging
   - Require approvals
     - The required number of approvals before merging is at least 1
@@ -14,7 +17,7 @@ This standard must be applied to all new repositories of the city of Amsterdam (
 ## Public or private {#status}
 Infra-as-code logic must always be stored in a private repository.
 This improves transparency and reusability,
-but protects us from exposing security implications that could benefit potential bad actors.
+but protects us from exposing sensitive information that could benefit potential bad actors.
 
 ## Recommendations
 - Send an e-mail to the Datapunt team to get access to the Amsterdam organisation in GitHub. Your e-mail must include the following:
@@ -26,20 +29,15 @@ but protects us from exposing security implications that could benefit potential
 
 ## What pitfalls to avoid?
 - Don't store the following files on GitHub whether the repository is public or not: 
-  - Private keys, secrets, usernames or other credentials.
+  - Private keys, secrets, usernames or other credentials. Make use of the templates on [gitignore template] (https://github.com/github/gitignore) repository to exclude files. 
   - Personally identifiable data. Report a data breach immediately if done so. Just removing the data will not erase it completely. The data will still be available through the history. Assume the data is publicly known as soon as you've published it. Bots are scanning repositories continuously looking for secrets. 
 - Don't disable the branch protection policies when they're inconvenient. Ask other developers outside your team to approve pull requests if no team members are available.  
 
-
-## Considerations
-
-
 ## Further reading
 - [The GitHub documentation](https://docs.github.com/en/get-started) is a good source of information.
 
 ## Acknowledgments
 Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra)
 
-
 ## 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).
+-  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).

docs/general/using-git.md

@@ -10,38 +10,36 @@ 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
+### 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.
-- [ ] Set up and document your team work flow. We recommend using [Git Flow](https://www.gitkraken.com/learn/git/git-flow) but other work flow are available. See [the recommendations below](#what-is-recommended) for options. As part of your work flow you must do up the following:
+- [ ] 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"
+    - [ ] Enable "Require a pull request before merging".
+    - [ ] Enable "Require approvals".
     - [ ] 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 must 
-  - [ ] prefix with either 
-    - [ ] feature
-    - [ ] chore
-    - [ ] bugfix
-    - [ ] hotfix
-    - [ ] docs
-  - [ ] contain a ticket number that references the PBI (product backlog item) if applicable
-  - [ ] contain a short name to indicate the branch purpose
-
-
-### commits
-- [ ] Commit messages must quickly convey what a change is supposed to do and why it was necessary.
-- [ ] Never commit generated files, dependencies or local configuration files unless there is a good reason.   
-- [ ] A commit message consists of two parts: a title and the description. 
-  - [ ] Title: describes what changed.
-  - [ ] Description: describes why this change is needed.
+### Branches
+- [ ] Branch names must include 
+  - [ ] a prefix, which can be either: 
+    - [ ] feature,
+    - [ ] chore,
+    - [ ] bugfix,
+    - [ ] hotfix or
+    - [ ] docs.
+  - [ ] a ticket number that references the PBI (product backlog item) if applicable.
+  - [ ] a short name to indicate the branch purpose.
+
+### Commits
+- [ ] Commit messages must quickly convey what a change is supposed to do and why it was necessary. In the [What is recommended](#what-is-recommended) section some best practices are described. 
+- [ ] A commit message must at least contain a title and a description. A title describes what's changed, a description describes why the change is needed.
+- [ ] Never commit generated files, dependencies or local configuration files unless there is a good reason.
 
 ## What is recommended?
-- [ ] Recommended alternatives to Git Flow include the [GitLab workflow](https://docs.gitlab.com/ee/topics/gitlab_flow.html) and [Trunk based development](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development).
+- [ ] The recommended team work flows for using Git are [GitLab workflow](https://docs.gitlab.com/ee/topics/gitlab_flow.html), [Git Flow](https://www.gitkraken.com/learn/git/git-flow) or [Trunk based development](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development).
   Trunk-based development should only be used when Continuous Integration is in place and code can be deployed at any time it is merged.
+- [ ] Discuss with your team how to manage your change- and release logs. [Conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary), together with [commitizen](https://commitizen-tools.github.io/commitizen/getting_started/) can be really helpful in creating clean crisp logs.
 - [ ] Push often to ensure that your work is visible and not lost.
 - [ ] Create a draft pull request to discuss the progress on the current task.
 - [ ] Create the same branch protection rules as for the 'main' and 'develop' branch for each long-lived environment branch:
@@ -51,13 +49,12 @@ This standard must be applied to all new projects of the city of Amsterdam (new
 - [ ] Commits should be atomic, meaning that it contains only one change. It could be multiple files, but it's a single change. 
 - [ ] Commit early and often.
 
-
 ## What to avoid?
 - [ ] Never commit sensitive information such as passwords, personal data or API keys.
 
 ## Further reading
 For more information on commits,
-please refer to this [blog post](https://initialcommit.com/blog/git-commit-messages-best-practices)
+please refer to this [blog post](https://initialcommit.com/blog/git-commit-messages-best-practices) [and this blog](https://cbea.ms/git-commit/)
 
 ## Acknowledgements
 Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra)

docs/projects/maps.md

@@ -0,0 +1,9 @@
+---
+custom_edit_url: null
+---
+
+# Leaflet maps in React
+
+Amsterdam's preferred map library is <a href="https://leafletjs.com/" target="_blank">Leaflet</a> and frontend framework is <a href="https://reactjs.org/" target="_blank">React</a>. Combining Leaflet with the React component lifecycle can provide some challenges. Therefore, we have created a repository and Storybook application to browse common map components and feature examples.
+
+You can browse the project at [https://maps.developers.amsterdam/](https://maps.developers.amsterdam/).