From f943b7b8446378f647a43976387aaef320d922ec Mon Sep 17 00:00:00 2001 From: lrcouto Date: Wed, 9 Aug 2023 16:19:34 -0300 Subject: [PATCH 1/3] Remove redundant pages and direct users to wiki Signed-off-by: lrcouto --- .../contribution/backwards_compatibility.md | 25 --- .../developer_contributor_guidelines.md | 197 ------------------ .../development_for_databricks.md | 95 --------- .../documentation_contributor_guidelines.md | 62 ------ docs/source/contribution/index.md | 10 +- 5 files changed, 4 insertions(+), 385 deletions(-) delete mode 100644 docs/source/contribution/backwards_compatibility.md delete mode 100644 docs/source/contribution/developer_contributor_guidelines.md delete mode 100644 docs/source/contribution/development_for_databricks.md delete mode 100644 docs/source/contribution/documentation_contributor_guidelines.md diff --git a/docs/source/contribution/backwards_compatibility.md b/docs/source/contribution/backwards_compatibility.md deleted file mode 100644 index 142cf929d2..0000000000 --- a/docs/source/contribution/backwards_compatibility.md +++ /dev/null @@ -1,25 +0,0 @@ -# Backwards compatibility & breaking changes - -This page explains the principles of backwards compatibility and breaking changes. - -A backwards-compatible change is any change that is not a breaking change. So what is a breaking change? - -A breaking change is any change that modifies Kedro's public APIs. Examples include making a change to the signature of public functions or removing a module. - -Your change is **not** considered a breaking change, and so is backwards compatible, **if a user can upgrade their Kedro version and include your change without anything breaking in their project**. - -## When should I make a breaking change? - -We aim to minimise the number of breaking changes to keep Kedro software stable and reduce the overhead for users as they migrate their projects. However, there are cases where a breaking change brings considerable value or increases the maintainability of the codebase. In these cases, breaking backwards compatibility can make sense. - -Before you contribute a breaking change, you should create a [GitHub Issue](https://github.com/kedro-org/kedro/issues) that describes the change and justifies the value gained by breaking backwards compatibility. - -## The Kedro release model - -All non-breaking changes go into `main`, from which a minor release can be deployed at any time. - -All breaking changes go into `develop`, from which a major release can be deployed at any time. The `develop` branch contains all commits from the `main` branch, but the `main` branch does not contain all the commits from `develop` until the next major release. - -![Kedro Gitflow Diagram](../meta/images/kedro_gitflow.svg) - -Got a question about the development process? Ask the community on [Slack](https://slack.kedro.org) if you need to! diff --git a/docs/source/contribution/developer_contributor_guidelines.md b/docs/source/contribution/developer_contributor_guidelines.md deleted file mode 100644 index 787a838d90..0000000000 --- a/docs/source/contribution/developer_contributor_guidelines.md +++ /dev/null @@ -1,197 +0,0 @@ -# Guidelines for contributing developers - -This page explains the principles and development process that we ask contributing developers to follow. - -**Any contributions you make will be under the [Apache 2.0 Software License](https://github.com/kedro-org/kedro/blob/main/LICENSE.md).** - -In short, when you submit code changes, your submissions are understood to be under the same the [Apache 2.0 License](https://github.com/kedro-org/kedro/blob/main/LICENSE.md) that covers the Kedro project. You should have permission to share the submitted code. - -```{note} -You don't need to contribute code to help the Kedro project. See our list of other ways [you can contribute to Kedro](https://github.com/kedro-org/kedro/blob/main/CONTRIBUTING.md). -``` - -## Introduction - -This guide is a practical description of: - -* How to set up your development environment to contribute to Kedro. -* How to prepare a pull request against the Kedro repository. - - -## Before you start: development set up - -To work on the Kedro codebase, you will need to be set up with Git, and Make. - -```{note} -If your development environment is Windows, you can use the `win_setup_conda` and `win_setup_env` commands from [Circle CI configuration](https://github.com/kedro-org/kedro/blob/main/.circleci/config.yml) to guide you in the correct way to do this. -``` - -You will also need to create and activate virtual environment. If this is unfamiliar to you, read through our [pre-requisites documentation](../get_started/install.md#installation-prerequisites). - -Next, you'll need to fork the [Kedro source code from the GitHub repository](https://github.com/kedro-org/kedro): - -* Fork the project by clicking **Fork** in the top-right corner of the [Kedro GitHub repository](https://github.com/kedro-org/kedro) -* Choose your target account - -If you need further guidance, consult the [GitHub documentation about forking a repo](https://docs.github.com/en/get-started/quickstart/fork-a-repo#forking-a-repository). - -You are almost ready to go. In your terminal, navigate to the folder into which you forked the Kedro code. - -Run these commands to install everything you need to work with Kedro: - -``` -make install-test-requirements -make install-pre-commit -``` - -Once the above commands have executed successfully, do a sanity check to ensure that `kedro` works in your environment: - -``` -make test -``` - -```{note} -If the tests in `tests/extras/datasets/spark` are failing, and you are not planning to work on [Spark](https://spark.apache.org) related features, then you can run a reduced test suite that excludes them. Do this by executing `make test-no-spark`. -``` - -## Get started: areas of contribution - -Once you are ready to contribute, a good place to start is to take a look at the `good first issues` and `help wanted issues` on [GitHub](https://github.com/kedro-org/kedro/issues). - -We focus on three areas for contribution: `core`, `extras` and `plugin`: - -- `core` refers to the primary Kedro library. Read the [`core` contribution process](#core-contribution-process) for details. -- `extras` refers to features that could be added to `core` that do not introduce too many dependencies or require new Kedro CLI commands to be created. Read the [`extras` contribution process](#extras-contribution-process) for more information. -- [`plugin`](../extend_kedro/plugins.md) refers to new functionality that requires a Kedro CLI command e.g. adding in Airflow functionality and [adding a new dataset](../extend_kedro/custom_datasets.md) to the `kedro-datasets` package. The [`plugin` development documentation](../extend_kedro/plugins.md) contains guidance on how to design and develop a Kedro `plugin`. - - -### `core` contribution process - -Typically, we only accept small contributions to the `core` Kedro library, but we accept new features as plugins or additions to the [`extras`](https://github.com/kedro-org/kedro/tree/main/kedro/extras) module. - -To contribute: - -1. Create a feature branch on your forked repository and push all your local changes to that feature branch. -2. Is your change [non-breaking and backwards-compatible](./backwards_compatibility.md)? Your feature branch should branch off from: -
    -
  1. main if you intend for it to be a non-breaking, backwards-compatible change.
    2. -
  2. develop if you intend for it to be a breaking change.
    3. -
