Skip to content

Latest commit

 

History

History
202 lines (137 loc) · 10.2 KB

CONTRIBUTING.md

File metadata and controls

202 lines (137 loc) · 10.2 KB
Raw

Contributing

👍🎉 First off, thank you for taking the time to contribute! 🎉👍

The following is a set of guidelines for contributing. These are just guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

What to know before getting started

Code of Conduct

This project adheres to a Code of Conduct. By participating, you are expected to uphold this code.

Please report unacceptable behavior to one of the Code of Conduct Committee members.

Related repositories

In addition to this repository, InstructLab has two related repositories:

The following sections provide a general overview for contributing to any of the InstructLab repositories.

Contributing overview

Participating in the InstructLab project can come by contributing to any one of the repositories. The following workflow is designed to help you understand contribution best practices, and to help you begin your contribution journey. It will guide you through creating and picking up issues, working through them, having your work reviewed, and then getting your pull request merged.

Help on open source projects is always welcome and there is always something that can be improved. For example, documentation (like the text you are reading now) can always use improvement, code can always be clarified, variables or functions can always be renamed or commented on, and there is always a need for more test coverage. If you see something that you think should be fixed, take ownership!

To contribute code or documentation, please submit a pull request to the relevant repository. Note that contribution to any repository has its own set of requirements and expectations, and users should familiarize themselves with those expectations before contributing.

ilab command-line interface (CLI) tool repository

We welcome contributions in the form of pull requests for documentation updates, code contributions and more. Prior to contribution, users should acquaint themselves with the ilab CLI repository contribution guide.

To submit a pull request to the ilab CLI tool repository, see the pull request page.

Taxonomy repository

We welcome contributions in the form of pull requests for documentation updates, skills contributions, knowledge contributions and more. Prior to contribution, users should acquaint themselves with the taxonomy repository contribution guide.

To submit a pull request to the taxonomy repository, see the pull request page.

Community

We welcome contributions in the form of pull requests for documentation. To submit a pull request to the community repository, see the pull request page.

Getting started with contribution

The InstructLab project uses the Fork and Pull model for contribution that is common in many open source repositories; this entails multiple steps, including forking and cloning the repository, creating a pull request (PR), and more. For details on this process, check out The GitHub Workflow Guide from Kubernetes.

After you have forked and cloned the repository, you can start the contribution process by looking at the issue trackers of the community repository, CLI repository, or the taxonomy repository. You can then pick up an issue by leaving a comment on said issue, and address the issue in a pull request (PR). Prior to submission, make sure that your changes pass formatting, linting, and unit tests. Additionally, all PRs must agree to the terms of Developer Certificate of Origin (DCO) by signing off your commits. Only PRs with commits signed off are accepted. If you didn't sign off your commits before creating the pull request, no worries, you can fix that after the fact. For more information about this process, see Developer Certificate of Origin (DCO).

Then, you can submit the PR to be reviewed. In general, we follow the standard GitHub pull request process. Follow the provided template on your PR to include details about your pull request for the maintainers.

[!IMPORTANT] If you are seeking to make a larger contribution, such as introducing a new feature or functionality, or refactoring a significant portion of the codebase to improve performance, readability, or maintainability, get in touch with us prior to starting. This helps ensure that your time is not wasted working on a change that the project developers will not accept into the codebase.

Pull request review

Once you've created a pull request (PR), maintainers will review your code and may make suggestions to fix before merging. It will be easier for your PR to receive reviews if you consider the criteria the reviewers follow while working. Remember to:

  • Run tests locally and ensure that they pass
  • Follow the project coding conventions
  • Write detailed commit messages
  • Break large changes into a logical series of smaller patches, which are easy to understand individually and combine to solve a broader issue

For a list of the maintainers and triagers, see the MAINTAINERS.md page.

Proposing new features

To propose a new feature, it's best to raise an issue in the appropriate repository:

This way, features can be discussed with the project maintainers, ensuring that your time is not wasted working on a feature that the project developers will not accept into the codebase.

Submitting or fixing bugs

To submit a new bug, raise an issue in the appropriate repository before creating a pull request. This ensures that the issue is appropriately tracked.

To fix an existing bug, leave a comment on the issue that you are working on. Then, create a pull request and submit the pull request for review.

Legal

The following sections detail important legal information that should be viewed prior to contribution.

License and Copyright

Distributed under the Apache License, Version 2.0.

SPDX-License-Identifier: Apache-2.0

If you would like to see the detailed LICENSE click here.

Developer Certificate of Origin (DCO)

We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the same approach - the Developer's Certificate of Origin 1.1 (DCO) - that the Linux® Kernel community uses to manage code contributions.

We ask that when submitting a patch for review, the developer must include a sign-off statement in the commit message. If you set your user.name and user.email in your git config file, you can sign your commit automatically by using the following command:

git commit -s

The following example includes a Signed-off-by: line, which indicates that the submitter has accepted the DCO:

Signed-off-by: John Doe <john.doe@example.com>

We automatically verify that all commit messages contain a Signed-off-by: line with your email address.

Useful tools for doing DCO signoffs

There are a number of tools that make it easier for developers to manage DCO signoffs.

Communication

You can join the InstructLab Slack workspace to communicate with project maintainers and your fellow users.

Additional resources

The following resources include additional information about each repository, such as setting up the environment, testing the environment, coding styles, etc.

ilab CLI tool additional resources

  • ilab CLI tool README.md. This resources provides information about the ilab CLI tool, including an overview, getting started, training the model, submitting a pull request, etc.

  • ilab CLI tool CONTRIBUTING.md. This resources provides information about contributing to the ilab CLI tool repository, reporting bugs, testing, coding styles, etc.

Taxonomy additional resources

  • Taxonomy README.md. This resource provides information about the taxonomy repository, including getting started, YAML examples for skills and knowledge pull requests, how to contribute, etc.

  • Taxonomy CONTRIBUTING.md. This resource contains information and best practices for contributing to the taxonomy repository.