diff --git a/community/core/community/README.md/index.html b/community/core/community/README.md/index.html index 6f2fe664af..1c0a4145db 100644 --- a/community/core/community/README.md/index.html +++ b/community/core/community/README.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Repository configuration

The github-config.yaml file contains the details of the + }

Thoth Logo

Project Thoth

Repository configuration

The github-config.yaml file contains the details of the GitHub configuration for our organization.

This file is used by Peribolos to apply the configuration to the various repositories. Check the Peribolos diff --git a/community/core/community/SUPPORT_POLICY.md/index.html b/community/core/community/SUPPORT_POLICY.md/index.html index db0597cbea..8b24a469db 100644 --- a/community/core/community/SUPPORT_POLICY.md/index.html +++ b/community/core/community/SUPPORT_POLICY.md/index.html @@ -14,7 +14,7 @@ - }

Thoth Logo

Project Thoth

Support Policy

This document outlines the support policy for Project Thoth. For general information how and where to contact us, + }

Thoth Logo

Project Thoth

Support Policy

This document outlines the support policy for Project Thoth. For general information how and where to contact us, please see our help page.

Supported Runtime Environments

When adding new content to Thoth’s Knoweldge Graph, we follow (roughly) the following policy:

  1. what runtime is used by RHODS/Open Data Hub? Right now most data science work is based on ubi8-py38
  2. what runtime is the latest release and maintained by Red Hat? ubi9-py39
  3. based on our research (py311 due to perf incr.), see also https://www.phoronix.com/review/python-311-performance

End of Life

We will disable solvers and the corresponding Python versions when they reach end of life. The data aggregated by Project Thoth will be kept in the Knowledge Graph for as long as possible. We will not delete data from the Ceph storage, but might disable its use for advises.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/governance.md/index.html b/community/core/community/governance.md/index.html index 8f6d51d542..948f690931 100644 --- a/community/core/community/governance.md/index.html +++ b/community/core/community/governance.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Principles

The Thoth Station community adheres to the following principles:

  • Open: Project Thoth is open source. See repository guidelines, below.
  • Welcoming and respectful: See Code of Conduct, below.
  • Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below.
  • Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles].

Code of Conduct

The Thoth Station community abides by [out code of conduct]:

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

As a member of the project, you represent the project and your fellow contributors. + }

Thoth Logo

Project Thoth

Principles

The Thoth Station community adheres to the following principles:

  • Open: Project Thoth is open source. See repository guidelines, below.
  • Welcoming and respectful: See Code of Conduct, below.
  • Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below.
  • Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles].

Code of Conduct

The Thoth Station community abides by [out code of conduct]:

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

As a member of the project, you represent the project and your fellow contributors. We value our community tremendously and we’d like to keep cultivating a friendly and collaborative environment for our contributors and users. We want everyone in the community to have [positive experiences].

Community groups

The project is comprised of the following types of subgroups:

  • Special Interest Groups, SIGs
    • Subprojects

SIGs

The project is organized primarily into Special Interest diff --git a/community/core/community/help-wanted.md/index.html b/community/core/community/help-wanted.md/index.html index da9672b106..8772f1ce99 100644 --- a/community/core/community/help-wanted.md/index.html +++ b/community/core/community/help-wanted.md/index.html @@ -20,7 +20,7 @@ - }Help Wanted and Good First Issue Labels | Thoth Station Help

Thoth Logo

Project Thoth

Help Wanted and Good First Issue Labels

Overview

We use two labels to identify issues that have been specifically created or selected for new contributors: help wanted and good first + }Help Wanted and Good First Issue Labels | Thoth Station Help

Thoth Logo

Project Thoth

Help Wanted and Good First Issue Labels

Overview

We use two labels to identify issues that have been specifically created or selected for new contributors: help wanted and good first issue. The good first issue label is a subset of the help wanted label, indicating that members have committed to providing extra assistance for new contributors. All good first issue items also have the help wanted diff --git a/community/core/community/liaisons.md/index.html b/community/core/community/liaisons.md/index.html index 3cbffbba7a..f6d0e88293 100644 --- a/community/core/community/liaisons.md/index.html +++ b/community/core/community/liaisons.md/index.html @@ -14,7 +14,7 @@ - }

Thoth Logo

Project Thoth

Liaisons

Each community group or SIG of Project Thoth assigned a Steering Committee + }

Thoth Logo

Project Thoth

Liaisons

Each community group or SIG of Project Thoth assigned a Steering Committee liaison. Liaisons act as a point of contact from steering, engage with their respective community groups to ensure they are healthy and facilitate communication.

Liaisons do not make decisions for the community group or on behalf of diff --git a/community/core/community/sig-devsecops/README.md/index.html b/community/core/community/sig-devsecops/README.md/index.html index dac1ca7287..044e7d0563 100644 --- a/community/core/community/sig-devsecops/README.md/index.html +++ b/community/core/community/sig-devsecops/README.md/index.html @@ -14,7 +14,7 @@ - }

Thoth Logo

Project Thoth

DevSecOps Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

DevSecOps Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. This SIG covers all the tools and supporting container images that deliver Thoth-Station applications, as well as the build pipelines and Continuous Integration systems that enable the automated builds. This includes the discussion related to the release process of the Thoth-Station applications, the build pipelines themselves, supporting container images, tooling, and architectural decisions.

The charter defines the scope and governance of the DevSecOps Special Interest Group.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing -subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-devsecops:

Notebooks

A set of base images that are useful for Data Science work

Pipelines

A set of base images and pipelines to build application container images

Services

Tooling and configuration to manage the releases of various Thoth services and components

Contribute to this page
\ No newline at end of file +subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-devsecops:

Notebooks

A set of base images that are useful for Data Science work

Pipelines

A set of base images and pipelines to build application container images

Services

Tooling and configuration to manage the releases of various Thoth services and components

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-devsecops/charter.md/index.html b/community/core/community/sig-devsecops/charter.md/index.html index a7c7356141..db19ef666d 100644 --- a/community/core/community/sig-devsecops/charter.md/index.html +++ b/community/core/community/sig-devsecops/charter.md/index.html @@ -14,8 +14,8 @@ - }
Thoth Logo

Project Thoth

SIG DevSecOps Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This SIG covers all the tools and supporting container images that deliver Thoth-Station + }

Thoth Logo

Project Thoth

SIG DevSecOps Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This SIG covers all the tools and supporting container images that deliver Thoth-Station applications, as well as the build pipelines and Continuous Integration systems that enable the automated builds.

This includes the discussion related to the release process of the Thoth-Station applications, the build pipelines themselves, supporting container images, tooling, -and architectural decisions.

In scope

  • Pipelines to build and publish application container images
  • Supporting container images
  • End-user oriented content about Thoth pipelines and supporting images
  • GitOps configurations to deploy the services
  • Release management for Thoth-Station

Out of scope

  • Operation of the clusters that host the services

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file +and architectural decisions.

In scope

  • Pipelines to build and publish application container images
  • Supporting container images
  • End-user oriented content about Thoth pipelines and supporting images
  • GitOps configurations to deploy the services
  • Release management for Thoth-Station

Out of scope

  • Operation of the clusters that host the services

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-observability/README.md/index.html b/community/core/community/sig-observability/README.md/index.html index e14a8b8727..981c5cf6dd 100644 --- a/community/core/community/sig-observability/README.md/index.html +++ b/community/core/community/sig-observability/README.md/index.html @@ -14,6 +14,6 @@ - }
Thoth Logo

Project Thoth

Observability Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

Observability Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. Work on all things that concern Observability! This includes the definition of metrics, monitoring, reporting and alerting.

The charter defines the scope and governance of the Observability Special Interest Group.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-observability:

Monitoring

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-observability/charter.md/index.html b/community/core/community/sig-observability/charter.md/index.html index 3594b174b3..6544f234a7 100644 --- a/community/core/community/sig-observability/charter.md/index.html +++ b/community/core/community/sig-observability/charter.md/index.html @@ -14,6 +14,6 @@ - }
Thoth Logo

Project Thoth

SIG Observability Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses + }

Thoth Logo

Project Thoth

SIG Observability Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

Work on all things that concerns Observability! This includes the definition of metrics, monitoring, reporting and alerting.

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-stack-guidance/README.md/index.html b/community/core/community/sig-stack-guidance/README.md/index.html index 738362ee6c..9c8284af9b 100644 --- a/community/core/community/sig-stack-guidance/README.md/index.html +++ b/community/core/community/sig-stack-guidance/README.md/index.html @@ -14,5 +14,5 @@ - }
Thoth Logo

Project Thoth

Stack Guidance Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

Stack Guidance Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. Work on recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information

The charter defines the scope and governance of the Stack Guidance Special Interest Group.

Leadership

Contact

Subprojects

The following subprojects are owned by sig-stack-guidance:

adviser

prescriptions

solver

storages

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-stack-guidance/charter.md/index.html b/community/core/community/sig-stack-guidance/charter.md/index.html index 10b95e7af1..e8510352e8 100644 --- a/community/core/community/sig-stack-guidance/charter.md/index.html +++ b/community/core/community/sig-stack-guidance/charter.md/index.html @@ -14,4 +14,4 @@ - }
Thoth Logo

Project Thoth

SIG Stack Guidance Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This includes the discussion related to recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information.

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

SIG Stack Guidance Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

This includes the discussion related to recommending the most effective, performant and secure software stack for user applications and on actively creating prescriptions and security related information.

Roles and Organization Management

This sig follows adheres to the Roles and Organization Management outlined in sig-governance.

Subproject Creation

SIG Chairs can create subprojects without requiring member votes.

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-user-experience/README.md/index.html b/community/core/community/sig-user-experience/README.md/index.html index d0084a4666..095b2a445b 100644 --- a/community/core/community/sig-user-experience/README.md/index.html +++ b/community/core/community/sig-user-experience/README.md/index.html @@ -14,6 +14,6 @@ - }
Thoth Logo

Project Thoth

User Experience Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. + }

Thoth Logo

Project Thoth

User Experience Special Interest Group

HIBERNATION NOTICE: This SIG is currently hibernating. If you are interested in reviving this SIG, please reach out to the Thoth team via an issue in the the core or support repository. The User Experience SIG focuses on the interaction points between end users and Thoth components.

The charter defines the scope and governance of the User Experience Special Interest Group.

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-user-experience:

jupyterlab-requirements

kebechet

s2i-thoth

thamos

user-api

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/sig-user-experience/charter.md/index.html b/community/core/community/sig-user-experience/charter.md/index.html index b1cacc9777..a1efd91fa2 100644 --- a/community/core/community/sig-user-experience/charter.md/index.html +++ b/community/core/community/sig-user-experience/charter.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

SIG User Experience Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses + }

Thoth Logo

Project Thoth

SIG User Experience Charter

This charter adheres to the conventions described in the Kubernetes Charter README and uses the Roles and Organization Management outlined in Kuberentes’ sig-governance. For all things taken from the Kubernetes community, we use scaled down variants, Kubernetes documents are references.

Scope

The goal of this SIG is to ensure that the entry points to Thoth provide a great user experience.

This includes the interaction with human users (be it though direct component diff --git a/community/core/community/wg-cnbi/README.md/index.html b/community/core/community/wg-cnbi/README.md/index.html index 92cfd2bfcd..6e8425054c 100644 --- a/community/core/community/wg-cnbi/README.md/index.html +++ b/community/core/community/wg-cnbi/README.md/index.html @@ -14,5 +14,5 @@ - }

Thoth Logo

Project Thoth

CNBi Working Group

HIBERNATION NOTICE: This WG is currently hibernating. If you are interested in reviving this WG, please reach out to the Thoth team via an issue in the the core or support repository. -The goal of this working group is to create a service that implements the backend side of the Custom Notebook Image (CNBi) MVP in the context of Open Data Hub (ODH).

The charter defines the scope and governance of the CNBi Working Group.

Stakeholder SIGs

  • SIG DevSecOps
  • SIG Stack Guidance
  • SIG User Experience

Organizers

  • Christoph Görn (@goern), Red Hat

Contact

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

CNBi Working Group

HIBERNATION NOTICE: This WG is currently hibernating. If you are interested in reviving this WG, please reach out to the Thoth team via an issue in the the core or support repository. +The goal of this working group is to create a service that implements the backend side of the Custom Notebook Image (CNBi) MVP in the context of Open Data Hub (ODH).

The charter defines the scope and governance of the CNBi Working Group.

Stakeholder SIGs

  • SIG DevSecOps
  • SIG Stack Guidance
  • SIG User Experience

Organizers

  • Christoph Görn (@goern), Red Hat

Contact

Contribute to this page
\ No newline at end of file diff --git a/community/core/community/wg-cnbi/charter.md/index.html b/community/core/community/wg-cnbi/charter.md/index.html index 5ffb5fa5d5..cca2a0bff1 100644 --- a/community/core/community/wg-cnbi/charter.md/index.html +++ b/community/core/community/wg-cnbi/charter.md/index.html @@ -14,4 +14,4 @@ - }
Thoth Logo

Project Thoth

WG Custom Notebook Image (CNBi) Charter

The goal of this working group (WG) is to design and implement an MVP for the backend side of the Custom Notebook Image (CNBi) functionality of Open Data Hub (ODH).

The WG is a continuation of the work of the BYON WG. The work produced by the working group aims at meeting the requirements specified in the RHODS epics about the functionality, including:

For reference, deliverables for phase 1 (BYON) were tracked in the byon repository and its corresponding project planning board.

Scope

The focus of this WG is on the backend components that handle the creation, validation, and importing of container images for use into ODH, as well as the software stack guidance service provided to the users of these images.

In scope

  • The CNBi operator
  • Tekton Pipeline definitions that implement the CNBi / BYON functionality
  • Thoth APIs that contribute to the requirements of the CNBi functionality on ODH
  • Coordination with ODH in integrating the funtcionality
  • Deployment of the PoC and coordination with Operate First and OS-Climate on its usage

Out of scope

  • ODH User Interface design and implementation

Stakeholders

  • Thoth SIGs:
    • DevSecOps
    • Stack Guidance
    • User Experience
  • ODH SIGs:
    • ML-DevExp
    • Platform

Deliverables

  • Documentation of the design of the backend, the components involved, the interactions between them, and the interface between ODH and the backend.
  • An evolution of the meteor operator that acts as the main controller for the CNBi functionality.
  • A set of Tekton / OpenShift pipelines definitions that implement the functionality.
  • A working PoC of the operator and pipelines, with ODH integration when available, ready to use by a target group: the OS-Climate project.

Disband criteria

If stakeholder SIGs and the WG decide all features described in the In Scope section are complete and no more discussions and investigations are needed in this WG, they may decide to disband this WG.

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

WG Custom Notebook Image (CNBi) Charter

The goal of this working group (WG) is to design and implement an MVP for the backend side of the Custom Notebook Image (CNBi) functionality of Open Data Hub (ODH).

The WG is a continuation of the work of the BYON WG. The work produced by the working group aims at meeting the requirements specified in the RHODS epics about the functionality, including:

For reference, deliverables for phase 1 (BYON) were tracked in the byon repository and its corresponding project planning board.

Scope

The focus of this WG is on the backend components that handle the creation, validation, and importing of container images for use into ODH, as well as the software stack guidance service provided to the users of these images.

In scope

  • The CNBi operator
  • Tekton Pipeline definitions that implement the CNBi / BYON functionality
  • Thoth APIs that contribute to the requirements of the CNBi functionality on ODH
  • Coordination with ODH in integrating the funtcionality
  • Deployment of the PoC and coordination with Operate First and OS-Climate on its usage

Out of scope

  • ODH User Interface design and implementation

Stakeholders

  • Thoth SIGs:
    • DevSecOps
    • Stack Guidance
    • User Experience
  • ODH SIGs:
    • ML-DevExp
    • Platform

Deliverables

  • Documentation of the design of the backend, the components involved, the interactions between them, and the interface between ODH and the backend.
  • An evolution of the meteor operator that acts as the main controller for the CNBi functionality.
  • A set of Tekton / OpenShift pipelines definitions that implement the functionality.
  • A working PoC of the operator and pipelines, with ODH integration when available, ready to use by a target group: the OS-Climate project.

Disband criteria

If stakeholder SIGs and the WG decide all features described in the In Scope section are complete and no more discussions and investigations are needed in this WG, they may decide to disband this WG.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/ROADMAP.md/index.html b/community/core/docs/ROADMAP.md/index.html index 5625f0a230..ec65d75b9e 100644 --- a/community/core/docs/ROADMAP.md/index.html +++ b/community/core/docs/ROADMAP.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Thoth Roadmap

After the current and coordinated release of Thoth’s components, we started this document to outline our + }

Thoth Logo

Project Thoth

Thoth Roadmap

After the current and coordinated release of Thoth’s components, we started this document to outline our current focus areas and the major items we are working on.

For a more detailed overview of our current activities, have a look at our GitHub projects. We use them to plan our sprints.

Informative Advice

Based on a command line tool and our GitHub App we will extend the advice we give to human developers. This @@ -34,4 +34,4 @@ Tekton catalog, and enables Python application developers to integrate Thoth Service consuming tasks (for example a Python module provenance check, or Security report) into their OpenShift and Tekton Pipelines.

Jupyter Requirements Management

Jupyter tools focused on the Data Scientist workflow have been created to help them with dependencies management:

They feature similar functionality as thamos, but embedding the dependencies and the locked dependencies within the meta information -of the Jupyter Notebook file itself together with creating dependencies files in the requested requirement formats.

Contribute to this page
\ No newline at end of file +of the Jupyter Notebook file itself together with creating dependencies files in the requested requirement formats.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html b/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html index d695424d1e..f90aa4b11b 100644 --- a/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html +++ b/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md/index.html @@ -14,4 +14,4 @@ - }
Thoth Logo

Project Thoth

Use Markdown Architectural Decision Records

Context and Problem Statement

We want to record architectural decisions made in Project Thoth. Which format and structure should these records follow?

Considered Options

Decision Outcome

Chosen option: “MADR 2.1.2”, because

  • Implicit assumptions should be made explicit.

    Design documentation is important to enable people understanding the decisions later on.

    See also A rational design process: How and why to fake it.

  • The MADR format is lean and fits our development style.

  • The MADR structure is comprehensible and facilitates usage & maintenance.

  • The MADR project is vivid.

  • Version 2.1.2 is the latest one available when starting to document ADRs.

Contribute to this page
\ No newline at end of file + }
Thoth Logo

Project Thoth

Use Markdown Architectural Decision Records

Context and Problem Statement

We want to record architectural decisions made in Project Thoth. Which format and structure should these records follow?

Considered Options

Decision Outcome

Chosen option: “MADR 2.1.2”, because

  • Implicit assumptions should be made explicit.

    Design documentation is important to enable people understanding the decisions later on.

    See also A rational design process: How and why to fake it.

  • The MADR format is lean and fits our development style.

  • The MADR structure is comprehensible and facilitates usage & maintenance.

  • The MADR project is vivid.

  • Version 2.1.2 is the latest one available when starting to document ADRs.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html b/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html index 53173721df..cf882d9259 100644 --- a/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html +++ b/community/core/docs/adr/0001-use-gpl3-as-license.md/index.html @@ -14,7 +14,7 @@ - }
Thoth Logo

Project Thoth

Use GNU GPL as license

Everything needs to be licensed, otherwise the default copyright laws apply. + }

Thoth Logo

Project Thoth

Use GNU GPL as license

Everything needs to be licensed, otherwise the default copyright laws apply. For instance, in Germany that means users may not alter anything without explicitly asking for permission. For more information see https://help.github.com/articles/licensing-a-repository/.

We want to have all source code related to Project Thoth to be used without any hassle and as free as possible, so that -users can just execute and enjoy the four freedoms.

Considered Options

Decision Outcome

Chosen option: “GNU GPL”, because this license supports a strong copyleft model.

Contribute to this page
\ No newline at end of file +users can just execute and enjoy the four freedoms.

Considered Options

Decision Outcome

Chosen option: “GNU GPL”, because this license supports a strong copyleft model.

Contribute to this page
\ No newline at end of file diff --git a/community/core/docs/adr/0002-release-policy.md/index.html b/community/core/docs/adr/0002-release-policy.md/index.html index e24a3a4bd9..881d031a00 100644 --- a/community/core/docs/adr/0002-release-policy.md/index.html +++ b/community/core/docs/adr/0002-release-policy.md/index.html @@ -14,9 +14,9 @@ - }
Thoth Logo

Project Thoth

Project Thoth Release Policy

  • Status: proposed
  • Date: 2020-Nov-04

Technical Story: As an Open Source project, we want to document the policies and guideline on how we create a new + }

Thoth Logo

Project Thoth

Project Thoth Release Policy

  • Status: proposed
  • Date: 2020-Nov-04

Technical Story: As an Open Source project, we want to document the policies and guideline on how we create a new release.

Context and Problem Statement

Project Thoth itself consists of many components all having their own release cycles and delivery artifacts such as container image or Python libraries.

Considered Options

  • a monolithic, coordinated release of all components by creating a tag within the thoth-application repository
  • have a rolling release, and no tags on any repository

Decision Outcome

Chosen option: we do a monolithic, coordinated release, because it will enable us to have a release at the project/product level while maintianing freedom of others to update.

Positive Consequences

  • users have a clear base line of versions, these versions have been tested with each other and have undergone integration testing.
  • a release can be referenced from documents, so that operational procedures have a clear relationship with component -versions being used
  • we can maintain sets of different versions for different deployment environments
  • we can provide a version string with each API provided by the project