-3. Before you submit a pull request (PR), please ensure that unit tests, end-to-end (E2E) tests and linters are passing for your changes by running `make test`, `make e2e-tests` and `make lint` locally; see the [development set up](#before-you-start-development-set-up) section above. -4. Open a PR: -
    -
  1. For backwards compatible changes, open a PR against the kedro-org:main branch from your feature branch.
    2. -
  2. For changes that are NOT backwards compatible, open a PR against the kedro-org:develop branch from your feature branch.
    3. -
- -5. Await reviewer comments. -6. Update the PR according to the reviewer's comments. -7. Your PR will be merged by the Kedro team once all the comments are addressed. - -```{note} -We will work with you to complete your contribution, but we reserve the right to take over abandoned PRs. -``` - -### `extras` contribution process - -You can add new work to `extras` if you do not need to create a new Kedro CLI command: - -1. Create an [issue](https://github.com/kedro-org/kedro/issues) describing your contribution. -2. Work in [`extras`](https://github.com/kedro-org/kedro/tree/main/kedro/extras) and create a feature branch on your forked repository and push all your local changes to that feature branch. -3. Before you submit a pull request, please ensure that unit tests, end-to-end (E2E) tests and linters are passing for your changes by running `make test`,`make e2e-tests` and `make lint` locally, have a look at the section [development set up](#before-you-start-development-set-up) section above. -4. Include a `README.md` with instructions on how to use your contribution. -5. Is your change [non-breaking and backwards-compatible](./backwards_compatibility.md)? -
    -
  1. For backwards compatible changes, open a PR against the kedro-org:main branch from your feature branch.
    2. -
  2. For changes that are NOT backwards compatible, open a PR against the kedro-org:develop branch from your feature branch.
    3. -
- -6. Reference your issue in the PR description (e.g., `Resolves #`). -7. Await review comments, then update the PR according to the reviewer's comments. -8. Your PR will be merged by the Kedro team once all the comments are addressed. - -```{note} -We will work with you to complete your contribution, but we reserve the right to take over abandoned PRs. -``` - -## Create a pull request - -[Give your pull request a descriptive title](#pull-request-title-conventions). Before you submit it, consider the following: - -* You should aim for cross-platform compatibility on Windows, macOS and Linux -* We use [Semantic Versioning](https://semver.org/) for versioning -* We have designed our code to be compatible with Python 3.7 onwards and our style guidelines are (in cascading order): - * [PEP 8 conventions](https://www.python.org/dev/peps/pep-0008/) for all Python code - * [Google docstrings](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings) for code comments - * [PEP 484 type hints](https://www.python.org/dev/peps/pep-0484/) for all user-facing functions/class methods; e.g. - - ```python - def count_truthy(elements: List[Any]) -> int: - return sum(1 for elem in elements if element) - ``` - -Ensure that your PR builds cleanly before you submit it, by running the CI/CD checks locally, as follows: -* `make lint`: PEP-8 Standards (`ruff`, `black`) -* `make test`: unit tests, 100% coverage (`pytest`, `pytest-cov`) -* `make e2e-tests`: end-to-end tests (`behave`) - -```{note} -If Spark/PySpark/Hive tests for datasets are failing it might be due to the lack of Java>8 support from Spark. You can try using `export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)` which [works under macOS or other workarounds](https://stackoverflow.com/questions/53583199/spark-error-unsupported-class-file-major-version). -``` - -```{note} -We place [conftest.py](https://docs.pytest.org/en/latest/reference/fixtures.html) files in some test directories to make fixtures reusable by any tests in that directory. If you need to see which test fixtures are available and where they come from, you can issue the following command `pytest --fixtures path/to/the/test/location.py`. -``` - -### Pull request title conventions - -The Kedro repository requires that you [squash and merge your pull request commits](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits), and, in most cases, the [merge message for a squash merge](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#merge-message-for-a-squash-merge) then defaults to the pull request title. - -For clarity, your pull request title should be descriptive, and we ask you to follow some guidelines suggested by [Chris Beams](https://github.com/cbeams) in his post [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/#seven-rules). In particular, for your pull request title, we suggest that you: - -* [Limit the length to 50 characters](https://chris.beams.io/posts/git-commit/#limit-50) -* [Capitalise the first letter of the first word](https://chris.beams.io/posts/git-commit/#capitalize) -* [Omit the period at the end](https://chris.beams.io/posts/git-commit/#end) -* [Use the imperative tense](https://chris.beams.io/posts/git-commit/#imperative) - -### Hints on `pre-commit` usage -[`pre-commit`](https://pre-commit.com) hooks run checks automatically on all the changed files on each commit but can be skipped with the `--no-verify` or `-n` flag: - -```bash -git commit --no-verify <...> -``` - -All checks will run during CI build, so skipping checks on commit will not allow you to merge your code with failing checks. You can uninstall the `pre-commit` hooks by running: - -```bash -make uninstall-pre-commit -``` -`pre-commit` will still be used by `make lint`, but will not install the git hooks. - -### Developer Certificate of Origin -We require that all contributions comply with the [Developer Certificate of Origin (DCO)](https://developercertificate.org/). This certifies that the contributor wrote or otherwise has the right to submit their contribution. - -All commits must be signed off by including a `Signed-off-by` line in the commit message: -``` -This is my commit message - -Signed-off-by: Random J Developer -``` - -The sign-off can be added automatically to your commit message using the `-s` option: -```bash -git commit -s -m "This is my commit message" -``` - -To avoid needing to remember the `-s` flag on every commit, you might like to set up a [git alias](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases) for `git commit -s`. Alternatively, run `make sign-off` to setup a [`commit-msg` Git hook](https://git-scm.com/docs/githooks#_commit_msg) that automatically signs off all commits (including merge commits) you make while working on the Kedro repository. - -If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass. - -## Need help? - -Working on your first pull request? You can learn how from these resources: - -* [First timers only](https://www.firsttimersonly.com/) -* [How to contribute to an open source project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github) - -Previous Q&A on [GitHub discussions](https://github.com/kedro-org/kedro/discussions) and the [searchable archive of Slack discussions](https://www.linen.dev/s/kedro). You can ask new questions about the development process on [Slack](https://slack.kedro.org) too! diff --git a/docs/source/contribution/development_for_databricks.md b/docs/source/contribution/development_for_databricks.md deleted file mode 100644 index 571b2e65ad..0000000000 --- a/docs/source/contribution/development_for_databricks.md +++ /dev/null @@ -1,95 +0,0 @@ -# Contribute changes to Kedro that are tested on Databricks - -Many Kedro users deploy their projects to [Databricks](https://www.databricks.com/), a cloud-based platform for data engineering and data science. We encourage contributions to extend and improve the experience for Kedro users on Databricks; this guide explains how to efficiently test your locally modified version of Kedro on Databricks as part of a build-and-test development cycle. - -## How to deploy a development version of Kedro to Databricks - -```{note} -This page is for **contributors** developing changes to Kedro that need to test them on Databricks. If you are a Kedro user working on an individual or team project and need more information about workflows, consult the [documentation pages for developing a Kedro project on Databricks](../deployment/databricks/index.md). -``` - -## Prerequisites - -You will need the following to follow this guide: - -* Python **version >=3.8**. -* An activated Python virtual environment into which you have installed the [Databricks CLI](https://docs.databricks.com/dev-tools/cli/index.html) with [authentication for your workspace](https://docs.databricks.com/dev-tools/cli/index.html#set-up-the-cli). -* Access to a Databricks workspace with an [existing cluster](https://docs.databricks.com/clusters/create-cluster.html). -* [GNU `make`](https://www.gnu.org/software/make/). -* [`git`](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git). -* A local clone of the [Kedro git repository](https://github.com/kedro-org/kedro). - -## How to install a build of Kedro onto Databricks - -The development workflow for Kedro on Databricks is similar to the one for Kedro in general, when you develop and test your changes locally. The main difference comes when manually testing your changes on Databricks, since you will need to build and deploy the wheel file to Databricks to test it on a cluster. - -To make developing Kedro for Databricks easier, Kedro comes with a `Makefile` target named `databricks-build` that automates the process of building a wheel file and installing this on your Databricks cluster to save development time. - -### How to set up the Databricks CLI to test a Kedro build - -Before you use `make databricks-build`, you must [set up the Databricks CLI](https://docs.databricks.com/dev-tools/cli/index.html#set-up-the-cli). - -Next, create and environment variable with the ID of the cluster you are using to test your Kedro build. You can find the ID by executing the Databricks CLI command `databricks clusters list` and looking for the Cluster ID to the left of the name of your chosen cluster, for instance: - -```bash -$ databricks clusters list -1234-567890-abcd1234 General Cluster TERMINATED -0987-654321-9876xywz Kedro Test Cluster TERMINATED -``` - -In this case, the cluster ID of `Kedro Test Cluster` is `0987-654321-9876xywz`. - -Once you have determined the cluster ID, you must export it to an environment variable named `DATABRICKS_CLUSTER_ID`: - -```bash -# Linux or macOS -export DATABRICKS_CLUSTER_ID= - -# Windows (PowerShell) -$Env:DATABRICKS_CLUSTER_ID = '' -``` - -### How to use `make databricks-build` to test your Kedro build - -With the setup complete, you can use `make databricks-build`. In your terminal, navigate to the parent directory of your Kedro development repository and run: - -```bash -make databricks-build -``` - -You should see a stream of messages being written to your terminal. Behind the scenes, `databricks-build` does the following: - -1. Builds a wheel file of your modified version of Kedro. -2. Uninstalls any library on your Databricks cluster with the same wheel file name. -3. Uploads your updated wheel file to DBFS (Databricks File System). -4. Queues your updated wheel file for installation -5. Restarts your cluster to apply the changes. - -Note that your cluster will be unavailable while it restarts. You can poll the status of the cluster using the Databricks CLI: - -```bash -# Linux or macOS -databricks clusters get --cluster-id $DATABRICKS_CLUSTER_ID | grep state - -# Windows (PowerShell) -databricks clusters get --cluster-id $Env:DATABRICKS_CLUSTER_ID | Select-String state -``` - -Once the cluster has restarted, you should verify that your modified version of Kedro has been correctly installed. Run `databricks libraries list --cluster-id `. If installation was successful, you should see the following output: - -```bash -{ - "cluster_id": "", - "library_statuses": [ - { - "library": { - "whl": "dbfs:/tmp/kedro-builds/kedro--py3-none-any.whl" - }, - "status": "INSTALLED", - "is_library_for_all_clusters": false - } - ] -} -``` - -Any runs of a Kedro project on this cluster will now reflect your latest local changes to Kedro. You can now test your changes to Kedro by using your cluster to run a Kedro project. diff --git a/docs/source/contribution/documentation_contributor_guidelines.md b/docs/source/contribution/documentation_contributor_guidelines.md deleted file mode 100644 index 85a4746a27..0000000000 --- a/docs/source/contribution/documentation_contributor_guidelines.md +++ /dev/null @@ -1,62 +0,0 @@ -# Contribute to the Kedro documentation - -You are welcome to contribute to the Kedro documentation if you find something incorrect or missing, or have other improvement suggestions. - -You can tell us what we should change or make a PR to change it yourself. - -Before you contribute any documentation changes, please read the [Kedro documentation style guidelines](https://github.com/kedro-org/kedro/wiki/Kedro-documentation-style-guide) on the GitHub wiki. - -## How do I rebuild the documentation after I make changes to it? - -Our documentation is written in Markdown and built from by Sphinx, coordinated by a [build script](https://github.com/kedro-org/kedro/blob/main/docs/build-docs.sh). - -If you make changes to the markdown for the Kedro documentation, you can rebuild it within a Unix-like environment (with `pandoc` installed). - -If you are a Windows user, you can still contribute to the documentation, but you cannot rebuild it. This is fine! As long as you have made an effort to verify that your Markdown is rendering correctly, and you have followed our basic guidelines, we will be happy to take your final draft as a pull request and rebuild it for you. - -The following instructions are specifically for people working with documentation who may not already have a development setup. If you are comfortable with virtual environments, cloning and branching from a git repo and using `make` you don't need them and can probably jump to the section called [Build the documentation](#build-the-documentation). - -### Set up to build Kedro documentation - -Follow the setup instructions in the [developer contributor guide](./developer_contributor_guidelines.md#before-you-start-development-set-up) -to fork the Kedro repo, create and activate a Python virtual environment and install the dependencies necessary to build the documentation. - - -### Build the documentation - -**MacOS users** can use `make` commands to build the documentation: - -```bash -make build-docs -``` - -The build will take a few minutes to finish, and a successful result is a set of HTML documentation in `docs/build/html`, which you can review by navigating to the following file and opening it: `docs/build/html/index.html`. - - -## Extend Kedro documentation - -### Add new pages - -All Kedro documentation is collated and built from a single index file, [`index.rst`](https://github.com/kedro-org/kedro/blob/main/docs/source/index.rst) found in the `docs/source` folder. - -If you add extra pages of documentation, you should always include them within `index.rst` file to include them in the table of contents and let Sphinx know to build them alongside the rest of the documentation. - -### Move or remove pages - -To move or remove a page of documentation, first locate it in the repo, and also locate where it is specified in the `index.rst` or `.rst` for the relevant section within the table of contents. - -### Create a pull request - -You need to submit any changes to the documentation via a branch. - -[Find out more about the process of submitting a PR to the Kedro project](./developer_contributor_guidelines.md). - -### Help! - -There is no shame in breaking the documentation build. Sphinx is incredibly fussy and even a single space in the wrong place will sometimes cause problems. A range of other issues can crop up and block you, whether you're technically experienced or less familiar with working with git, conda and Sphinx. - -Ask for help over on [GitHub discussions](https://github.com/kedro-org/kedro/discussions). - -## Kedro documentation style guide - -There is a lightweight [documentation style guide](https://github.com/kedro-org/kedro/wiki/Kedro-documentation-style-guide) on Kedro's GitHub wiki. diff --git a/docs/source/contribution/index.md b/docs/source/contribution/index.md index 40e660bcbd..d2c779bc54 100644 --- a/docs/source/contribution/index.md +++ b/docs/source/contribution/index.md @@ -8,16 +8,14 @@ We welcome any and all contributions to Kedro, at whatever level you can manage. - Make a pull request on the [`awesome-kedro` GitHub repo](https://github.com/kedro-org/awesome-kedro) to update the curated list of Kedro community content - Report a bug or propose a new feature on [GitHub issues](https://github.com/kedro-org/kedro/issues) - [Review other contributors' PRs](https://github.com/kedro-org/kedro/pulls) -- [Contribute code](./developer_contributor_guidelines.md), for example to fix a bug or add a feature -- [Contribute to the documentation](documentation_contributor_guidelines.md) +- [Contribute code](https://github.com/kedro-org/kedro/wiki/Guidelines-for-contributing-developers), for example to fix a bug or add a feature +- [Contribute to the documentation](https://github.com/kedro-org/kedro/wiki/Contribute-to-the-Kedro-documentation) + +Make sure to read our [contribution guidelines](https://github.com/kedro-org/kedro/wiki/Contribute-to-Kedro) on the [Kedro wiki](https://github.com/kedro-org/kedro/wiki). ```{toctree} :hidden: -developer_contributor_guidelines -backwards_compatibility -documentation_contributor_guidelines technical_steering_committee -development_for_databricks ``` From ce5f5e7b0d9624871554e720e81aba1bb832689a Mon Sep 17 00:00:00 2001 From: Jo Stichbury Date: Fri, 11 Aug 2023 08:38:23 +0100 Subject: [PATCH 2/3] Lint docs changes Signed-off-by: Jo Stichbury --- docs/source/contribution/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/contribution/index.md b/docs/source/contribution/index.md index d2c779bc54..6712009a84 100644 --- a/docs/source/contribution/index.md +++ b/docs/source/contribution/index.md @@ -10,7 +10,7 @@ We welcome any and all contributions to Kedro, at whatever level you can manage. - [Review other contributors' PRs](https://github.com/kedro-org/kedro/pulls) - [Contribute code](https://github.com/kedro-org/kedro/wiki/Guidelines-for-contributing-developers), for example to fix a bug or add a feature - [Contribute to the documentation](https://github.com/kedro-org/kedro/wiki/Contribute-to-the-Kedro-documentation) - + Make sure to read our [contribution guidelines](https://github.com/kedro-org/kedro/wiki/Contribute-to-Kedro) on the [Kedro wiki](https://github.com/kedro-org/kedro/wiki). From ecdfae0ab0a27907e52a0b5437ed1ba6b604d656 Mon Sep 17 00:00:00 2001 From: Jo Stichbury Date: Fri, 11 Aug 2023 08:47:08 +0100 Subject: [PATCH 3/3] Few tweaks to index page Signed-off-by: Jo Stichbury --- docs/source/contribution/index.md | 5 +++-- docs/source/contribution/technical_steering_committee.md | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/source/contribution/index.md b/docs/source/contribution/index.md index 6712009a84..a3e1aee36d 100644 --- a/docs/source/contribution/index.md +++ b/docs/source/contribution/index.md @@ -2,7 +2,7 @@ We welcome any and all contributions to Kedro, at whatever level you can manage. For example, you could: -- Join the community on [Slack](https://slack.kedro.org) +- Join the community on [Slack](https://slack.kedro.org) to answer questions - Review Kedro's [GitHub issues](https://github.com/kedro-org/kedro/issues) or raise your own issue to report a bug or feature request - Start a conversation about the Kedro project on [GitHub discussions](https://github.com/kedro-org/kedro/discussions) - Make a pull request on the [`awesome-kedro` GitHub repo](https://github.com/kedro-org/awesome-kedro) to update the curated list of Kedro community content @@ -10,8 +10,9 @@ We welcome any and all contributions to Kedro, at whatever level you can manage. - [Review other contributors' PRs](https://github.com/kedro-org/kedro/pulls) - [Contribute code](https://github.com/kedro-org/kedro/wiki/Guidelines-for-contributing-developers), for example to fix a bug or add a feature - [Contribute to the documentation](https://github.com/kedro-org/kedro/wiki/Contribute-to-the-Kedro-documentation) +- [Write a blog post for blog.kedro.org](https://github.com/kedro-org/kedro-devrel/wiki/Want-to-write-a-blog-post-for-Kedro%3F-Here's-how!) -Make sure to read our [contribution guidelines](https://github.com/kedro-org/kedro/wiki/Contribute-to-Kedro) on the [Kedro wiki](https://github.com/kedro-org/kedro/wiki). +There is further information about contributing to Kedro, including our [developer guidelines](https://github.com/kedro-org/kedro/wiki/Contribute-to-Kedro), on the [Kedro wiki](https://github.com/kedro-org/kedro/wiki). ```{toctree} diff --git a/docs/source/contribution/technical_steering_committee.md b/docs/source/contribution/technical_steering_committee.md index 1760cfd6f6..fdcaebf2ff 100644 --- a/docs/source/contribution/technical_steering_committee.md +++ b/docs/source/contribution/technical_steering_committee.md @@ -1,10 +1,10 @@ -# Join the Technical Steering Committee +# Kedro's Technical Steering Committee -In the Kedro project's latest iteration it is an incubating project within [LF AI & Data](https://lfaidata.foundation/). +Kedro is an incubating project within [LF AI & Data](https://lfaidata.foundation/). The term "Technical Steering Committee" (TSC) describes the group of Kedro maintainers. We list [Kedro's current and past maintainers](#kedro-maintainers) on this page. -The TSC is responsible for the project's future development; you can read about our duties in our [Technical Charter](https://github.com/kedro-org/kedro/blob/main/kedro_technical_charter.pdf). We are happy to accept new members into the TSC to fuel Kedro's continued development. +The TSC is responsible for the project's future development; you can read about our duties in our [Technical Charter](https://github.com/kedro-org/kedro/blob/main/kedro_technical_charter.pdf). We accept new members into the TSC to fuel Kedro's continued development. On this page we describe: