From e4429bc05402f0aabd04cb138b3001450fe16778 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 18 Nov 2024 00:08:14 +0000 Subject: [PATCH] Updates --- community/core/community/README.md/index.html | 2 +- community/core/community/SUPPORT_POLICY.md/index.html | 2 +- community/core/community/governance.md/index.html | 4 ++-- community/core/community/help-wanted.md/index.html | 4 ++-- community/core/community/liaisons.md/index.html | 4 ++-- community/core/community/sig-devsecops/README.md/index.html | 4 ++-- community/core/community/sig-devsecops/charter.md/index.html | 2 +- .../core/community/sig-observability/README.md/index.html | 2 +- .../core/community/sig-observability/charter.md/index.html | 2 +- .../core/community/sig-stack-guidance/README.md/index.html | 2 +- .../core/community/sig-stack-guidance/charter.md/index.html | 2 +- .../core/community/sig-user-experience/README.md/index.html | 2 +- .../core/community/sig-user-experience/charter.md/index.html | 2 +- community/core/community/wg-cnbi/README.md/index.html | 2 +- community/core/community/wg-cnbi/charter.md/index.html | 2 +- community/core/docs/ROADMAP.md/index.html | 2 +- .../index.html | 2 +- .../core/docs/adr/0001-use-gpl3-as-license.md/index.html | 2 +- community/core/docs/adr/0002-release-policy.md/index.html | 2 +- .../core/docs/adr/0003-decommision-qeb-hwt.md/index.html | 4 ++-- .../core/docs/adr/0004-naming-convention-images.md/index.html | 4 ++-- .../index.html | 2 +- .../core/docs/adr/0005-obtimizing-keb-runs.md/index.html | 2 +- .../core/docs/adr/0006-thoth-github-action.md/index.html | 2 +- community/core/docs/adr/0007-scorecard-metrics.md/index.html | 2 +- community/core/docs/adr/template.md/index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- .../detecting-lincenses-of-python-modules.md/index.html | 2 +- .../generate-prescription-from-text.md/index.html | 2 +- .../intern-projects/prescriptions-bootstrap.md/index.html | 2 +- community/core/docs/sprint-demos/35.md/index.html | 2 +- community/core/docs/sprint-demos/37.md/index.html | 2 +- community/core/docs/sprint-demos/38.md/index.html | 2 +- community/core/docs/sprint-demos/39.md/index.html | 2 +- community/core/docs/sprint-demos/README.md/index.html | 2 +- community/index.html | 2 +- metrics/issue_metrics.md/index.html | 2 +- metrics/site_metrics.md/index.html | 2 +- page-data/sq/d/1276261476.json | 2 +- support/faq/overview.mdx/index.html | 4 ++-- support/faq/thoth_yaml.mdx/index.html | 4 ++-- support/index.html | 4 ++-- support/issue_tracker.mdx/index.html | 2 +- 44 files changed, 53 insertions(+), 53 deletions(-) diff --git a/community/core/community/README.md/index.html b/community/core/community/README.md/index.html index 01ce29595a..e99b8e7790 100644 --- a/community/core/community/README.md/index.html +++ b/community/core/community/README.md/index.html @@ -14,7 +14,7 @@ - }

Repository configuration

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

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 fc9dff2b36..b332061b00 100644 --- a/community/core/community/SUPPORT_POLICY.md/index.html +++ b/community/core/community/SUPPORT_POLICY.md/index.html @@ -14,7 +14,7 @@ - }

Support Policy

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

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.

\ 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 a1c7d4e6f3..0b678ebf49 100644 --- a/community/core/community/governance.md/index.html +++ b/community/core/community/governance.md/index.html @@ -14,7 +14,7 @@ - }

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. + }

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 @@ -44,4 +44,4 @@ some subproject. Some SIGs may have a single subproject, but many SIGs have multiple significant subprojects with distinct (though sometimes overlapping) sets of contributors and [owners], who act as -subproject’s technical leaders.

Subprojects for each SIG are documented in [sigs.yaml].

\ No newline at end of file +subproject’s technical leaders.