Negative Consequences

  • A release might not contain the latest versions of components
Contribute to this page
\ No newline at end of file +versions being used
  • we can maintain sets of different versions for different deployment environments
  • we can provide a version string with each API provided by the project

    • Negative Consequences

    • A release might not contain the latest versions of components
    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html b/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html index 53ba186e9a..205198ca67 100644 --- a/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html +++ b/community/core/docs/adr/0003-decommision-qeb-hwt.md/index.html @@ -14,7 +14,7 @@ - }
    Thoth Logo

    Project Thoth

    Decommission Qeb-Hwt GitHub App

    Technical Story: Decommision Qeb-Hwt GitHub App

    Context and Problem Statement

    Qeb-Hwt is a GitHub Application which adds thamos advise based output to + }

    Thoth Logo

    Project Thoth

    Decommission Qeb-Hwt GitHub App

    Technical Story: Decommision Qeb-Hwt GitHub App

    Context and Problem Statement

    Qeb-Hwt is a GitHub Application which adds thamos advise based output to Pull Requests as a check. This functionality could be integrated into https://github.com/marketplace/khebhut and complexity and maintain costs.

    Decision Drivers

    • cost of maintaining Qeb-Hwt code and app
    • redundancy of infrastructure

    Considered Options

    • keep and maintain Qeb-Hwt
    • merge function into Khebhut

    Decision Outcome

    Chosen option: “merge function into Khebhut”, because we can reduce the cost of maintaining our software infrastructure -by reducing redundancy.

    Contribute to this page
    \ No newline at end of file +by reducing redundancy.

    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0004-naming-convention-images.md/index.html b/community/core/docs/adr/0004-naming-convention-images.md/index.html index 58abfaea1c..ef1d4998e3 100644 --- a/community/core/docs/adr/0004-naming-convention-images.md/index.html +++ b/community/core/docs/adr/0004-naming-convention-images.md/index.html @@ -14,11 +14,11 @@ - }
    Thoth Logo

    Project Thoth

    Project Thoth Naming Convention Schema for Images

    • Status: proposed
    • Date: 2021-Jun-17

    Technical Story: As Thoth goal to provide curated stack and images, it would be nice to have a convention for naming of the images.

    Context and Problem Statement

    Image names are important for branding and let others identify easily a specific image they need. For example “I want to work on computer vision project with Tensorflow, what stack and image should I use?” Having a trusted well maintained source of images with clean naming convention can help on that.

    Considered Options

    • s2i-{application} standard name currently, but not everyone knows what S2I is.
    • odh-{application} for branding/marketing having ODH in front seems to be the best solution, in this way the name will be shorter as well.
    • ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.

    These names are for the core repository name, then overlays will allow for combinations of libraries based on other criteria, for example ml_framework and/or hardware:

    `ps-nlp`
+      }
    Thoth Logo
    Project Thoth
    Project Thoth Naming Convention Schema for Images
    • Status: proposed
    • Date: 2021-Jun-17
    Technical Story: As Thoth goal to provide curated stack and images, it would be nice to have a convention for naming of the images.
    Context and Problem Statement
    Image names are important for branding and let others identify easily a specific image they need. For example “I want to work on computer vision project with Tensorflow, what stack and image should I use?” Having a trusted well maintained source of images with clean naming convention can help on that.
    Considered Options
    • s2i-{application} standard name currently, but not everyone knows what S2I is.
    • odh-{application} for branding/marketing having ODH in front seems to be the best solution, in this way the name will be shorter as well.
    • ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.
    These names are for the core repository name, then overlays will allow for combinations of libraries based on other criteria, for example ml_framework and/or hardware:
    `ps-nlp`
 ├── overlays                    # Overlays structure for builds
 │   ├── ps-nlp-tensorflow          # NLP image with TensorFlow ML framework
 │   ├── ps-nlp-tensorflow-gpu      # NLP image with TensorFlow ML framework for GPU
 │   ├── ps-nlp-pytorch             # NLP image with Pytorch ML framework
 │   ├── ps-nlp-pytorch-gpu         # NLP image with Pytorch ML framework for GPU
 │   └── ps-nlp-scikit-learn        # NLP image with Scikit-learn ML framework
-└── ...
    Decision Outcome
    Selected option: ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.
    Positive Consequences 
    • users can immediately select an image based on the application they want.
    • using overlays we can have a variety of combination, not just for ml_framework
    Negative Consequences 
    • N/A
    Contribute to this page
    
\ No newline at end of file
+└── ...

    Decision Outcome

    Selected option: ps-{application} as it shows what our intention is: we want to provide a curated/predictable software stack, it might be used by ODH or RHODS or others, it might use S2I or other technology. Moreover helps from pipeline creation point of view, because the length of repo name on quay can crate issues.

    Positive Consequences

    • users can immediately select an image based on the application they want.
    • using overlays we can have a variety of combination, not just for ml_framework

    Negative Consequences

    • N/A
    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html b/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html index e8e7ea4ac9..2f99eb7073 100644 --- a/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html +++ b/community/core/docs/adr/0005-automatically-bump-container-image-versions.md/index.html @@ -14,4 +14,4 @@ - }
    Thoth Logo

    Project Thoth

    Automatically bump the version of base images used to generate container images

    • Status: proposed
    • Date: 2022-02-15

    Technical Story: As a maintainer of Thoth, I would like to automatically update the version of the base images used to generate new container images of some components (see: https://github.com/thoth-station/kebechet/issues/991)

    Context and Problem Statement

    When new base image versions used to genereate container images for Thoth components are released on Quay, it would be practical to update them automatically instead of manually opening Bump <component name> to vx.y.z in <environment> pull requests in the concerned repositories (Example: https://github.com/thoth-station/thoth-application/pull/2314).

    Considered Options

    • Implement a simple Python script to bump the base image versions used to deliver container images in .aicoe-ci.yaml, .thoth.yaml or similar files for eventual uses outside of the project.
      • 1) Integrate this script in the AICoE-CI pipeline logic
      • 2) Integrate this script in Kebechet

    Decision Outcome

    Chosen option: 1). For the moment, this script has been integrated in the AICoE-CI pipeline logic, but it could eventually be reused in Kebechet if needed.

    Positive Consequences

    • Keeping the base image versions we use up-to-date for active repositories.
    • Base image version updates are made automatically, which is less error-prone and time-consuming for developers compared to making the update manually.

    Links

    Contribute to this page
    \ No newline at end of file + }
    Thoth Logo

    Project Thoth

    Automatically bump the version of base images used to generate container images

    • Status: proposed
    • Date: 2022-02-15

    Technical Story: As a maintainer of Thoth, I would like to automatically update the version of the base images used to generate new container images of some components (see: https://github.com/thoth-station/kebechet/issues/991)

    Context and Problem Statement

    When new base image versions used to genereate container images for Thoth components are released on Quay, it would be practical to update them automatically instead of manually opening Bump <component name> to vx.y.z in <environment> pull requests in the concerned repositories (Example: https://github.com/thoth-station/thoth-application/pull/2314).

    Considered Options

    • Implement a simple Python script to bump the base image versions used to deliver container images in .aicoe-ci.yaml, .thoth.yaml or similar files for eventual uses outside of the project.
      • 1) Integrate this script in the AICoE-CI pipeline logic
      • 2) Integrate this script in Kebechet

    Decision Outcome

    Chosen option: 1). For the moment, this script has been integrated in the AICoE-CI pipeline logic, but it could eventually be reused in Kebechet if needed.

    Positive Consequences

    • Keeping the base image versions we use up-to-date for active repositories.
    • Base image version updates are made automatically, which is less error-prone and time-consuming for developers compared to making the update manually.

    Links

    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html b/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html index 8807a67ee0..6ff7f7d268 100644 --- a/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html +++ b/community/core/docs/adr/0005-obtimizing-keb-runs.md/index.html @@ -14,8 +14,8 @@ - }
    Thoth Logo

    Project Thoth

    {short title of solved problem and solution}

    • Status: proposed
    • Deciders: @KPostOffice @fridex @cgoern
    • Date: 2022-3-15 when the decision was last updated}

    Technical Story: Kebechet#873

    Context and Problem Statement

    Kebechet is being run too often and is eagerly eating resources in cluster. We need to pare down how often we spin up + }

    Thoth Logo

    Project Thoth

    {short title of solved problem and solution}

    • Status: proposed
    • Deciders: @KPostOffice @fridex @cgoern
    • Date: 2022-3-15 when the decision was last updated}

    Technical Story: Kebechet#873

    Context and Problem Statement

    Kebechet is being run too often and is eagerly eating resources in cluster. We need to pare down how often we spin up pods to do repository management.

    Decision Drivers

    • Less pods being spun up.
    • Reduce frequency of reaching GitHub API quota limit

    Considered Options

    • Option 1: Filter web-hooks in thoth-user-api
    • Option 2: Create Kebechet deployment receives web-hooks and only runs specific manager(s) depending on contents
    • Option 3: Create individual repositories and GitHub applications for each manager
    • Option 4: create GitHub app for each repo and choose auth at run time

    Decision Outcome

    Chosen option: “option 3”, because we can use existing bot frameworks and github event handlers such as gidgethub(Python) and probot(JavaScript). This should help reduce cluster load as pods will be shorter lived and less frequent, however, it does require multiple small deployments for handling web-hooks.

    Implementing option 2 and option 4 might be another good solution.

    Positive Consequences

    • Reduced resource consumption
    • More apps means more quota
    • Each app’s behavior is well defined. It’s at times unclear what “Kebechet” is

    Negative Consequences

    • Follow up decisions required: “What technologies do we use?”, “How do we manage configuration?”
    • Transition from maintaining list of managers to installing individual managers

    Pros and Cons of the Options

    Option 1: Filter web-hooks in thoth-user-api

    • Good, because it requires minimal upfront work
    • Bad, because it introduces tight coupling between Kebechet and user-api
    • Bad, because GitHub already only sends a subset of events and it is likely that we would not see a major decrease in -resource consumption.

    Option 2: Create Kebechet deployment receives web-hooks and only runs specific manager(s) depending on contents

    • Good, because it allows for thorough processing of events prior to pod being spun up
    • Good, it can still run multiple bots in the same pod (depends on implementation)
    • ?, Preserves Kebechet name recognition (may obfuscate functionality)
    • Bad, does not help with reducing GitHub API quota consumption

    Option 3: Create individual repositories and GitHub applications for each manager

    • Good, because it creates more apps which effectively increases the total API limit
    • Good, segregating functionality helps users understand what they are installing
    • Good, workloads can be very selectively run through thorough web-hook processing
    • Bad, many small deployments

    Option 2&4: Create Keb deployment and Individual apps

    • Good, because it creates more apps which effectively increases the total API limit
    • Good?, single deployment
    • Good, workloads can be very selectively run through thorough web-hook processing
    • Bad, installation story becomes unclear
    Contribute to this page
    \ No newline at end of file +resource consumption.

    Option 2: Create Kebechet deployment receives web-hooks and only runs specific manager(s) depending on contents

    • Good, because it allows for thorough processing of events prior to pod being spun up
    • Good, it can still run multiple bots in the same pod (depends on implementation)
    • ?, Preserves Kebechet name recognition (may obfuscate functionality)
    • Bad, does not help with reducing GitHub API quota consumption

    Option 3: Create individual repositories and GitHub applications for each manager

    • Good, because it creates more apps which effectively increases the total API limit
    • Good, segregating functionality helps users understand what they are installing
    • Good, workloads can be very selectively run through thorough web-hook processing
    • Bad, many small deployments

    Option 2&4: Create Keb deployment and Individual apps

    • Good, because it creates more apps which effectively increases the total API limit
    • Good?, single deployment
    • Good, workloads can be very selectively run through thorough web-hook processing
    • Bad, installation story becomes unclear
    Contribute to this page
    \ No newline at end of file diff --git a/community/core/docs/adr/0006-thoth-github-action.md/index.html b/community/core/docs/adr/0006-thoth-github-action.md/index.html index af23157eaf..ad78237de0 100644 --- a/community/core/docs/adr/0006-thoth-github-action.md/index.html +++ b/community/core/docs/adr/0006-thoth-github-action.md/index.html @@ -14,7 +14,7 @@ - }
    Thoth Logo

    Project Thoth

    Thoth GitHub Action ADR

    • Status: proposed
    • Date: 2022-May-16

    Technical Story: we would like to create a new Thoth integration via a GitHub Acttion to advise users on the dependencies used in their repositories.

    Context and Problem Statement

    The Thoth GitHub Action was originally supposed to be implemented to advise on the dependencies present in the Packit repository, but should be extendable to other repositories as well with different requirement formats (pip, pipenv…).

    The primary goal of this Action would be to advise on the security aspects of dependencies of a project by providing a mean to:

    • Identify CVE present in the versions of the packages used in the project, so that users can eventually block Pull Requests introducing vulnerable dependencies
      • Comment on the Pull Requests with a list of CVE found for the current package versions
      • Log all stack info in the action workflow
      • Provide a link to Thoth Search UI to browse the advise results
      • Fail the workflow to eventually block the Pull Request
    • Get security insights on the dependency stack introduced by a Pull Request by returning the content of the stack info (Security Scorecards data, warnings, info, etc)
      • Log stack info in the action workflow
      • Provide a link to Thoth Search UI to browse the advise results
    • Score the current dependency stack and allow repository maintainers to display this score as a badge in the landing page of their repository as an indicator of application dependencies health
      • Get the software stack score provided in the advise result and normalize it if needed
      • Create a status badge for the workflow running the Thoth GitHub Action indicating the score of the software stack on the merge of a Pull Request modifying the requirements file.

    Considered Options

    Setting up the Action on a repository

    name: User CI workflow
