kyma-project / community Goto Github PK

Description

Describe the decision making process based on the decision log.

Reasons

Describe the consistent decision making process applicable for the whole Kyma community

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• Prepare a template and store in one location with other documentation templates in guidelines directory
• Base the template on already existing documents:
  • https://github.com/kyma-project/kyma/blob/master/docs/api-gateway/docs/011-api-custom-resource.md
  • https://github.com/kyma-project/kyma/blob/master/docs/kyma/docs/040-installation-custom-resource.md
• Be consistent with already existing templates: https://github.com/kyma-project/community/blob/master/guidelines/templates/resources/cli-reference.md or suggest refactor that will have to be done also in other templates

Reasons

Every documentation topic must follow https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/content-strategy.md#documentation-types and all those types must have templates which make it much easier for anybody to contribute content

Description

1. Create a template for release notes. Consult the template with other TWs. Make sure the template contains the summary section from which a reader gets the gist of major changes in the release.
2. Use these guidelines and add them to our content guidelines.

Note that:

• Release notes should be written from the user's perspective.
• This is a marketing/business type of doc so proper tone should be used in it.

Reasons

• POs should know how to provide input to the release notes.
• It should be clear what writing guidelines should be followed when writing the release notes.

Description

Add information to the Links section in the guidelines that in the docs inside the kyma repository we should cross-reference only external docs and if we want to make a reference to any other related docs from the docs directory, we should reference it by a (bolded) name only.

Reasons

The internal cross-references do not work on the Console and on the website.

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• Add new guideline file and be consistent with diagrams guideline file
• I suggest to reuse https://devportal.yaas.io/tools/documentationguidelines/index.html#ImagesandDiagrams-images-and-screenshots
• check if we can provide a kind o snaggit source file with a picture and those circle and square components used there.
• the example is still needed as well
• change the purple and yellow colors from yaas guidelines to #0a6ed1
  

Reasons

We recently agreed to have some exception rule for allowing screen shots. We need to provide guidelines for that

Description

Update the content strategy document to include the Installation document type as an additional, optional, document type. Describe the type and its purpose in short.

Reasons

Since the number of Kyma installation guides is (and will be) growing we would like to expose those documents more and separate them from other Getting Started guides or Details docs on the installation topic. Thus, an idea for a new type was proposed and agreed on as part of that issue.

Hi,

We need customized GitHub analytics for the Kyma project.
These analytics should include the following KPIs:

• No of external contributors
• No of external downloads/clones
• No of external issues (bugs, improvements, comments, reviews, PRs…)
• Commits per external contributor

These data should be filtered by period. Analytics should have a summary dashboard covering main KPIs listed above in the form of numbers. Also, we need a detail view of each KPI in a form of numbers and graphs.

A reference for the GitHub analytics is the Google analytics.

I hope this was detailed enough for you to work on a script. Let me know if you need more input from my side.

Best,
Ana

Description

Update the optional doc section in the content-strategy.md document with information on a new type of documents called Examples. Mention that it should be used optionally in the official kyma docs under kyma/docs.

Related issues
It relates to the issue #1730 and should be done as a follow-up to it.

Description
The first release of kyma-project is out. In order to make a next release less painfull several actions should be taken:

• document current release process (used for the first release)
• automate some manual steps to simplify and speed up the process
• implement the process in the new CI/CD tool (Prow)
• review, adapt and create a new version of the release process that will be used in next releases

1. Mention the new UI OSBA Contract document type in the content-strategy document.
2. Fix bugs in the community repo

Description

• propagate https://github.com/kyma-project/community/blob/master/.github/ISSUE_TEMPLATE/security-vulnerability.md template to all the repos
• add template to the repo template

Reasons

This is to increase accuracy and better definitions of security related issues

Description

As it was agreed at the SIG content meeting, the attached material for the Kyma open-source branded template needs to be placed in the community repository (perhaps a separate folder under templates?) so it could be used to introduce the Kyma open-source project.

Attachments include:

• the Kyma open-source branded template
• elements from the ppt in the .png format for the assets folder

Kyma open source branded ppt.pptx
png.zip

Hi,