Subprojects for each SIG are documented in [sigs.yaml].

\ No newline at end of file diff --git a/community/core/community/help-wanted.md/index.html b/community/core/community/help-wanted.md/index.html index b5a48823e0..0acf1ef500 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

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

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 @@ -75,4 +75,4 @@ They want to know the acceptable way to ask for people to review a PR, and how to nudge things along when a PR is stalled. Show them how we operate by helping move their first PR along.

  • If you have time, let the contributor know that they can DM you with questions -that they aren’t yet comfortable asking the wider group.
  • \ No newline at end of file +that they aren’t yet comfortable asking the wider group.
    \ No newline at end of file diff --git a/community/core/community/liaisons.md/index.html b/community/core/community/liaisons.md/index.html index cbafec90ff..56ddcab474 100644 --- a/community/core/community/liaisons.md/index.html +++ b/community/core/community/liaisons.md/index.html @@ -14,10 +14,10 @@ - }

    Liaisons

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

    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 the Steering Committee.

    Liaisons are assigned community groups at random (adjustments can be made, if needed) with each member having an (almost) equal distribution -of SIGs, WGs and UGs.

    Community GroupSteering Committee Liaison
    SIG DevSecOpsChristoph Görn (@goern)
    SIG ObservabilityChristoph Görn (@goern)
    SIG Stack GuidanceChristoph Görn (@goern)
    SIG User ExperienceChristoph Görn (@goern)
    \ No newline at end of file +of SIGs, WGs and UGs.

    Community GroupSteering Committee Liaison
    SIG DevSecOpsChristoph Görn (@goern)
    SIG ObservabilityChristoph Görn (@goern)
    SIG Stack GuidanceChristoph Görn (@goern)
    SIG User ExperienceChristoph Görn (@goern)
    \ No newline at end of file diff --git a/community/core/community/sig-devsecops/README.md/index.html b/community/core/community/sig-devsecops/README.md/index.html index 01f8e0243a..de8b5f8786 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 @@ - }

    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. + }

    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

    \ 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

    \ 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 dc1ac237ab..9f11bb7ab7 100644 --- a/community/core/community/sig-devsecops/charter.md/index.html +++ b/community/core/community/sig-devsecops/charter.md/index.html @@ -14,7 +14,7 @@ - }

    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 + }

    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, diff --git a/community/core/community/sig-observability/README.md/index.html b/community/core/community/sig-observability/README.md/index.html index c14a3e2b52..1145392746 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 @@ - }

    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. + }

    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

    \ 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 a9710c2cdb..e1a75eef0a 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 @@ - }

    SIG Observability Charter

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

    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.

    \ 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 1d2b61a0d9..a8c7491308 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 @@ - }

    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. + }

    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

    \ 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 8a78d26f97..f4d4b06df5 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 @@ - }

    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.

    \ No newline at end of file + }

    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.

    \ 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 9ca4975cd1..1404f354de 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 @@ - }

    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. + }

    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

    \ 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 f5c7fe29b4..e7bcefb8c4 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 @@ - }

    SIG User Experience Charter

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

    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 9e66278504..9380a60dca 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 @@ - }

    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. + }

    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

    \ 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 228fced501..e4be60f40c 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 @@ - }

    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.

    \ No newline at end of file + }

    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.

    \ 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 46afb4fedf..87541af258 100644 --- a/community/core/docs/ROADMAP.md/index.html +++ b/community/core/docs/ROADMAP.md/index.html @@ -14,7 +14,7 @@ - }

    Thoth Roadmap

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

    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 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 9ff93523b9..244d826ce7 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 @@ - }

    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.

    \ No newline at end of file + }

    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.

    \ 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 e05b5845e5..35b6f9e6f8 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 @@ - }

    Use GNU GPL as license

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

    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.

    \ 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 3128e593fa..7a11c42856 100644 --- a/community/core/docs/adr/0002-release-policy.md/index.html +++ b/community/core/docs/adr/0002-release-policy.md/index.html @@ -14,7 +14,7 @@ - }

    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 + }

    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