+      }
    Thoth Logo
    Project Thoth
    Thoth GitHub Action ADR
    • Status: proposed
    • Date: 2022-May-16
    Technical Story: we would like to create a new Thoth integration via a GitHub Acttion to advise users on the dependencies used in their repositories.
    Context and Problem Statement
    The Thoth GitHub Action was originally supposed to be implemented to advise on the dependencies present in the Packit repository, but should be extendable to other repositories as well with different requirement formats (pip, pipenv…).
    The primary goal of this Action would be to advise on the security aspects of dependencies of a project by providing a mean to:
    • Identify CVE present in the versions of the packages used in the project, so that users can eventually block Pull Requests introducing vulnerable dependencies
      • Comment on the Pull Requests with a list of CVE found for the current package versions
      • Log all stack info in the action workflow
      • Provide a link to Thoth Search UI to browse the advise results
      • Fail the workflow to eventually block the Pull Request
    • Get security insights on the dependency stack introduced by a Pull Request by returning the content of the stack info (Security Scorecards data, warnings, info, etc)
      • Log stack info in the action workflow
      • Provide a link to Thoth Search UI to browse the advise results
    • Score the current dependency stack and allow repository maintainers to display this score as a badge in the landing page of their repository as an indicator of application dependencies health
      • Get the software stack score provided in the advise result and normalize it if needed
      • Create a status badge for the workflow running the Thoth GitHub Action indicating the score of the software stack on the merge of a Pull Request modifying the requirements file.
    Considered Options
    Setting up the Action on a repository
    name: User CI workflow
 on:
   push:
     paths:
diff --git a/community/core/docs/adr/0007-scorecard-metrics.md/index.html b/community/core/docs/adr/0007-scorecard-metrics.md/index.html
index 4043f3a764..cef3ddd7ca 100644
--- a/community/core/docs/adr/0007-scorecard-metrics.md/index.html
+++ b/community/core/docs/adr/0007-scorecard-metrics.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Aggregating OpenSSF Scorecard metrics to compute software stack quality scores
    • Status: proposed
    • Date: 2022-August-1
    Technical Story: Aggregate OpenSSF Scorecard metrics on a package release update to compute software stack quality scores.
    Context and Problem Statement
    As part of advise output improvements mentioned in , we would like to aggregate Security Scorecards data on a new package release to provide software stack quality metrics with regards to the global quality of packages that can be found in Thoth’s Database. These metrics would inform the user about the health of a project dependencies and provide a software stack score (on a 0-100 scale or A,B,C…) based on Scorecard data.
    Note: The architecture diagram below supposes that the OSSF Scorecards dataset available on BigQuery will expose metrics by package release instead of repository head commit SHA as it is currently the case. However if this feature is not going to be implemented on the Scorecards project side, we will need to handle the head commit SHA to release association logic by ourselves and thus revisit the diagram to include appropriate calls to the GitHub API and additional computations.
    The data aggregation and score computation logic would be implemented as follows:
    • With each package-releases-job run, aggregate data about the latest package release and corresponding Scorecards data retrieved from BigQuery
    • Update a new database table package_scorecard_metrics with columns for the package name and version and Scorecards Check (1 if the check passed, 0 otherwise). Eventually add a column for a global confidence computed from all Scorecards confidence for a project
    • Schedule a job to compute a global package quality score from the previously aggregated data and store this score in the database
    • Make this data available in prescriptions: update existing Scorecard prescriptions with the package version and create new prescriptions for other packages via prescriptions-refresh-job
    • Implement the scoring logic available for relevant Thoth endpoints
    • When a request is made to the relevant endpoint or a parameter is passed to ask for software stack scoring when computing an advise, output the computed metrics about the user’s software stack quality
    Architectural diagram
    Scorecard metrics aggregation logic diagram
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    Aggregating OpenSSF Scorecard metrics to compute software stack quality scores
    • Status: proposed
    • Date: 2022-August-1
    Technical Story: Aggregate OpenSSF Scorecard metrics on a package release update to compute software stack quality scores.
    Context and Problem Statement
    As part of advise output improvements mentioned in , we would like to aggregate Security Scorecards data on a new package release to provide software stack quality metrics with regards to the global quality of packages that can be found in Thoth’s Database. These metrics would inform the user about the health of a project dependencies and provide a software stack score (on a 0-100 scale or A,B,C…) based on Scorecard data.
    Note: The architecture diagram below supposes that the OSSF Scorecards dataset available on BigQuery will expose metrics by package release instead of repository head commit SHA as it is currently the case. However if this feature is not going to be implemented on the Scorecards project side, we will need to handle the head commit SHA to release association logic by ourselves and thus revisit the diagram to include appropriate calls to the GitHub API and additional computations.
    The data aggregation and score computation logic would be implemented as follows:
    • With each package-releases-job run, aggregate data about the latest package release and corresponding Scorecards data retrieved from BigQuery
    • Update a new database table package_scorecard_metrics with columns for the package name and version and Scorecards Check (1 if the check passed, 0 otherwise). Eventually add a column for a global confidence computed from all Scorecards confidence for a project
    • Schedule a job to compute a global package quality score from the previously aggregated data and store this score in the database
    • Make this data available in prescriptions: update existing Scorecard prescriptions with the package version and create new prescriptions for other packages via prescriptions-refresh-job
    • Implement the scoring logic available for relevant Thoth endpoints
    • When a request is made to the relevant endpoint or a parameter is passed to ask for software stack scoring when computing an advise, output the computed metrics about the user’s software stack quality
    Architectural diagram
    Scorecard metrics aggregation logic diagram
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/adr/template.md/index.html b/community/core/docs/adr/template.md/index.html
index 40c54220d9..850c65f63e 100644
--- a/community/core/docs/adr/template.md/index.html
+++ b/community/core/docs/adr/template.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    [short title of solved problem and solution]
    • Status: [proposed | rejected | accepted | deprecated | … | superseded by ADR-0005] 
    • Deciders: [list everyone involved in the decision] 
    • Date: [YYYY-MM-DD when the decision was last updated] 
    Technical Story: [description | ticket/issue URL] 
    Context and Problem Statement
    [Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
    Decision Drivers 
    • [driver 1, e.g., a force, facing concern, …]
    • [driver 2, e.g., a force, facing concern, …]
    • … 
    Considered Options
    • [option 1]
    • [option 2]
    • [option 3]
    • … 
    Decision Outcome
    Chosen option: ”[option 1]”, because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
    Positive Consequences 
    • [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
    • …
    Negative Consequences 
    • [e.g., compromising quality attribute, follow-up decisions required, …]
    • …
    Pros and Cons of the Options 
    [option 1]
    [example | description | pointer to more information | …] 
    • Good, because [argument a]
    • Good, because [argument b]
    • Bad, because [argument c]
    • … 
    [option 2]
    [example | description | pointer to more information | …] 
    • Good, because [argument a]
    • Good, because [argument b]
    • Bad, because [argument c]
    • … 
    [option 3]
    [example | description | pointer to more information | …] 
    • Good, because [argument a]
    • Good, because [argument b]
    • Bad, because [argument c]
    • … 
    Links 
    • [Link type][Link to ADR] 
    • … 
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    [short title of solved problem and solution]
    • Status: [proposed | rejected | accepted | deprecated | … | superseded by ADR-0005] 
    • Deciders: [list everyone involved in the decision] 
    • Date: [YYYY-MM-DD when the decision was last updated] 
    Technical Story: [description | ticket/issue URL] 
    Context and Problem Statement
    [Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
    Decision Drivers 
    • [driver 1, e.g., a force, facing concern, …]
    • [driver 2, e.g., a force, facing concern, …]
    • … 
    Considered Options
    • [option 1]
    • [option 2]
    • [option 3]
    • … 
    Decision Outcome
    Chosen option: ”[option 1]”, because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
    Positive Consequences 
    • [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
    • …
    Negative Consequences 
    • [e.g., compromising quality attribute, follow-up decisions required, …]
    • …
    Pros and Cons of the Options 
    [option 1]
    [example | description | pointer to more information | …] 
    • Good, because [argument a]
    • Good, because [argument b]
    • Bad, because [argument c]
    • … 
    [option 2]
    [example | description | pointer to more information | …] 
    • Good, because [argument a]
    • Good, because [argument b]
    • Bad, because [argument c]
    • … 
    [option 3]
    [example | description | pointer to more information | …] 
    • Good, because [argument a]
    • Good, because [argument b]
    • Bad, because [argument c]
    • … 
    Links 
    • [Link type][Link to ADR] 
    • … 
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/intern-projects/Inferring-package-names-out-of-Python-imports.md/index.html b/community/core/docs/intern-projects/Inferring-package-names-out-of-Python-imports.md/index.html
index 11fca1cfc1..66541bfa31 100644
--- a/community/core/docs/intern-projects/Inferring-package-names-out-of-Python-imports.md/index.html
+++ b/community/core/docs/intern-projects/Inferring-package-names-out-of-Python-imports.md/index.html
@@ -14,5 +14,5 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Inferring package names out of Python imports
    Assigned intern: Tlegen
+      }
    Thoth Logo
    Project Thoth
    Inferring package names out of Python imports
    Assigned intern: Tlegen
 Assigned mentor: Francesco Murdaca
    Project Goal
    The goal of this project is to create an automated mechanism for inferring package names out of their imports.
    Deliverables
    An endpoint on User API that can suggest package names based on an import supplied.
    Prerequisites for Team Members
    Please check you have all the following:
    • Be part of Thoth-Station Google Chat Room
    • Be part of Thoth scrum meetings
    • Access to GitHub using your GitHub your account: Thoth Station
    Project outline
    1. Welcome to the Thoth Station!
    2. Get familiar with how we work
      1. Get familiar with team members
    3. Get familiar with thoth-solver, study its output
    4. Get familiar with invectio, study its output
    5. Check available results of thoth-solver runs that are present on Ceph, use Jupyter Notebooks to explore the dataset
      1. Make sure you have access to Ceph and data are readable
    6. Check packages in the ecosystem that provide modules under a different name than the package name itself
      1. See import sklearn vs pip install scikit-learn
    7. Design and propose a solution that can automatically derive module names
      1. No need to strictly use thoth-solver data if a better solution is found
      2. Mind “namespaced” modules
    8. Write a program that can automatically derive package names out of imports
      1. Design a database that can hold such information, if needed
      2. Design an approach to sync required data into the database
    9. Get familiar with Thoth deployment, design and propose integration of your application into the system
      1. Study Argo workflows, check how the proposed solution can be integrated into the system (e.g. run it after solver finishes)
    10. Integrate your solution into Thoth
      1. Adjust templates in thoth-station/thoth-application repository
      2. Provide an endpoint on user-api that can give information to users about imports Input: import Output: Package name (package required to be installed so that import works)
    11. Create an integration test verifying the endpoint implemented
    Stretch goals
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/intern-projects/classify-errors-produced-during-installation-of-python-modules.md/index.html b/community/core/docs/intern-projects/classify-errors-produced-during-installation-of-python-modules.md/index.html
index 14c08f7c33..a0b2d8cb3c 100644
--- a/community/core/docs/intern-projects/classify-errors-produced-during-installation-of-python-modules.md/index.html
+++ b/community/core/docs/intern-projects/classify-errors-produced-during-installation-of-python-modules.md/index.html
@@ -14,5 +14,5 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Classify errors produced during installation of Python modules
    Assigned intern: Bjoern Hasemann
+      }
    Thoth Logo
    Project Thoth
    Classify errors produced during installation of Python modules
    Assigned intern: Bjoern Hasemann
 Assigned mentor: Frido Pokorny
    Project Goal
    The goal of this project is to create a classifier that can classify errors reported during Python package installation. This classifier will be used in thoth-solver errors classification as well as in build analysis.
    Deliverables
    A Jupyter Notebook, later an CLI application, that can automatically classify error logs.
    Prerequisites for Team Members
    Please check you have all the following:
    • Access to Red Hat network
    • Access to GMail and Google Chat
      • Be part of Thoth-Station Google Chat Room
    • Be part of Thoth scrum meetings
      • You should receive an invite to a Google calendar Event
    • Access to GitHub using your GitHub your account
      • Thoth Station
    • Get access to JupyterHub
    Project outline
    1. Welcome to the Thoth Station!
      1. get familiar with team members
    2. Get familiar with thoth-solver [1], study its output
    3. Get familiar with micropipenv [2], study its output
    4. Get familiar with Amun service and inspections that are run there [4]
    5. Get access to solver dataset that is present on Ceph, explore the dataset using Jupyter Notebooks, create a batch of solver documents that capture failed solver runs with the error log reported
      1. You can also check available datasets on Kaggle [3] and GitHub [4]
    6. Similarly to the previous point, get access to inspection dataset
    7. Design and propose a solution that will automatically or semi-automatically classify errors, discuss the proposed solution with the team
      1. Discuss algorithm used
      2. Discuss how the solution can be applied to solver errors and errors in inspection build logs
    8. Create a generic Jupyter Notebook that accepts a list of solver documents and classifies them automatically
      1. Check already implemented classifier, propose improvements or reuse parts
    9. Create a generic Jupyter Notebook that accepts a list of inspections and automatically classifies them
      1. Discuss how the error is extracted
      2. Study buildlog-parser, think of its reusability [6]
    10. Discuss correctness and applicability of the proposed solution
    Stretch goals:
    • Study solver workflow and how it works in Thoth deployment, try to come up with a design on how to integrate your solution into solver workflow
    • Integrate your solution into solver workflow
    • Extend error classification to classify also errors specific to Amun inspections (e.g. failed push of images)
    • Study buildlog analysis endpoint and build analysis workflow
    • Integrate your solution into buildlog analysis workflow
    References
    1. https://github.com/thoth-station/solver/
    2. https://github.com/thoth-station/micropipenv
    3. https://www.kaggle.com/thothstation/thoth-solver-dataset-v10
    4. https://github.com/thoth-station/datasets
    5. https://github.com/thoth-station/amun-api/
    6. https://github.com/thoth-station/buildlog-parser
    7. https://github.com/thoth-station/report-processing
    Previous attempts to learn from
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/intern-projects/detecting-lincenses-of-python-modules.md/index.html b/community/core/docs/intern-projects/detecting-lincenses-of-python-modules.md/index.html
index f0d595a8ea..e88735d43d 100644
--- a/community/core/docs/intern-projects/detecting-lincenses-of-python-modules.md/index.html
+++ b/community/core/docs/intern-projects/detecting-lincenses-of-python-modules.md/index.html
@@ -14,7 +14,7 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Detect license of Python modules
    Assigned intern: Viliam Podhajecký
+      }
    Thoth Logo
    Project Thoth
    Detect license of Python modules
    Assigned intern: Viliam Podhajecký
 Assigned mentor: Frido Pokorny
    Project Goal
    The goal of this project is to detect license of Python modules.
    Deliverables
    A Jupyter Notebook, later an CLI application, that can automatically detect
 license information of Python modules. This CLI application is then integrated
 into the system and automatically detects license information of Python modules
@@ -26,4 +26,4 @@
 field or check license specific trove classifiers) - see [7], [8] and
 [9] for more info
  • Create a generic Jupyter Notebook that accepts a list of solver documents
 and extracts license information
  • Convert the created Jupyter Notebook into a CLI
  • Discuss correctness and applicability of the proposed solution
  • Integrate the created CLI into the system (“solver” workflow)
  • Sync license information into the database (see thoth-storages module)
  • Design a wrap adviser pipeline unit [6] in adviser that provides license
-information to users
    • Stretch goals
    • Detect and infer license information from dual licensed projects
    References
    1. https://github.com/thoth-station/solver/
    2. https://www.kaggle.com/thothstation/thoth-solver-dataset-v10
    3. https://github.com/thoth-station/datasets
    4. https://github.com/thoth-station/prescriptions-gh-release-notes-job
    5. https://github.com/thoth-station/solver-project-url-job/
    6. https://thoth-station.ninja/docs/developers/adviser/wraps.html
    7. https://packaging.python.org/guides/distributing-packages-using-setuptools/#license
    8. https://packaging.python.org/guides/distributing-packages-using-setuptools/#classifiers
    9. https://pypi.org/classifiers/
    Contribute to this page
    
\ No newline at end of file
+information to users
    Stretch goals
    • Detect and infer license information from dual licensed projects
    References
    1. https://github.com/thoth-station/solver/
    2. https://www.kaggle.com/thothstation/thoth-solver-dataset-v10
    3. https://github.com/thoth-station/datasets
    4. https://github.com/thoth-station/prescriptions-gh-release-notes-job
    5. https://github.com/thoth-station/solver-project-url-job/
    6. https://thoth-station.ninja/docs/developers/adviser/wraps.html
    7. https://packaging.python.org/guides/distributing-packages-using-setuptools/#license
    8. https://packaging.python.org/guides/distributing-packages-using-setuptools/#classifiers
    9. https://pypi.org/classifiers/
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/intern-projects/generate-prescription-from-text.md/index.html b/community/core/docs/intern-projects/generate-prescription-from-text.md/index.html
index f20145e044..e53a24f9f1 100644
--- a/community/core/docs/intern-projects/generate-prescription-from-text.md/index.html
+++ b/community/core/docs/intern-projects/generate-prescription-from-text.md/index.html
@@ -14,5 +14,5 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Generate prescriptions from text (text2prescription)
    Assigned intern: ??
-Assigned mentor: ??
    Project Goal
    The goal of this research project is to create text2prescription model that can be used in a bot for generating prescriptions to heal Python Projects from text inputs.
    Deliverables
    A Jupyter Notebook, later an CLI application, that can automatically generate prescriptions from text input.
    Prerequisites for Team Members
    Please check you have all the following:
    • Access to Operate First
    • Access to GMail and Google Chat
      • Be part of Thoth-Station Google Chat Room
    • Be part of Thoth scrum meetings
      • You should receive an invite to a Google calendar Event
    • Access to GitHub using your GitHub your account
      • Thoth Station
    • Get access to JupyterHub
    Project outline
    1. Welcome to the Thoth Station! [1]
      1. get familiar with team members
    2. Get familiar with adviser [2], study how it works [3].
    3. Get familiar with prescriptions [4][5], study how they are created [6].
    4. Research methods for mapping text to templates (e.g. prescription).
    5. Create NLP pipeline to analyze Text inputs (using Elyra [7] and Kubeflow Pipelines[8] available on Operate First).
    6. Create NLP model for entity recognition from text specific to prescriptions. (e.g. Python package, runtime environment, hardware).
    7. Create a Jupyter Notebook that accepts text and produce prescription (.yaml format).
      1. Discuss NLP pipeline steps.
      2. Discuss NLP model for entity recognition specific to prescriptions.
    8. Discuss applicability and use of this new approach (e.g. bot supporting users that want to create a prescription for Python application)
    Stretch goals:
    • Create a bot that can receive text from an issue as input and create a pull request with prescriptions
    References
    1. https://thoth-station.ninja/
    2. https://github.com/thoth-station/adviser
    3. https://developers.redhat.com/articles/2021/09/22/thoth-prescriptions-resolving-python-dependencies#
    4. https://github.com/thoth-station/prescriptions
    5. https://thoth-station.ninja/docs/developers/adviser/index.html#pipeline-units
    6. https://www.youtube.com/watch?v=OCX8JQDXP9s
    7. https://github.com/elyra-ai/elyra
    8. https://www.kubeflow.org/docs/components/pipelines/overview/pipelines-overview/
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    Generate prescriptions from text (text2prescription)
    Assigned intern: ??
