-
Notifications
You must be signed in to change notification settings - Fork 23
2019_03_06_Kirby Guild Meeting Summary
This page contains a meeting summary from the Kirby Guild meeting, held on March 6th, 2019.
This time, the "Kirby Guild" had a visit from Lyngby, instead of having a virtual meeting, everyone was in the same physical location
The meeting had a lot of conversational dialog going on (re-iterating decisions from previous meetings etc.), hence not really suited for a summary. This is the "best effort" trying to capture any decisions, and summarize (in very broad terms) what went on.
The mandate for the "Kirby Guild" is:
- Meet once per week to facilitate progress of the Kirby Designsystem (where the meeting has a set length of one hour).
The Kirby Designsystem will have an additional, 2 new "full time" (dedicated) resources (from Trifork) added to ensure progress - hopefully leading to no developers / teams waiting for components to be created. They will be working in close association with the Kirby Guild (and be participating in future meetings)
There's been an ongoing investigation task, evaluting a "common starting point" for basing "simple" UI-components on (for web-clients). The choice has been between:
- using native web components (and creating our own components, where one is not present, eg. a toggle)
- using Ionic Framework (presenting UX mimicking the host platform)
- using Material Design / Angular Material which would provide a similar UX regardless of the host platform)
We came to the conclusion "to go" with the Ionic Framework.
The Kirby Designsystem is provided under the MIT license. When using other licensed product, in case their license conflicts with the MIT license, they should be provided as a peer dependency.
Highcharts is also provided through the same mechanism, although their licensing policy does dictate when a "end product" uses their chart (even open source), a license must be acquired. Hence, we need to acquire an Open Source license for the Kirby Cookbook.
A task of acquiring a license, has been created (see #135).
Follow this link for instructions on how to get support.
Have a look at the contribution guidelines.
The following articles can help you become a good contributor. They document our toughts and opinions on contribution related topics.
- The Good: Issue
- The Good: Branch
- The Good: Commit
- The Good: Self-review
- The Good: Pull-request
- The Good: Test
Other ways of doing things are not wrong - however a project of this size requires consistency in the way we cooperate to be manageable.
Ultimately it will help you save some time getting from a new issue to a merged PR.