Can you, please, add the Stack Overflow Icon to the footer and community section on the Kyma Website?
The relevant icons are in Zeplin.

Thanks!
Ana

The table with the templates may be a bit unclear when it comes to the README.md documents. Improve the table so that it makes it clear when to use a given README template.

Created on 2018-12-05 by Szymon Janota (@sjanota)

Decision log

Context

One of the features that is currently being implemented in Kyma is the integration with Knative. It must be established how to run Kyma and Knative in a single Kubernetes cluster.
The following factors need to be taken into consideration:

• The way Kyma has to works without Knative has to remain unchanged
• How difficult is it to upgrade to newer versions of Knative
• How difficult is it to extend the solution and integrate more Knative components
• How difficult is it to manage additional components in the running clusters
• How does the solution fit into the overall Kyma architecture

With these criteria in mind, solutions must be chosen for these problems:

1. How to run Kyma and Knative on a single Kubernetes cluster and have both tools fully funtional.
2. How to fit Knative into the Kyma installation process.
3. How to version Knative within Kyma.

Each of these problems can be solved several ways. The possible solutions are discussed in the next section.

How to run Kyma and Knative on a single Kubernetes cluster and have both tools fully functional

Kyma and Knative are both installed in their own Namespaces, so they are not conflicting with each other directly. The only component they share is Istio. Kyma introduces several changes to the default Istio installation, whereas Knative does not modify Istio in an intrusive manner. This allows Knative to work with the Kyma version of Istio without any problems. Knative runs on top of Istio, but uses its own ingress gateway, while Kyma uses the Istio default Gateway. The Gateways are configured so that they can be accessed under different Services. Both ingress gateways and their configurations are installed in the istio-system Namespace. There are two approaches to making both tools accessible:

1. Do not change the network configuration. Acces Kyma and Knative through their respective default ingress gateways. This solution was proved to be working by @kubadz in kyma-project/kyma#1643

   • Advantages:
     • No changes in any of the systems
   • Disadvantages:
     • Two ingress gateways have to be maintained. This means more complex DNS management, deployment and debugging

2. Route all traffic through the Knative ingress gateway, abandon the default Kyma ingress gateway. This solution was proved to be working by @sjanota in kyma-project/kyma#1598.

   • Advantages:

     • Easier network management thanks to having a single point of entry in the cluster
     • Easier management of TLS certificates
     • Closer integration with Knative

   • Disadvantages:

     • Requires modifying Knative and Kyma deployments
     • Knative must to be tightly integrated with Kyma installation process

How to fit Knative into Kyma's installation process

The "batteries included" principal is one of the most important ones for Kyma. That's why Knative integration needs to be available without requiring the users to install additional components on their own. Because of its dependency on Istio, Knative must be installed by the Kyma installer after Istio.

Knative team does not provide Helm charts for their releases. Instead, they provide yaml files containing all of the resources. Possible ways to integrate Knative installation into the Kyma installer:

1. Create a Kubernetes job which installs Knative from the yaml file and verifies the installation, just like Helm would do. This job also adds required customizations.

   • Advantages:

     • Easier upgrades of Knative

   • Disadvantages:

     • This is not how installer is intended to be used
     • Yet another Bash script we need to maintain. Goes against the general rule to avoid Bash scripts whenever possible

2. Create a chart which embeds Knative yaml files. Required customisations are added as generic parameters to the chart or changed using existing tools such as overrides or the istio-patch.

   • Advantages:

     • Easier extensibility
     • More in line with the installer
     • No additional tool introduced to the system

   • Disadvantages:

     • More difficult upgrades until Knative introduces a helm chart

How to version Knative within Kyma

1. Version URLs to specific versions of Knative.

   • Advantages:

     • Knative yaml file are not maintained in Kyma

   • Disadvantages:

     • Kyma installation depends on the availability of the external files
     • Cannot be used if Knative is embedded in a chart

2. Version all yaml files within the Kyma repository

   • Advantages:

     • Better control over what's being installed

   • Disadvantages:

     • These files become a part of Kyma and thus need to be maintained

Proposed solution