+Assigned mentor: ??
    Project Goal
    The goal of this research project is to create text2prescription model that can be used in a bot for generating prescriptions to heal Python Projects from text inputs.
    Deliverables
    A Jupyter Notebook, later an CLI application, that can automatically generate prescriptions from text input.
    Prerequisites for Team Members
    Please check you have all the following:
    • Access to Operate First
    • Access to GMail and Google Chat
      • Be part of Thoth-Station Google Chat Room
    • Be part of Thoth scrum meetings
      • You should receive an invite to a Google calendar Event
    • Access to GitHub using your GitHub your account
      • Thoth Station
    • Get access to JupyterHub
    Project outline
    1. Welcome to the Thoth Station! [1]
      1. get familiar with team members
    2. Get familiar with adviser [2], study how it works [3].
    3. Get familiar with prescriptions [4][5], study how they are created [6].
    4. Research methods for mapping text to templates (e.g. prescription).
    5. Create NLP pipeline to analyze Text inputs (using Elyra [7] and Kubeflow Pipelines[8] available on Operate First).
    6. Create NLP model for entity recognition from text specific to prescriptions. (e.g. Python package, runtime environment, hardware).
    7. Create a Jupyter Notebook that accepts text and produce prescription (.yaml format).
      1. Discuss NLP pipeline steps.
      2. Discuss NLP model for entity recognition specific to prescriptions.
    8. Discuss applicability and use of this new approach (e.g. bot supporting users that want to create a prescription for Python application)
    Stretch goals:
    • Create a bot that can receive text from an issue as input and create a pull request with prescriptions
    References
    1. https://thoth-station.ninja/
    2. https://github.com/thoth-station/adviser
    3. https://developers.redhat.com/articles/2021/09/22/thoth-prescriptions-resolving-python-dependencies#
    4. https://github.com/thoth-station/prescriptions
    5. https://thoth-station.ninja/docs/developers/adviser/index.html#pipeline-units
    6. https://www.youtube.com/watch?v=OCX8JQDXP9s
    7. https://github.com/elyra-ai/elyra
    8. https://www.kubeflow.org/docs/components/pipelines/overview/pipelines-overview/
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/intern-projects/prescriptions-bootstrap.md/index.html b/community/core/docs/intern-projects/prescriptions-bootstrap.md/index.html
index f29649964f..b1bbb99014 100644
--- a/community/core/docs/intern-projects/prescriptions-bootstrap.md/index.html
+++ b/community/core/docs/intern-projects/prescriptions-bootstrap.md/index.html
@@ -14,9 +14,9 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Bootstrap database of Thoth prescriptions
    Assigned intern:
+      }
    Thoth Logo
    Project Thoth
    Bootstrap database of Thoth prescriptions
    Assigned intern:
 Assigned mentor:
    Project Goal
    The goal of this project is to extend the current database of prescriptions
 with known or not yet known issues in the Python ecosystem.
    Deliverables
    Set of YAML files committed to
 thoth-station/prescriptions
 repository that help the recommender system to advise better software stacks to
-users.
    Prerequisites for Team Members
    Please check you have all the following:
    • Be part of Thoth-Station Google Chat Room
    • Be part of Thoth scrum meetings
      • You should receive an invite to a Google calendar Event
    • Access to GitHub using your GitHub your account
      • Thoth Station
    Project outline
    1. Welcome to the Thoth Station!
      1. get familiar with team members
    2. Get familiar with thoth-station/prescriptions repository
    3. Get familiar with prescriptions concept, follow the online documentation for more info
    4. Identify popular Python packages that can be valuable to data scientists and Python developers
      1. Take a look at already existing hundredsDatasciencePackages list
      2. Take a look at Python packages based on their popularity (number of downloads from PyPI)
    5. For the identified set of Python packages create prescriptions that add knowledge to the recommender system so that users do not encounter known issues
      1. Follow project issues and/or project release notes
      2. Collaborate with communities to understand issues and required fixes, present prescriptions concept to communities
    6. Get familiar with Amun service and Dependency Monkey
    7. Identify possible cases that are suitable for running Dependency Monkey to spot issues in packages or runtime environments
    8. Run Dependency Monkey jobs and/or Amun inspections to conduct experiments that can result in new prescriptions
      1. Discuss possible issues with upstream communities
    9. Discuss extensibility and possible improvements that would help you to get results more effectively
    References
    1. https://github.com/thoth-station/prescriptions
    2. https://thoth-station.ninja/docs/developers/adviser/prescription.html
    3. https://thoth-station.ninja/docs/developers/adviser/dependency_monkey.html
    4. https://github.com/thoth-station/amun-api
    Contribute to this page
    
\ No newline at end of file
+users.
    Prerequisites for Team Members
    Please check you have all the following:
    • Be part of Thoth-Station Google Chat Room
    • Be part of Thoth scrum meetings
      • You should receive an invite to a Google calendar Event
    • Access to GitHub using your GitHub your account
      • Thoth Station
    Project outline
    1. Welcome to the Thoth Station!
      1. get familiar with team members
    2. Get familiar with thoth-station/prescriptions repository
    3. Get familiar with prescriptions concept, follow the online documentation for more info
    4. Identify popular Python packages that can be valuable to data scientists and Python developers
      1. Take a look at already existing hundredsDatasciencePackages list
      2. Take a look at Python packages based on their popularity (number of downloads from PyPI)
    5. For the identified set of Python packages create prescriptions that add knowledge to the recommender system so that users do not encounter known issues
      1. Follow project issues and/or project release notes
      2. Collaborate with communities to understand issues and required fixes, present prescriptions concept to communities
    6. Get familiar with Amun service and Dependency Monkey
    7. Identify possible cases that are suitable for running Dependency Monkey to spot issues in packages or runtime environments
    8. Run Dependency Monkey jobs and/or Amun inspections to conduct experiments that can result in new prescriptions
      1. Discuss possible issues with upstream communities
    9. Discuss extensibility and possible improvements that would help you to get results more effectively
    References
    1. https://github.com/thoth-station/prescriptions
    2. https://thoth-station.ninja/docs/developers/adviser/prescription.html
    3. https://thoth-station.ninja/docs/developers/adviser/dependency_monkey.html
    4. https://github.com/thoth-station/amun-api
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/sprint-demos/35.md/index.html b/community/core/docs/sprint-demos/35.md/index.html
index 311b37dc74..f24574ddc8 100644
--- a/community/core/docs/sprint-demos/35.md/index.html
+++ b/community/core/docs/sprint-demos/35.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Sprint 35 - 2020-Apr-14
    Topic: ArgoCD  (goern)
    Cards:
    Started working on ArgoCD and created a few Applications to play around with: https://github.com/thoth-station/thoth-application is the core application, branches in this repo reflect deployment environments (right now all are on Quicklab). Separate Applications for example for solver, as they need to go to more than one namespace.  ArgoCD uses kustomize to create manifests from the git repositories and keeps an OpenShift project in sync.
    Topic: Tekton based Thoth-CI  (hnalla)
    Cards:
    The work on the Thoth-CI is present in: https://github.com/thoth-station/thoth-ci.git
    Thoth-CI focuses on test checks and image creation on PR to test them. Pull Request is the main focus right now, on each PR as the pipeline is triggered to serve it. The instance of the Thoth-CI is running on Quicklab cluster.  Use Thoth-CI: Attach the Webhook to Github repo: http://thoth-ci.aicoe.ultrahook.com/
    Topic: Handling unsolved python packages (fmurdaca)
    Cards:
    Acting on unresolved package_version by analysing advisor results using a new component https://github.com/thoth-station/advise-reporter. And modifying the architecture of the Qeb-Hwt App (https://github.com/thoth-station/Qeb-Hwt).
    Topic: Optimizing Thoth’s adviser (fpokorny)
    Cards:
    Optimizations of the adviser’s internal structure to derive recommendations faster or bring better recommendations. We switched from the standard heap queue implementation that is provided by the standard Python library to a custom library called “fext” that is implementat as an C/C++ extension to CPython. This library is optimized for Thoth’s adviser use case when handling internal resolver states.
    Topic: Repository Health Report (Proof of concept) (dominik)
    Visualized Repository Health Report in form of a dashboard (using Dash). Any user that wants to see the current status of (his/her) repository, could run SrcOpsMetrics analysis locally and launch a dashboard for a quick status preview of the project.
    Cards:
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    Sprint 35 - 2020-Apr-14
    Topic: ArgoCD  (goern)
    Cards:
    Started working on ArgoCD and created a few Applications to play around with: https://github.com/thoth-station/thoth-application is the core application, branches in this repo reflect deployment environments (right now all are on Quicklab). Separate Applications for example for solver, as they need to go to more than one namespace.  ArgoCD uses kustomize to create manifests from the git repositories and keeps an OpenShift project in sync.
    Topic: Tekton based Thoth-CI  (hnalla)
    Cards:
    The work on the Thoth-CI is present in: https://github.com/thoth-station/thoth-ci.git
    Thoth-CI focuses on test checks and image creation on PR to test them. Pull Request is the main focus right now, on each PR as the pipeline is triggered to serve it. The instance of the Thoth-CI is running on Quicklab cluster.  Use Thoth-CI: Attach the Webhook to Github repo: http://thoth-ci.aicoe.ultrahook.com/
    Topic: Handling unsolved python packages (fmurdaca)
    Cards:
    Acting on unresolved package_version by analysing advisor results using a new component https://github.com/thoth-station/advise-reporter. And modifying the architecture of the Qeb-Hwt App (https://github.com/thoth-station/Qeb-Hwt).
    Topic: Optimizing Thoth’s adviser (fpokorny)
    Cards:
    Optimizations of the adviser’s internal structure to derive recommendations faster or bring better recommendations. We switched from the standard heap queue implementation that is provided by the standard Python library to a custom library called “fext” that is implementat as an C/C++ extension to CPython. This library is optimized for Thoth’s adviser use case when handling internal resolver states.
    Topic: Repository Health Report (Proof of concept) (dominik)
    Visualized Repository Health Report in form of a dashboard (using Dash). Any user that wants to see the current status of (his/her) repository, could run SrcOpsMetrics analysis locally and launch a dashboard for a quick status preview of the project.
    Cards:
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/sprint-demos/37.md/index.html b/community/core/docs/sprint-demos/37.md/index.html
index d2fa6cf190..990dd029d4 100644
--- a/community/core/docs/sprint-demos/37.md/index.html
+++ b/community/core/docs/sprint-demos/37.md/index.html
@@ -14,5 +14,5 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Sprint 37 - 2020-May-08
    Topic: ArgoCD: Thoth-application (goern)
    See https://argocd-server-aicoe-argocd.apps.ocp.prod.psi.redhat.com/applications for all the thoth application components deployed to thoth01 (quicklab==test) cluster. Using sops/ksops to encrypt and decrypt secrets.
    Topic: Publish s2i migration tool (frido)
    Cards:
    Topic: Updates on Thoth-CI (hnalla)
    New Feature
    Tag based release of image of the application slash-command to interact with the thoth-ci.
