docs: add decision minutes for 2019-10-09 meeting

decisions/2019/10/09-fe-decision-board.md

@@ -0,0 +1,123 @@
+# Front-end Decision Board, 2019-10-09
+
+**Attending**: Viktor, Ismay, Hendrik, Jennifer, Jan, Jan-Gerke, Austin,
+Joakim S., Erik, Birk, Edoardo
+
+## Topics
+
+### Help each other stay on topic in a discussion, split side topics into new issues
+
+**Conclusion**: Since GitHub Issues are linear, it is difficult to keep
+track of discussions if it starts to deviate away from the original
+issue. If that happens, we should not be shy about suggesting to move
+the _new_ discussion to a separate issue.
+
+Once that's done and all the comments have been moved to the new
+discussion, they can be hidden or removed from the original issue to
+make it easier to follow.
+
+Think of each issue in GitHub as a single thread.
+
+### ESlint config generated by d2 style js install [#52](https://github.com/dhis2/notes/issues/42)
+
+**Conclusion**: It is [possible to customise the ESLInt
+rules](https://github.com/dhis2/cli-style#eslint) that
+`d2-style` applies when running its checks and balances. It was
+introduced in version 4.0.0 so make sure you are on the latest major
+version to access the functionality. [>=4.1.3 is strongly
+recommended](https://github.com/dhis2/cli-style/releases/tag/v4.1.3).
+
+Now we want to implement support for project-specific configuration
+files, e.g. `project/react` to get all the special React ESLint rules,
+and an open question was how to deal with the dependencies. There are
+two proposals:
+
+1. Bundle the dependencies in `d2-style` so the consumer doesn't have to
+   think about it.
+
+2. Print a list of required dependencies that the consumer will have to
+   satisfy manually.
+
+The primary pros and cons raised for **(1)** were:
+
+- :heavy_plus_sign: Simple implementation.
+- :heavy_plus_sign: Easier to manage dependency versions.
+- :heavy_plus_sign: Inline with how the rest of `d2-style` works (batteries included).
+- :heavy_minus_sign: Potentially un-used dependencies installed into
+  the consumers `node_modules/`.
+- :heavy_minus_sign: Longer install time for `d2-style` because there's
+  simply more runtime deps.
+
+For option **(2)**:
+
+- :heavy_plus_sign: No stale/un-used dependencies in `node_modules/`.
+- :heavy_plus_sign: Smaller install size for `d2-style`.
+- :heavy_minus_sign: Difficult to maintain versions of supported plugins
+  and catch discrepencies.
+- :heavy_minus_sign: User needs to be aware that she needs to install
+  additional deps after enabling e.g. `project/react` config.
+- :heavy_minus_sign: Requires a more complex implementation to work.
+
+Since option **(1)** is closer to the vision of the `d2-style` tool, we
+will start with that solution, and if the size of the installed tool
+gets out of hand, we will have to re-think the approach.
+
+One suggestion was to use custom NPM packages for specific presets, e.g.
+for React: `@dhis2/cli-style-preset-react` to avoid bundling all
+dependencies in `@dhis2/cli-style`.
+
+### Unified form handling [#25](https://github.com/dhis2/notes/issues/25)
+
+**Conclusion**: Going forward with
+[`dhis2/ui-forms`](https://github.com/dhis2/ui-core/pull/430) as is.
+Work on it is currently on hold as some required components are being
+re-worked and developed for the next major version of
+[`dhis2/ui-core`](https://github.com/dhis2/ui-core/pull/430), so now is
+a _great time_ to go through `ui-forms` and get involved!
+
+### Slow down releases a bit, improve automation
+
+**Conclusion**: The proposal was rejected. This was in part due to
+wishes to not split the developer workflow in two by having e.g.
+squash-merges to `develop` and merges to `master`.
+
+On hindsight there are multiple issues conflated in this topic:
+
+- Allow Dependabot **automatic merges** of certain dependencies to handle
+  the avalanche of dependency updates.
+
+- Allow a developer to **defer the automatic release system** for a
+  short amount of time to bundle commits into the same release.
+
+- Allow the developer to **use the same workflow everywhere** so she
+  doesn't have to keep track of what to do when in 40+ repos.
+
+Splitting them up as follows:
+
+### Use the same workflow everywhere
+
+**Conclusion**: Run a trial for a single merge strategy tracked in
+[#72](https://github.com/dhis2/notes/issues/72).
+
+### Automatic merges
+
+**Conclusion**: Run a trial tracked in
+[#71](https://github.com/dhis2/notes/issues/71).
+
+### Defer the automatic release system
+
+**Conclusion**: There are a few options of varying complexity:
+
+- The proposed workflow in the agenda.
+
+- Bundle multiple changes on the same branch before merging to `master`.
+
+- Using `[skip ci]` in a commit message to, well, skip CI, which will
+  also skip the `semantic-release` process.
+
+- Implementing another commit message tag, e.g. `[defer release]` to
+  still run the CI checks, but skip the `semantic-release` process. [A PR
+  for it has been posted](https://github.com/dhis2/cli/pull/161).
+
+The `[skip ci]` and `[defer release]` options are different variations
+of the same. The PR for the defer release tag has been merged and is available in [`@dhis2/cli` in version 2.5.0](https://github.com/dhis2/cli/releases/tag/v2.5.0).