Proposed solution is to use the Knative ingress gateway as it allows for a better integration with Knative and makes cluster management easier. The other ingress gateway will still be deployed, but will remain unexposed and unused. As this solution requires changes in both Knative and Kyma deployments, extensibility is the main concern when thinking about installation. Therefore the chosen approach is to embed Knative in the chart. Packing Knative into a chart format eliminates the possibility to version only URLs. Instead, all of the required yaml files must be added to Kyma.

Installing Kyma with Knative is optional. Installation can be enabled with the global.knative global installer override paired with a boolean value. Kyma without Knative installed will continue working as before.

Decision

Approved

Status

Proposed on 2018-12-06

Consequences

Advantages:

• Debugging and maintanance of installation with Knative is easier as Kyma and Knative use the same entry point.
• Extending Kyma-Knative integration will be easier than with raw yaml files. This is important from the eventing and serverless perspective.
• We are independent of Knative release cycle
• We can contribute helm charts to Knative

Disadvantages:

• Different component works as entry point in normal operations and with Knative. This difference may disappear as Knative will use Istio ingress gateway in new releases (knative/serving#2434).
• Upgrading Knative is troublesome as we need to migrate customizations from one version of the yaml files to another.
• We need to maintain Knative charts in Kyma

Description

Update the Tool section in the diagram guidelines to mention that it is enough to add SVG diagram format to the relevant assets folder without html or xml source since you can edit SVG directly in draw.io.

Reasons
You can edit SVG directly in draw.io so there is no need to add the source to the assets folder as well.

Description

Update release-subscription.md to include the GitHub's new feature to only subscribe for watching releases.

Attachments

Description

• Research what are obligatory repository settings in the kyma-project organization.
• Create an instruction for members of the organization on obligatory settings that should be defined on a new repository (e.g. only the Squash and merge option enabled).
• Add the instruction here.
• Update the README.md with information on this new document.

Reasons

Consistency in the repository settings throughout the organization. You need to know not only what structure the repo should get but also what settings are required.

Created on 2018-10-12 by Mateusz Szostok (@mszostok)

Decision log

Context

Kyma project was consolidated and now all core project written in Go are placed in one repository. Unfortunately, still all projects are written in a different way.

This situation causes the following problems:

• often the common package is copied across different project because of that we break the DRY rule.
• when we do not follow the DRY rule then when the bug is detected, we must apply the fix in all places. That's increasing complexity and it's easy to forget about some projects.
• if a developer is not aware that some functionality is already implemented and can be reused the often we have a different approach for same business logic e.g. logging pattern, metrics, graceful shutdown, testing, configuration etc.
• because projects have often different approaches to the same problem then the getting acquainted with the projects is more complex for internal and external contributors.
• when given functionality is reimplemented several times by different developers then the testing approach is often different. Sometimes functionality is well tested but sometimes not and not working as expected. The good example is a wait functionality. We reimplemented a well know pattern here but in this case with the small bug which caused that function never reach the given timeout. We can see also a lot of reimplementation of this pattern in new PRs, f.e. here also without test case.

Decision

The decision is to extract common code from Kyma components to the common package and use it in all required places. Thanks to that Kyma Developers can use in Kyma projects unified and well tested libraries which will be easier to understand and make a future development faster.

Status

Proposed on 2018-10-17.
Accepted on 2018-11-30.

Consequences

Once approved, these are the consequences:

• new package for common libraries need to be created and maintained
• new strong CODEOWNERS need to be defined for reviewing libraries added for common package
• new package needs to be announced and other projects should switch to use the official libraries instead of custom implementation
• developers always need to check our libraries to do not reimplementing business logic
• if some business logic is used in more than 2 projects then is highly recommended to extract it to common libraries. Remember that added source code needs to follow all rules of being in common package. Announce new library which solves given problem, so another developer can simply use it.

Create a document that contains information about the release process.
The input from @crabtree:

1. Create release branch in kyma repository - only done when creating new release, not bugfix release
   a. Name of this branch should follow pattern release-x.y (example release-0.4)
2. Bump versions and dirs parameters in values.yaml files in root charts, setting those to desired version which will be released. Commit and push this file to release branch
3. Run release pipeline on Jenkins (before you can run this pipeline all components and governance plan need to be changed. The merging strategy needs to be disabled for time of running release pipeline)
4. Run pipeline for releasing kyma-installer from release branch and set version to release version
5. Produce local and cluster combo yamls
   a. ./installation/scripts/generate-kyma-installer.sh ./installation/resources/installer-config-local.yaml.tpl > kyma-config-local.yaml
   b. ./installation/scripts/generate-kyma-installer.sh ./installation/resources/installer-config-cluster.yaml.tpl > kyma-config-cluster.yaml
6. In generated combo yamls set apropriate kyma-installer image (produced in step 4)
7. Attach artifacts and readme to release on github

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

The guideline on CRDs (guidelines/custom-resource-definitions.md) is using "kyma.cx" as domain for kyma-specific CRDs. That should be changed to "kyma-project.io".

Description

• create DR template
• replace current ADR template with new DR template
• Cleanup existing ADR location and put them under SIG-Core

Reasons

• unify the ADRs with DRs

Description
Since the decision-making process has changed, the "governance.md" document contains outdated diagram illustrating the process.

Correct the diagram and save the updated version in the svg format according to the guidelines.

Description
The guidelines do not provide any information on whether to capitalize "lambda/function" terms or not. Make a research on whether to capitalize those terms or not and update the guidelines.

Decision
We should capitalize Function when it refers to the Kubernetes resource. Otherwise, it should be written in lowercase. We agreed not to capitalize "lambda" on one of the SIG Core meetings.

AI:
Add "Function" to the list of capitalized terms in the guidelines.

Description

If you add a new component to the kyma/docs, the following files must be changed:

1. resources/core/charts/docs/charts/documentation/templates/docs-job.yaml
2. docs/manifest.yaml
3. docs/Jenkinsfile
   Find and entry for a topic that already exists, duplicate it and adjust to use the name of your topic.

Reasons

As there are quite a few steps to complete when adding a new component to the kyma/docs folder, create a document describing this process step by step. This would leave contributors no room for doubts when adding a new component to docs.

Created on 2018-11-29 by Paweł Kosiec (@pkosiec).

Decision log

Context

UI API Layer exposes GraphQL API for the Kyma Console. It consists of resolver logic for different domains, like Kubernetes, Service Catalog, Remote Environments, Kubeless, etc. As Kyma needs to be modularized, users should be able to install only the components they need.

The current approach we use in UI API Layer makes it impossible. During the GraphQL server start, we try to synchronize Stores of all Informers. As a result, if a resource of a specific type doesn't exist, UI API Layer won't start properly because its Informer will return an error.

Decision

The decision is to implement UI API Layer module pluggability according to the proposal merged in #141, which bases on replacing UI API Layer resolver logic implementation depending on Back-end Module Custom Resource existence.

Status

Proposed on 2018-11-29.
Accepted on 2018-12-03.

Consequences

This decision have the following consequences:

• UI API Layer modularization will be implemented according to the task kyma-project/kyma#1883, which describes steps required for production-grade implementation suggested in the proposal.
• All Front-end Developers should adjust their UIs to make them resilient. Some UI API Layer modules can be turned off, which could not result in crashing UI.

Description

When I go to page: https://kyma-project.io/docs/components/serverless#

scroll down to the bottom and click the service catalog hyperlink:

it does not work:

Expected result

The document page for service catalog is displayed.

Actual result

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Changes required:

• move components list from installer config-map to installation CR
• extend components list to support more descriptive installation steps
  • componentName - required
  • releaseName - default=componentName
  • namespace - required
  • stepType [helm, kubectl-apply, kubectl-patch]- default=helm
• installer will not support bash scripts execution
• installer will not support dependencies, if your component relies on another component then you need to handle dependency checking yourself (init containers)

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• Prepare a template and store in one location with other documentation templates in guidelines directory
• Base the template on already existing documents
• Be consistent with already existing templates: https://github.com/kyma-project/community/blob/master/guidelines/templates/resources/cli-reference.md or suggest refactor that will have to be done also in other templates

As a follow-up task, adjust the existing Overview documents to the template.

Reasons

Every documentation topic must follow https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/content-strategy.md#documentation-types and all those types must have templates which make it much easier for anybody to contribute content

Description

Since CI does no longer run automatically on the PRs, it is required to run the builds manually before the PR is merged.
Update these CONTRIBUTING.md documents with the manual CI run step information:

• https://github.com/kyma-project/examples/blob/master/CONTRIBUTING.md
• https://github.com/kyma-project/community/blob/master/CONTRIBUTING.md

Description

• Update the content-strategy.md document with the new numbering format.

• Update existing templates for official docs and remove information document types from the document names as the number of the doc already describes the type and the metadata in the doc also provides these details.

• Add formatting to the names of the {xxx} CustomResourceDefinitions (CRD) in the related template.

Description

Add information on the new formatting of CRs to the content guidelines.
The accepted format is: {Name} custom resource

Reasons

TWs' decision

Description

Decide what should be the order of document types that should be used consistently in all component docs under kyma/docs.

• Propose the order by updating the list of obligatory docs in content-strategy.md accordingly. Consult the choice with other TWs (it can be done through comments in the pull request).
• Add a note to the document explaining that the order is binding and should be used for all components.
• Rename Getting Started type of docs into Tutorial, as agreed on the SIG Content.

Reasons

Consistency in docs

Purpose

Having the option to run kyma-eventing on top of knative-eventing.

Use-cases

1. Kyma runs by default with the event-bus and nats-streaming messaging system.
2. Kyma runs on top of knative and knative-eventing when the knative flag is provided to the kyma installer.

Design

Kyma is installed on top of Knative and using knative-eventing abstraction to publish and deliver messages:

• The Publisher sends messages to the Publish app. Each message should contain the event-type and source-id.
• The Kyma Publish app receives the publish request from the publisher and sends the message to the corresponding knative channel related to the event-type provided with the publish request.
• The Knative Dispatcher stores messages to the underlying messaging system backend.
• The Kyma SubscriptionController app acts upon events coming from Kubernetes for the Kyma subscription-crd and the Kyma event-activation-crd, and it creates a knative-subscription for a specific Knative channel.
• The Knative Provisioner Controller manages subscriptions on the underlying messaging system backend.
• The Knative Provisioner Dispatcher delivers messages to the subscriber endpoint.

• Kyma EventBus sends messages to multiple Knative channels each of which can be tied to different Knative Provisioner.

Development

• Create two new apps inside the event-bus component codebase, one for the publish-knative app and the other for subscription-controller-knative app.

  Note: The publish-knative app should expose a publish API to publish messages from kyma to knative-eventing. The publish API should expect two required parameters the event-type and the source-id.

  Note: The subscription-controller-knative app should act upon the events coming from Kubernetes regarding the Kyma subscription-crd and the Kyma event-activation-crd, and it should create a corresponding Knative subscription. In addition, it should send requests to the Knative provisioner controller to store the subscriptions in the underlying messaging system backend.

  Note: We need to come up with a convention to map kyma-subscription(s) to knative-subscription(s).

Deployment

• Move event-bus helm chart from kyma/resources/core/charts/event-bus/ to kyma/resources/event-bus.

• Create a new helm chart for event-bus-knative component inside kyma/resources/event-bus-knative.

• Move nats-streaming helm chart from kyma/resources/core/charts/event-bus/charts/nats-streaming to kyma/resources/nats-streaming. As a constraint by Knative, the nats-streaming messaging system should not be installed in the knative-eventing namespace. Also it should be installed in a namespace which is istio-injection enabled. In general, it can be installed in the kyma-system namespace which is istio-injection enabled.

• Create a new helm chart for nats-streaming-provisioner under kyma/resources/nats-streaming-provisioner. As a constraint by Knative, the nats-streaming-provisioner must be installed in the knative-eventing namespace. Also it should have a dependency entry in the kyma/resources/core/charts/event-bus-eventing/requirements.yaml to install it when Kyma runs on top of Knative.

  The new directory structure should look like this:

  .
  ├── kyma/
  │   └── resources/
  │       ├── .
  │       ├── event-bus/
  │       ├── event-bus-knative/
  │       ├── nats-streaming/
  │       ├── nats-streaming-provisioner/
  │       ├── .
  

• Update the template files kyma/installation/resources/installer-cr.yaml.tpl and kyma/installation/resources/installer-cr-cluster.yaml.tpl to include the components nats-streaming and event-bus under the spec/components.

• Update the template files kyma/installation/resources/installer-cr-knative.yaml.tpl and kyma/installation/resources/installer-cr-cluster-knative.yaml.tpl to include the components nats-streaming, nats-streaming-provisioner and event-bus-knative under the spec/components.

• Update the knative charts inside kyma/resources/knative/ to use the proper knative version that has the nats-streaming-provisioner supported.

Design decisions

• There are two separate helm charts for event-bus and event-bus-knative, because both are serving two different purposes.
• There is one nats-streaming helm chart which is used for both event-bus and event-bus-knative, because the deployment of the nats-streaming messaging system remain the same for the two use-cases. The only constraint in case of Kyma is running on top of Knative, is not to install nats-streaming in the knative-eventing namespace. Also it has to be installed in a namespace that is istio-injection enabled.
• There is a separate chart for nats-streaming-provisioner, because it will be installed only in case of Kyma running on top of Knative.
• There are two new apps publish-knative and subscription-controller-knative introduced inside the event-bus component codebase for clear separation of concerns and responsibilities.

Installation

• Run Kyma installer and provide the knative flag to install knative, knative-eventing and nats-streaming-provisioner.
• Installing multiple Provisioners on a running kyma cluster should be applicable using helm charts by putting the provisioners under the kyma/resources/ directory.

Description

Rewrite the diagram in https://github.com/kyma-project/community/blob/master/issues-workflow.md to match our guidelines: https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/diagrams.md.
SVG as a source is enough.

Reasons

It does not match the guidelines.

Description
Add information about meeting recordings and mailing list in templates
https://github.com/kyma-project/community/tree/master/guidelines/templates/resources

Description

As decided by the SIG Content, the ASCII header needs to be removed from the chart_README.md template.
Apart from the template, it must to be removed from all existing chart README.md documents in the kyma repository.

Description

The Style and standards guide contains a confusing passage about the terminology of "for example".

Expected result

Clarify that "for example" should be used instead of "e.g.":

• "for example", not "e.g."
  ✅ There are many animals in the zoo. For example: lions, elephants, and zebras.
  ⛔️ There are many animals in the zoo, for example: lions, elephants, and zebras.
  ⛔️ There are many animals in the zoo. e.g.: lions, elephants, and zebras.

On the other hand, "for example" should not be used instead of "i.e.", since that has a different meaning. If you want to cover that, too, this should do:

• "that is", "that means", "in other words", or "namely", not "i.e."

Sorry, don't have any good examples for that. Should it be used at all?

Actual result

The suggested usage of "for example" instead of "i.e." is bad advice, because it would change the meaning of the sentence. In fact, the current example of using "i.e." does not make much sense, unless the only animals that the zoo contains are lions, elephants, and zebras – not sure if that qualifies as "many animals" though.

• "for example", not "i.e."
  ✅ There are many animals in the zoo. For example: lions, elephants, and zebras.
  ⛔️ There are many animals in the zoo, for example: lions, elephants, and zebras.
  ⛔️ There are many animals in the zoo. i.e.: lions, elephants, and zebras.

Steps to reproduce

Read the guide.

Troubleshooting

Until this is fixed, one might simply ignore the guide, and just make sure that both "i.e." and "e.g." are expressed in English language.

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• Prepare a template and store in one location with other documentation templates in guidelines directory
• Base the template on already existing documents
• Be consistent with already existing templates: https://github.com/kyma-project/community/blob/master/guidelines/templates/resources/cli-reference.md or suggest refactor that will have to be done also in other templates

Reasons

Every documentation topic must follow https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/content-strategy.md#documentation-types and all those types must have templates which make it much easier for anybody to contribute content

Description

Now that all PRs should have labels of the area(s) they refer to, the below guidelines require an update:

https://github.com/kyma-project/community/blob/master/git-workflow.md#contribute
https://github.com/kyma-project/community/blob/master/CONTRIBUTING.md#contribution-process

Update them with the info / or a step that a proper label should be assigned to each and every PR on every repo - only then they are included in the changelog.

Description

Update content guidelines with information to use short command line arguments (-n instead of --namespace) in the documentation whenever possible, unless it causes confusion in a given context. For example, short ones can be easily misinterpreted as they differ between tools, e.g. helm -n == helm --name != helm --namespace while kubectl -n == kubectl --namespace. In such a situation, the context should be explained in a given doc.

Reasons

A unified standard for command line arguments.

Description

As confirmed, the Creative Commons (CC) license is not required additionally in the repositories, Apache license is sufficient.

This as part of the clean-up, update the following:

1. Remove the CC license from repository-template
2. CC license is mentioned in this README.md - pls remove this information.
3. Replace the CC license with the Apache license at the root of the community repo.
4. Remove the CC from all docs folders in all repositories in the kyma organization and make sure only Apache license is present at the root of all repositories.

Description

• Create the decision record with respect to the template
• move proposal as well
• do it under sig-core

Reasons

We need clear decision on how we generate change log for our projects that are released

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• Prepare a template and store in one location with other documentation templates in guidelines directory
• Base the template on already existing documents
• Be consistent with already existing templates: https://github.com/kyma-project/community/blob/master/guidelines/templates/resources/cli-reference.md or suggest refactor that will have to be done also in other templates

Reasons

Every documentation topic must follow https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/content-strategy.md#documentation-types and all those types must have templates which make it much easier for anybody to contribute content

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

Since there were changes in the PR template introduced by this PR: [https://github.com//pull/12,] TWs need to adjust other templates to those changes.

1. Copy the pull request template (https://github.com/kyma-project/community/blob/master/.github/pull-request-template.md) to the repository template here: https://github.com/kyma-project/community/blob/master/guidelines/internal-guidelines/repository-template/template/.github/pull-request-template.md and in all repositories, other than the community repository, under /.github/pull-request-template.md location.
2. You need to get rid of checkboxes from all issue templates now and basically remove that phrase with hidden descriptive points (use PR template as a reference):

Confirm these statements before you submit the issue:

- [ ] I have searched open and closed issues for duplicates.
- [ ] I have read the contributing guidelines.
---

The replacement of the checkboxes with hidden descriptions needs to be done on all repos and in the repository-template that is in the community repo. There are three issue templates on each repo:

1. General issue template under /.github/issue-template.md
2. Bug report template under /.github/ISSUE_TEMPLATE/bug-report.md
3. New feature template under /.github/ISSUE_TEMPLATE/feature-request.md

Please add an information to the decision log template regarding the possibility to revisit particular decision earlier if needed. In that case a ticket would need to be created.

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• template should contain
  • information about the security email address, that user can use it if he doesn't want to make his security finding public
  • explanation what labels to use for security issues (security/{score})
• publish template in all repositories like in case of other templates

Reasons

• have clear specification of how to define a good security issue and remind user that he can keep those secret
• show that we treat security seriously

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description

• Document ServiceBindingUsage, UsageKind, EnvironmentMapping, EventActivation, RemoteEnvironment
• Use this template #25

Reasons

be consistent across all documentation topic and document Custom Resources the same way everywhere

Description

Add these two bullet points to the Terminology section in the Style and Standards document to mention that we should use:

• "API Micro Gateway" instead of "API Gateway"
• "connect/connection" instead of "integrate/integration"

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

Description
Currently it is hard to figure out what resources were created by controllers for Kyma CRDs. For example the API controller creates an ingress resource but it is hard to identify that it belongs to an API resource (you need to know the naming convention).

Without an easy way to recognize system resources that are managed by controllers (creation and deletion) we have the following issues

• Cannot provide filters on the UI to hide that "system" resources in an easy way
• Provide transparency to the end users (e.g. developers) about which resources are generated/managed by Kyma

Suggestion
whenever a kyma controller creates a resource in consequence of a kyma CRD resource, that resource will be enriched with all needed ownerReference attributes, see kubernetes guide. That needs to be documented in the guide for CRD development.

If done, please think about creating follow up tickets for adjusting existing controllers.