-/approve : To merge a pr on merge.
    CI focuses on test checks and image creation on PR to test them. Pull Request is the main focus right now, on each PR as the pipeline is triggered to serve it. The instance of the Thoth-CI is running on Quicklab cluster. Developers can interact with the CI for ease of operations.
    Use Thoth-CI: Attach the Webhook to Github repo: http://thoth-ci.aicoe.ultrahook.com
    Topic: Bandit Security Benchmark (kpostlet)
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    Sprint 37 - 2020-May-08
    Topic: ArgoCD: Thoth-application (goern)
    See https://argocd-server-aicoe-argocd.apps.ocp.prod.psi.redhat.com/applications for all the thoth application components deployed to thoth01 (quicklab==test) cluster. Using sops/ksops to encrypt and decrypt secrets.
    Topic: Publish s2i migration tool (frido)
    Cards:
    Topic: Updates on Thoth-CI (hnalla)
    New Feature
    Tag based release of image of the application slash-command to interact with the thoth-ci.
+/approve : To merge a pr on merge.
    CI focuses on test checks and image creation on PR to test them. Pull Request is the main focus right now, on each PR as the pipeline is triggered to serve it. The instance of the Thoth-CI is running on Quicklab cluster. Developers can interact with the CI for ease of operations.
    Use Thoth-CI: Attach the Webhook to Github repo: http://thoth-ci.aicoe.ultrahook.com
    Topic: Bandit Security Benchmark (kpostlet)
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/sprint-demos/38.md/index.html b/community/core/docs/sprint-demos/38.md/index.html
index 719552328c..c662ddd26b 100644
--- a/community/core/docs/sprint-demos/38.md/index.html
+++ b/community/core/docs/sprint-demos/38.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Sprint 38 - 2020-May-22
    Topic: Bandit Security Benchmark (kpostlet)
    Find us on YouTube: https://bit.ly/thoth-sprint-38
    Topic: SLO reporter (fmurdaca)
    Service Level Objective (SLO) reporter and the mails it’s sending out. Data is read form thanos (hosted by internal Data Hub), mail is send out each Friday night.
    Cards:
    Topic:  End-to-end demo of Thoth’s Jupyter Notebook build pipeline for custom and internal repositories (hnalla)
    OpenShift-pipelines/TektonCD-pipeline based a build pipeline which on tag release of a github/gitlab repository containing the jupyter notebook, builds an image based on requirements of the jupyter notebook, for them to be comfortable import into jupyterhub. S2i build process is used for build procedure.
    Cards:
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    Sprint 38 - 2020-May-22
    Topic: Bandit Security Benchmark (kpostlet)
    Find us on YouTube: https://bit.ly/thoth-sprint-38
    Topic: SLO reporter (fmurdaca)
    Service Level Objective (SLO) reporter and the mails it’s sending out. Data is read form thanos (hosted by internal Data Hub), mail is send out each Friday night.
    Cards:
    Topic:  End-to-end demo of Thoth’s Jupyter Notebook build pipeline for custom and internal repositories (hnalla)
    OpenShift-pipelines/TektonCD-pipeline based a build pipeline which on tag release of a github/gitlab repository containing the jupyter notebook, builds an image based on requirements of the jupyter notebook, for them to be comfortable import into jupyterhub. S2i build process is used for build procedure.
    Cards:
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/sprint-demos/39.md/index.html b/community/core/docs/sprint-demos/39.md/index.html
index f2769bd034..f431149a75 100644
--- a/community/core/docs/sprint-demos/39.md/index.html
+++ b/community/core/docs/sprint-demos/39.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Sprint 39 - 2020-Jun-05
    Find us on YouTube: http://bit.ly/thoth-on-youtube
    Topic: How does the SrcOpsMetrics gather data? (dtuchyna)
    The SrcOpsMetrics is currently able to gather the fundamental information about GitHub repository in order to calculate or visualize its Health Report. But how do we approach the data aggregation for multiple repositories present in organization that is inspected?
    Cards or Issues:
    Topic: Thoth Datasets (fmurdaca)
    Thoth datasets are related to observations regarding software stacks (e.g. dependency tree, installability, performance, security, health) as part of Project Thoth. All these datasets can be found also here where they are described and explored to facilitate their use. All these observations are created with different components which are part of Project Thoth and stored in Thoth Knowledge Graph. All this knowledge is used by Thoth Adviser to provide advices on software stacks depending on User requirements.
    Cards or Issues:
    References:
    Contribute to this page
    
\ No newline at end of file
+      }
    Thoth Logo
    Project Thoth
    Sprint 39 - 2020-Jun-05
    Find us on YouTube: http://bit.ly/thoth-on-youtube
    Topic: How does the SrcOpsMetrics gather data? (dtuchyna)
    The SrcOpsMetrics is currently able to gather the fundamental information about GitHub repository in order to calculate or visualize its Health Report. But how do we approach the data aggregation for multiple repositories present in organization that is inspected?
    Cards or Issues:
    Topic: Thoth Datasets (fmurdaca)
    Thoth datasets are related to observations regarding software stacks (e.g. dependency tree, installability, performance, security, health) as part of Project Thoth. All these datasets can be found also here where they are described and explored to facilitate their use. All these observations are created with different components which are part of Project Thoth and stored in Thoth Knowledge Graph. All this knowledge is used by Thoth Adviser to provide advices on software stacks depending on User requirements.
    Cards or Issues:
    References:
    Contribute to this page
    
\ No newline at end of file
diff --git a/community/core/docs/sprint-demos/README.md/index.html b/community/core/docs/sprint-demos/README.md/index.html
index a3f09a13fa..7af93b8210 100644
--- a/community/core/docs/sprint-demos/README.md/index.html
+++ b/community/core/docs/sprint-demos/README.md/index.html
@@ -14,7 +14,7 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Thoth-Station Sprint Demos
    This directory contains show notes for the Thoth-Station sprint demo session. Right now, our sprints are two weeks
+      }
    
\ No newline at end of file
diff --git a/community/index.html b/community/index.html
index 0b52c5250c..aea1dd5384 100644
--- a/community/index.html
+++ b/community/index.html
@@ -14,7 +14,7 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Terms and Conditions for the Thoth Station Scrum
    Thoth Station Inhabitants, v0.4.0, 2022-05-04
    A scrum sprint (or iteration) is 3 weeks of calendar time, and a task should/can not span more than one sprint.
+      }
    Thoth Logo
    Project Thoth
    Terms and Conditions for the Thoth Station Scrum
    Thoth Station Inhabitants, v0.4.0, 2022-05-04
    A scrum sprint (or iteration) is 3 weeks of calendar time, and a task should/can not span more than one sprint.
 If a task can not be accomplished in one sprint it must be broken up.
    Tasks are tracked as GitHub issues. Issues are created by anyone in the
 community, including the team and the users of the Thoth service.
    Issues are assigned to persons (they become an assignee of the issue) when a
 person picks up the card and starts working on it (pulls it into the ‘in
@@ -51,4 +51,4 @@
 will have done at the end of the scrum? What can we communicate to the outside of the team at the end of the scrum?
    Sprint Demo
    Scrum demos will be recorded and have meeting minutes. Every team member is encouraged to demo the work of the past
 sprint. Demos are published to our YouTube channel.
    Sprint Retrospective
    This activity is for reviewing what went well/not well regarding the past sprint. A discussion like what was the better
 aspect we would like to continue? What should be aspects that need more discussion as a team? What could have been a
-better way to proceed?
    The outcome of the sprint retrospective is a set of action items that will help the team improve in future sprints.
    Contribute to this page
    
\ No newline at end of file
+better way to proceed?
    The outcome of the sprint retrospective is a set of action items that will help the team improve in future sprints.
    Contribute to this page
    
\ No newline at end of file
diff --git a/metrics/index.html b/metrics/index.html
index 3d7e631033..0a8bacfc70 100644
--- a/metrics/index.html
+++ b/metrics/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    
\ No newline at end of file
+      }
    
\ No newline at end of file
diff --git a/metrics/issue_metrics.md/index.html b/metrics/issue_metrics.md/index.html
index 4060632da1..713b730683 100644
--- a/metrics/issue_metrics.md/index.html
+++ b/metrics/issue_metrics.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    
\ No newline at end of file
+      }
    
\ No newline at end of file
diff --git a/metrics/site_metrics.md/index.html b/metrics/site_metrics.md/index.html
index 9b04eac434..ce3a2479d2 100644
--- a/metrics/site_metrics.md/index.html
+++ b/metrics/site_metrics.md/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    
\ No newline at end of file
+      }
    
\ No newline at end of file
diff --git a/page-data/sq/d/1276261476.json b/page-data/sq/d/1276261476.json
index 5f5bddf609..c17aa32384 100644
--- a/page-data/sq/d/1276261476.json
+++ b/page-data/sq/d/1276261476.json
@@ -1 +1 @@
-{"data":{"navData":{"navItems":[{"id":"aT32CsBsaMf_2OfoZKcQn","label":"Terms and Conditions","href":"/community/core/docs/TermsAndConditionsForTheScrum.md","index":"/community","links":null},{"id":"4ctlnW622cI7GOM6vj5QZ","label":"Blueprints","href":null,"index":null,"links":[{"id":"94ftTGZFINBNBarT7fvVB","label":"Thoth Roadmap","remote":null,"href":"/community/core/docs/ROADMAP.md"},{"id":"RSuJR29_1lQTd2Zil393h","label":"Help Wanted Labels","remote":null,"href":"/community/core/community/help-wanted.md"}]},{"id":"gTIE3I-QCz02avP4WMqvi","label":"Special Interest Groups","href":null,"index":null,"links":[{"id":"Igy3_3dOaq_Y2df4I29zC","label":"Governance","remote":null,"href":"/community/core/community/governance.md"},{"id":"uIABuKlvM16UWtEwYEdi1","label":"SIG DevSecOps","remote":null,"href":"/community/core/community/sig-devsecops/README.md"},{"id":"CJn4lK3hcMugypB6jBhc1","label":"SIG Observability","remote":null,"href":"/community/core/community/sig-observability/README.md"},{"id":"AgVxEskQLGMvhEPy_d5r6","label":"SIG Stack Guidance","remote":null,"href":"/community/core/community/sig-stack-guidance/README.md"},{"id":"nnmZglO4-AHsGKpCcaXra","label":"SIG User Experience","remote":null,"href":"/community/core/community/sig-user-experience/README.md"}]},{"id":"Ah3Ar-6eIBw7anrEinduG","label":"Architecture Decision Records","href":null,"index":null,"links":[{"id":"YUhGrc55jq3Nu1u51d5ul","label":"0000 Architectural Decision","remote":null,"href":"/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md"},{"id":"CYOzLTMb1B07YOFiSlRLC","label":"0001 License","remote":null,"href":"/community/core/docs/adr/0001-use-gpl3-as-license.md"},{"id":"6dXAeFt3jtt5U9-Nag8qI","label":"0002 Release Policy","remote":null,"href":"/community/core/docs/adr/0002-release-policy.md"},{"id":"nIBXywwoWCdqD6pMqZlpF","label":"0003 Decommission qeb-hwt","remote":null,"href":"/community/core/docs/adr/0003-decommision-qeb-hwt.md"},{"id":"YGu_MVJm0Skjw65z6z1Qn","label":"0004 Image Naming Convention","remote":null,"href":"/community/core/docs/adr/0004-naming-convention-images.md"},{"id":"HitMXJVHBkphm9RJlIiGR","label":"0005 Bump Versions","remote":null,"href":"/community/core/docs/adr/0005-automatically-bump-container-image-versions.md"}]},{"id":"ClqEtFk3-cmwswu8qZhEl","label":"Getting Support","href":"/support","index":null,"links":null},{"id":"sEYMSlzBdO5FScyraqfbA","label":"FAQ","href":null,"index":null,"links":[{"id":"2F2y9fYrtAtLlgI0PNMyc","label":"Overview","remote":null,"href":"/support/faq/overview.mdx"},{"id":"q0yVaH5SDx35ld5MG7k6P","label":"Default .thoth.yaml","remote":null,"href":"/support/faq/thoth_yaml.mdx"}]},{"id":"rUlOD2VEvIpbPzYB8zSBJ","label":"Track your issue","href":"/support/issue_tracker.mdx","index":null,"links":null},{"id":"GT1ZELbWYMlMdx-hWIW9q","label":"Thoth Service Status","href":"/metrics","index":null,"links":null},{"id":"ziZ5NtI_-ajRScIvuoU2m","label":"GitHub Support","href":"/metrics/issue_metrics.md","index":null,"links":null},{"id":"MU053RPbMpW7o8i8oQsmT","label":"Website Usage","href":"/metrics/site_metrics.md","index":null,"links":null}]}}}
\ No newline at end of file
+{"data":{"navData":{"navItems":[{"id":"tM6ZwWyd7PhTbFXTZG9Bq","label":"Terms and Conditions","href":"/community/core/docs/TermsAndConditionsForTheScrum.md","index":"/community","links":null},{"id":"VOLDlvdAU2g103BHaL-Lq","label":"Blueprints","href":null,"index":null,"links":[{"id":"tsXsJbw4dbMaWpKNO5Xv0","label":"Thoth Roadmap","remote":null,"href":"/community/core/docs/ROADMAP.md"},{"id":"hJe0YasnYTUAraipNB0Zu","label":"Help Wanted Labels","remote":null,"href":"/community/core/community/help-wanted.md"}]},{"id":"by7l4YY5iMvRbgNfR2umz","label":"Special Interest Groups","href":null,"index":null,"links":[{"id":"-_BYdvMfMmJaPt2tHtRer","label":"Governance","remote":null,"href":"/community/core/community/governance.md"},{"id":"Jw2y2zqXOfqLk-VaKuvSX","label":"SIG DevSecOps","remote":null,"href":"/community/core/community/sig-devsecops/README.md"},{"id":"xzhiMBvR6Fp45BUO7YEku","label":"SIG Observability","remote":null,"href":"/community/core/community/sig-observability/README.md"},{"id":"_COwD74a-pMx0njhZGgzZ","label":"SIG Stack Guidance","remote":null,"href":"/community/core/community/sig-stack-guidance/README.md"},{"id":"dytJAxEm8nUQiFWk2r6gs","label":"SIG User Experience","remote":null,"href":"/community/core/community/sig-user-experience/README.md"}]},{"id":"h7zoq15-JlvlEnm12pkvb","label":"Architecture Decision Records","href":null,"index":null,"links":[{"id":"VULCpMtnacQ5ngMF1ZQrK","label":"0000 Architectural Decision","remote":null,"href":"/community/core/docs/adr/0000-use-markdown-architectural-decision-records.md"},{"id":"AV6YPUNUxDe7ZnonDft28","label":"0001 License","remote":null,"href":"/community/core/docs/adr/0001-use-gpl3-as-license.md"},{"id":"REREfYbA894baciBp2eDA","label":"0002 Release Policy","remote":null,"href":"/community/core/docs/adr/0002-release-policy.md"},{"id":"JD2z_w6eD_K7X3_gqrpak","label":"0003 Decommission qeb-hwt","remote":null,"href":"/community/core/docs/adr/0003-decommision-qeb-hwt.md"},{"id":"tISfYypr1fj3ypLYvO4c9","label":"0004 Image Naming Convention","remote":null,"href":"/community/core/docs/adr/0004-naming-convention-images.md"},{"id":"76drQ6VV9xcMeGNxkuWct","label":"0005 Bump Versions","remote":null,"href":"/community/core/docs/adr/0005-automatically-bump-container-image-versions.md"}]},{"id":"PdDwslzZ9Pl6qtonpCn1n","label":"Getting Support","href":"/support","index":null,"links":null},{"id":"72BmE_68dyn5QitFD6ZUZ","label":"FAQ","href":null,"index":null,"links":[{"id":"sR8LbIvgnKqbIY2RND6Zk","label":"Overview","remote":null,"href":"/support/faq/overview.mdx"},{"id":"8D4QFJ7sHhc3i4WoZN0Un","label":"Default .thoth.yaml","remote":null,"href":"/support/faq/thoth_yaml.mdx"}]},{"id":"zz_L0-D5Og3_S7LjeJIc1","label":"Track your issue","href":"/support/issue_tracker.mdx","index":null,"links":null},{"id":"kV8WYq15CiSjM_m8RVRb8","label":"Thoth Service Status","href":"/metrics","index":null,"links":null},{"id":"a5J60ajMuYwRimPHIMcXL","label":"GitHub Support","href":"/metrics/issue_metrics.md","index":null,"links":null},{"id":"xw42r2NEmQtZEcaD1UAe6","label":"Website Usage","href":"/metrics/site_metrics.md","index":null,"links":null}]}}}
\ No newline at end of file
diff --git a/support/faq/overview.mdx/index.html b/support/faq/overview.mdx/index.html
index 8c7421416c..22f116de02 100644
--- a/support/faq/overview.mdx/index.html
+++ b/support/faq/overview.mdx/index.html
@@ -14,7 +14,7 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    How do I use Thoth?
    Depending on your use case, you can interact with Thoth through a variety of integration points.
    Thamos CLI
    Thamos is a command line tool and library for communicating with the Thoth backend. More information on how to
+      }
    Thoth Logo
    Project Thoth
    How do I use Thoth?
    Depending on your use case, you can interact with Thoth through a variety of integration points.
    Thamos CLI
    Thamos is a command line tool and library for communicating with the Thoth backend. More information on how to
 install and get started with it can be found in our tutorial space.
    Kebechet
    Kebechet is an extensible system of repository managers for GitHub, GitLab, and Pagure. You can use this bot integrate
 the functionality of Thoth into your repositories. More information on Kebechet can be found here.
    Jupyterlab Extension
    If you use Jupyterlab for development, this extension allows
 you to integrate Thoth’s adviser into your notebook’s environment.
    Thoth User API
    You can directly interact with the Thoth User API too.
    What are Kebechet managers and how do I configure them?
    Managers can be seen as separate bots all part of Kebechet. You can enable and configure each available bot by adding it
diff --git a/support/faq/thoth_yaml.mdx/index.html b/support/faq/thoth_yaml.mdx/index.html
index 6e9bbea0c9..42d77df0e3 100644
--- a/support/faq/thoth_yaml.mdx/index.html
+++ b/support/faq/thoth_yaml.mdx/index.html
@@ -14,7 +14,7 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    # This is  Thoth's configuration file placed in a root of a repo
    # (named as .thoth.yaml) used by Thamos CLI as well as by Thoth bots. Please
    # adjust values listed below as desired.
    
+      }
    Thoth Logo
    Project Thoth
    # This is  Thoth's configuration file placed in a root of a repo
    # (named as .thoth.yaml) used by Thamos CLI as well as by Thoth bots. Please
    # adjust values listed below as desired.
    
 
    # A remote Thoth service to talk to:
    host: khemenu.thoth-station.ninja
    
 
    # Configure TLS verification for communication with remote Thoth instance:
    tls_verify: true
    
 
    # Format of requirements file, supported are "pip" and "pipenv":
    requirements_format: {requirements_format}
    # A path to overlays directory relative to this configuration file. If null provided, no overlays are used.
    # Read more about overlays in the README: https://github.com/thoth-station/thamos#overlays-directory
    overlays_dir: null
    # Allow or disable managing virtual environment for each overlay.
    virtualenv: false
    
diff --git a/support/index.html b/support/index.html
index 8bfdce6ff5..ef1f3e54c9 100644
--- a/support/index.html
+++ b/support/index.html
@@ -14,7 +14,7 @@
       
       
       
-      }
    Thoth Logo
    Project Thoth
    Getting Support
    Channels of support
    GitHub Issues
    The primary channel for getting support is by creating a GitHub issue through our support repository.
+      }
    Thoth Logo
    Project Thoth
    Getting Support
    Channels of support
    GitHub Issues
    The primary channel for getting support is by creating a GitHub issue through our support repository.
 Choose between any of the issue templates or create a blank issue if no template fits your situation.
 Once created, your issue will be delegated out to one of Thoth’s Special Interest Groups (SIG)
 or a specific person on the Thoth team. They will help you get the issue ready to be worked on by refining the issue to
diff --git a/support/issue_tracker.mdx/index.html b/support/issue_tracker.mdx/index.html
index d5d9c9ab20..08bd01ec7a 100644
--- a/support/issue_tracker.mdx/index.html
+++ b/support/issue_tracker.mdx/index.html
@@ -14,4 +14,4 @@
       
       
       
-      }
    
\ No newline at end of file
+      }
    
\ No newline at end of file