diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000..528bc2f --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,2 @@ +# This should match the owning team set up in https://github.com/orgs/opensearch-project/teams +* @Rajrahane @navneet1v @yigithub @vamshin @jed326 @rchitale7 @owenhalpert @neetikasinghal diff --git a/.github/ISSUE_TEMPLATE/BUG_TEMPLATE.md b/.github/ISSUE_TEMPLATE/BUG_TEMPLATE.md new file mode 100644 index 0000000..55a660b --- /dev/null +++ b/.github/ISSUE_TEMPLATE/BUG_TEMPLATE.md @@ -0,0 +1,24 @@ +--- +name: 🐛 Bug Report +about: Create a report to help us improve +title: '[BUG]' +labels: 'bug, untriaged' +assignees: '' +--- +### What is the bug? +_A clear and concise description of the bug._ + +### How can one reproduce the bug? +_Steps to reproduce the behavior._ + +### What is the expected behavior? +_A clear and concise description of what you expected to happen._ + +### What is your host/environment? +_Operating system, version._ + +### Do you have any screenshots? +_If applicable, add screenshots to help explain your problem._ + +### Do you have any additional context? +_Add any other context about the problem._ diff --git a/.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md b/.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..df7215d --- /dev/null +++ b/.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md @@ -0,0 +1,18 @@ +--- +name: 🎆 Feature Request +about: Request a feature in this project +title: '[FEATURE]' +labels: 'enhancement, untriaged' +assignees: '' +--- +### Is your feature request related to a problem? +_A clear and concise description of what the problem is, e.g. I'm always frustrated when [...]._ + +### What solution would you like? +_A clear and concise description of what you want to happen._ + +### What alternatives have you considered? +_A clear and concise description of any alternative solutions or features you've considered._ + +### Do you have any additional context? +_Add any other context or screenshots about the feature request here._ diff --git a/.github/ISSUE_TEMPLATE/GITHUB_REQUEST_TEMPLATE.yaml b/.github/ISSUE_TEMPLATE/GITHUB_REQUEST_TEMPLATE.yaml new file mode 100644 index 0000000..0e662cd --- /dev/null +++ b/.github/ISSUE_TEMPLATE/GITHUB_REQUEST_TEMPLATE.yaml @@ -0,0 +1,51 @@ +--- +name: '⚙️ GitHub Request' +description: 'Request an update to permissions/management/settings on the opensearch-project GitHub organization or its repositories.' +title: '[GitHub Request]' +labels: ['github-request'] +body: + - type: markdown + attributes: + value: | + Thanks for taking the time to submit this GitHub Request! Please note that the estimated time for the request to be resolved is 7-10 days from the time of the request. + - type: dropdown + attributes: + description: 'Provide request type.' + label: 'What is the type of request?' + multiple: false + options: + - # Empty first option to force selection. + - User Permission + - Organization Membership + - Repository Management + - Settings Update + - Secret Update + - GitHub Action + - Other + validations: + required: true + - type: textarea + attributes: + description: 'Describe the actions you are requesting (e.g., GitHub Actions in the take too long to allocate runners). If this is about a repository, please contact the corresponding maintainers before raising the issue.' + label: 'Details of the request' + validations: + required: true + - type: textarea + attributes: + description: 'Provide reasons for your request. For example, if you request to add a new maintainer to a repository, confirm that you have followed the steps in the [Becoming a Maintainer](https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#becoming-a-maintainer) guide, and provide the required materials and votes.' + label: 'Additional information to support your request' + validations: + required: true + - type: textarea + attributes: + description: 'Provide the timeline of your request. Requests typically require 7-10 business days to process. Specify your request timeline and whether or not it is an urgent request.' + label: 'When does this request need to be completed?' + validations: + required: true + - type: textarea + attributes: + label: 'Notes' + value: | + Track the progress of your request here: https://github.com/orgs/opensearch-project/projects/208/views/33. + Member of @opensearch-project/admin will take a look at the request soon. + Thanks! diff --git a/.github/ISSUE_TEMPLATE/PROPOSAL_TEMPLATE.md b/.github/ISSUE_TEMPLATE/PROPOSAL_TEMPLATE.md new file mode 100644 index 0000000..5853405 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/PROPOSAL_TEMPLATE.md @@ -0,0 +1,40 @@ +--- +name: 💭 Proposal +about: Suggest an idea for a specific feature you wish to propose to the community for comment +title: '[PROPOSAL]' +labels: proposal +assignees: '' +--- +## What/Why +### What are you proposing? +_In a few sentences, describe the feature and its core capabilities._ + +### What users have asked for this feature? +_Highlight any research, proposals, requests or anecdotes that signal this is the right thing to build. Include links to GitHub Issues, Forums, Stack Overflow, Twitter, etc._ + +### What problems are you trying to solve? +_Summarize the core use cases and user problems and needs you are trying to solve. Describe the most important user needs, pain points and jobs as expressed by the user asks above. Template: When \ , a \ wants to \, so they can \ (e.g. When **searching by postal code**, **a buyer** wants to **be required to enter a valid code** so they **don’t waste time searching for a clearly invalid postal code.**)._ + +### What is the developer experience going to be? +_Does this have a REST API? If so, please describe the API and any impact it may have to existing APIs. In a brief summary (not a spec), highlight what new REST APIs or changes to REST APIs are planned. as well as any other API, CLI or Configuration changes that are planned as part of this feature._ + +#### Are there any security considerations? +_Describe whether the feature has any security considerations or impact. What is the security model of the new APIs? Features should be integrated into the OpenSearch security suite and so if they are not, we should highlight the reasons here._ + +#### Are there any breaking changes to the API +_If this feature will require breaking changes to any APIs, outline what those will be and why they are needed. What is the path to minimizing impact? (e.g. add new API and deprecate the old one)._ + +### What is the user experience going to be? +_Describe the feature requirements and or user stories. You may include low-fidelity sketches, wireframes, APIs stubs, or other examples of how a user would use the feature via CLI, OpenSearch Dashboards, REST API, etc. Using a bulleted list or simple diagrams to outline features is okay. If this is net new functionality, call this out as well._ + +#### Are there breaking changes to the User Experience? +_Will this change the existing user experience? Will this be a breaking change from a user flow or user experience perspective?_ + +### Why should it be built? Any reason not to? +_Describe the value that this feature will bring to the OpenSearch community, as well as what impact it has if it isn't built, or new risks if it is. Highlight opportunities for additional research._ + +### What will it take to execute? +_Describe what it will take to build this feature. Are there any assumptions you may be making that could limit scope or add limitations? Are there performance, cost, or technical constraints that may impact the user experience? Does this feature depend on other feature work? What additional risks are there?_ + +### Any remaining open questions? +_What are known enhancements to this feature? Any enhancements that may be out of scope but that we will want to track long term? List any other open questions that may need to be answered before proceeding with an implementation._ diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml new file mode 100644 index 0000000..826b2f0 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -0,0 +1,10 @@ +contact_links: + - name: 💬 OpenSearch Community Slack Workspace + url: https://opensearch.org/slack.html + about: Chat with community members and maintainers here. + - name: 🤷 OpenSearch Community Forum + url: https://forum.opensearch.org/ + about: Ask and answer OpenSearch usage questions here. + - name: 🔐 Report a Security Issue + url: https://github.com/opensearch-project/.github/blob/main/SECURITY.md + about: Please e-mail security@opensearch.org. Do not create a public GitHub issue. \ No newline at end of file diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..59bfd18 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,8 @@ +### Description +_Describe what this change achieves._ + +### Issues Resolved +_List any issues this PR will resolve, e.g. Closes [...]._ + +By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. +For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). \ No newline at end of file diff --git a/.github/workflows/add-untriaged.yml b/.github/workflows/add-untriaged.yml new file mode 100644 index 0000000..c6a64fd --- /dev/null +++ b/.github/workflows/add-untriaged.yml @@ -0,0 +1,19 @@ +name: Apply 'untriaged' label during issue lifecycle + +on: + issues: + types: [opened, reopened, transferred] + +jobs: + apply-label: + runs-on: ubuntu-latest + steps: + - uses: actions/github-script@v6 + with: + script: | + github.rest.issues.addLabels({ + issue_number: context.issue.number, + owner: context.repo.owner, + repo: context.repo.repo, + labels: ['untriaged'] + }) \ No newline at end of file diff --git a/.github/workflows/link-checker.yml b/.github/workflows/link-checker.yml new file mode 100644 index 0000000..a8190a8 --- /dev/null +++ b/.github/workflows/link-checker.yml @@ -0,0 +1,17 @@ +name: Link Checker +on: [push, pull_request] + +jobs: + linkchecker: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - name: Lychee Link Checker + id: lychee + uses: lycheeverse/lychee-action@master + with: + args: --accept=200,403,429 "./**/*.md" "./**/*.txt" + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + - name: Fail on Error + run: exit ${{ steps.lychee.outputs.exit_code }} \ No newline at end of file diff --git a/.lycheeignore b/.lycheeignore new file mode 100644 index 0000000..6f90455 --- /dev/null +++ b/.lycheeignore @@ -0,0 +1 @@ +https://playground.opensearch.org/* \ No newline at end of file diff --git a/ADMINS.md b/ADMINS.md new file mode 100644 index 0000000..c0f73b0 --- /dev/null +++ b/ADMINS.md @@ -0,0 +1,61 @@ +- [Overview](#overview) +- [Current Admins](#current-admins) +- [Admin Permissions](#admin-permissions) + - [Prioritize Security](#prioritize-security) + - [Enforce Code of Conduct](#enforce-code-of-conduct) + - [Add/Remove Maintainers](#addremove-maintainers) + - [Adopt Organizational Practices](#adopt-organizational-practices) +- [New Repos](#new-repos) + +## Overview + +This document explains who the admins are (see below), what they do in opensearch-project, and how they should be doing it. These individuals are members of an "admin" GitHub team that is given Admin-level permissions to every repository in opensearch-project organization. These are individuals that worked on creating the OpenSearch fork, and those that currently support the organization-wide infrastructure, such as the public [CI/CD](https://build.ci.opensearch.org/). + +If you're interested in becoming a maintainer, see [MAINTAINERS](MAINTAINERS.md). If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). + +## Current Admins + +| Admin | GitHub ID | Affiliation | +| ------------------------ | --------------------------------------------------------- | ----------- | +| Navneet Verma | [navneet1v](https://github.com/navneet1v ) | Amazon | +| Rajvaibhav Rahane | [Rajrahane](https://github.com/Rajrahane) | Amazon | +| Vamshi Vijay Nakkirtha | [vamshin](https://github.com/vamshin) | Amazon | +| Yigit Kiran | [yigithub](https://github.com/yigithub) | Amazon | +| Jay Deng | [jed326](https://github.com/jed326) | Amazon | +| Rohan Chitale | [rchitale7](https://github.com/rchitale7) | Amazon | +| Owen Halpert | [owenhalpert](https://github.com/owenhalpert) | Amazon | +| Neetika Singhal | [neetikasinghal](https://github.com/neetikasinghal) | Amazon | + +## Admin Permissions + +Admins have [admin-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and protect the repository as follows. + +### Prioritize Security + +Security is your number one priority. Manage security keys and safeguard access to the repository. + +Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details. + +### Enforce Code of Conduct + +Act on [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md) violations by revoking access, and blocking malicious actors. + +### Add/Remove Maintainers + +Perform administrative tasks, such as [adding](RESPONSIBILITIES.md#adding-a-new-maintainer) and [removing maintainers](RESPONSIBILITIES.md#removing-a-maintainer). + +Please note that maintainers typically do not have admin-level permissions in their repos in this organization. Admin-level permissions allow for sensitive and destructive actions, such as managing security, or deleting a repository. Therefore, admin access in opensearch-project was designed to be deliberately centralized in ways that requires that two people to make any one sensitive change. If you need to perform an admin function, such as adding or removing a maintainer, please [follow the maintainer nomination process](RESPONSIBILITIES.md#becoming-a-maintainer), then ask to effect permissions by tagging `@admin` in your pull request, or the [#maintainers channel on the public Slack](https://opensearch.slack.com/archives/C05L60S4UBT). One of the above-mentioned admins will make this change for you. + +### Adopt Organizational Practices + +Adopt organizational practices documented in this repo, work in the open, and collaborate with other admins by opening issues before making process changes. Prefer consistency, and avoid diverging from practices in the opensearch-project organization. + +## New Repos + +There are currently two ways new repositories may appear in the opensearch-project organization: creating a new repo and adopting, or moving a repo from outside of the organization into it. The process is the same. + +The AWS Open Source Program Office (OSPO) currently owns and manages the opensearch-project organization, and has permissions to create a new repo. This will change shortly following the [formation of the OpenSearch Software Foundation](https://foundation.opensearch.org/). While the admins above have admin-level permissions, they do not have permissions to create new repositories or move repositories into the organization. + +All new repositories inside opensearch-project follow the [security response process](SECURITY.md), and therefore require an Amazon team to be engaged when necessary. If you wish to create a repository in this organization, or move a repository into opensearch-project, please contact one of the above-mentioned admins via the [#maintainers channel on the public Slack](https://opensearch.slack.com/archives/C05L60S4UBT). + +While the opensearch-project organization has adopted [opensearch-plugin-template-java](https://github.com/opensearch-project/opensearch-plugin-template-java), or [opensearch-project/opensearch-learning-to-rank-base](https://github.com/opensearch-project/opensearch-learning-to-rank-base) in the past, we generally encourage you to start and run with your open-source project outside of the organization, and only consider making it part of it when you wish to include your already very popular component or tool in the "official" distribution. To request moving a repo into this organization, please open a proposal in your repo, have repo maintainers confirm they wish to move, and engage admins via the [#admin-requests channel on the public Slack](https://opensearch.slack.com/archives/C051CKVFB2A). \ No newline at end of file diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..c511573 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,24 @@ + +This code of conduct applies to all spaces provided by the OpenSource project including in code, documentation, issue trackers, mailing lists, chat channels, wikis, blogs, social media, events, conferences, meetings, and any other communication channels used by the project. + +**Our open source communities endeavor to:** + +* Be Inclusive: We are committed to being a community where everyone can join and contribute. This means using inclusive and welcoming language. +* Be Welcoming: We are committed to maintaining a safe space for everyone to be able to contribute. +* Be Respectful: We are committed to encouraging differing viewpoints, accepting constructive criticism and work collaboratively towards decisions that help the project grow. Disrespectful and unacceptable behavior will not be tolerated. +* Be Collaborative: We are committed to supporting what is best for our community and users. When we build anything for the benefit of the project, we should document the work we do and communicate to others on how this affects their work. + +**Our Responsibility. As contributors, members, or bystanders we each individually have the responsibility to behave professionally and respectfully at all times. Disrespectful and unacceptable behaviors include, but are not limited to:** + +* The use of violent threats, abusive, discriminatory, or derogatory language; +* Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, race, political or religious affiliation; +* Posting of sexually explicit or violent content; +* The use of sexualized language and unwelcome sexual attention or advances; +* Public or private harassment of any kind; +* Publishing private information, such as physical or electronic address, without permission; +* Other conduct which could reasonably be considered inappropriate in a professional setting; +* Advocating for or encouraging any of the above behaviors. + +**Enforcement and Reporting Code of Conduct Issues:** + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported. [Contact us](mailto:conduct@opensearch.foundation). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..e193543 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,178 @@ +- [Contributing to OpenSearch](#contributing-to-opensearch) +- [First Things First](#first-things-first) +- [Ways to Contribute](#ways-to-contribute) + - [Bug Reports](#bug-reports) + - [Feature Requests \& Proposals](#feature-requests--proposals) + - [Documentation Changes](#documentation-changes) + - [Contributing Code](#contributing-code) +- [Developer Certificate of Origin](#developer-certificate-of-origin) + - [Troubleshooting Failed DCO Checks](#troubleshooting-failed-dco-checks) +- [License Headers](#license-headers) + - [Java](#java) + - [Python, Ruby, Shell](#python-ruby-shell) +- [Review Process](#review-process) +- [Using Feature Branches](#using-feature-branches) +- [Experimental Features](#experimental-features) + +## Contributing to OpenSearch + +OpenSearch, a member of non-profit Linux Foundation, is a community project that is built and maintained by people just like **you**. We're glad you're interested in helping out. There are several different ways you can do it, but before we talk about that, let's talk about how to get started. + +## First Things First + +1. **When in doubt, open an issue** - For almost any type of contribution, the first step is opening an issue. Even if you think you already know what the solution is, writing down a description of the problem you're trying to solve will help everyone get context when they review your pull request. If it's truly a trivial change (e.g. spelling error), you can skip this step -- but as the subject says, when it doubt, [open an issue](https://github.com/opensearch-project/.github/issues). + +2. **Only submit your own work** (or work you have sufficient rights to submit) - Please make sure that any code or documentation you submit is your work or you have the rights to submit. We respect the intellectual property rights of others, and as part of contributing, we'll ask you to sign your contribution with a "Developer Certificate of Origin" (DCO) that states you have the rights to submit this work and you understand we'll use your contribution. There's more information about this topic in the [DCO section](#developer-certificate-of-origin). + +3. When you're ready to start, we have [a step-by-step onboarding guide](ONBOARDING.md) to help you get oriented. + +## Ways to Contribute + +### Bug Reports + +Ugh! Bugs! + +A bug is when software behaves in a way that you didn't expect and the developer didn't intend. To help us understand what's going on, we first want to make sure you're working from the latest version. + +Once you've confirmed that the bug still exists in the latest version, you'll want to check to make sure it's not something we already know about on the [open issues GitHub page](https://github.com/opensearch-project/.github/issues). + +If you've upgraded to the latest version and you can't find it in our open issues list, then you'll need to tell us how to reproduce it Provide as much information as you can. You may think that the problem lies with your query, when actually it depends on how your data is indexed. The easier it is for us to recreate your problem, the faster it is likely to be fixed. + +### Feature Requests & Proposals + +If you've thought of a way that OpenSearch could be better, we want to hear about it. We track `feature requests` ([examples](https://github.com/search?q=org%3Aopensearch-project+%22Is+your+feature+request+related+to+a+problem%3F%22&type=Issues)) using GitHub, so please feel free to open an issue which describes the feature you would like to see, why you need it, and how it should work. If you would like contribute code toward building it, you might consider a `feature proposal` ([examples](https://github.com/search?q=org%3Aopensearch-project+%22How+did+you+come+up+with+this+proposal%3F%22&type=Issues)) instead. A feature proposal is the first step to helping the community better understand what you are planning to contribute, why it should be built, and collaborate on ensuring you have all the data points you need for implementation. + +### Documentation Changes + +There are two types of documentation in OpenSearch: developer documentation, which describes how OpenSearch is designed internally, and user documentation, which describes how to use OpenSearch. + +Developer documentation is maintained in the repository to which it pertains. The workflow for contributing developer documentation is the same as the one for contributing code. + +User documentation is maintained in the [documentation-website](https://github.com/opensearch-project/documentation-website/) repo. You can find the rendered documentation at [opensearch.org/docs](https://opensearch.org/docs). To learn how to contribute user documentation, see the [contribution guidelines](https://github.com/opensearch-project/documentation-website/blob/main/CONTRIBUTING.md). + +### Contributing Code + +As with other types of contributions, the first step is to [open an issue on GitHub](https://github.com/opensearch-project/.github/issues/new/choose). Opening an issue before you make changes makes sure that someone else isn't already working on that particular problem. It also lets us all work together to find the right approach before you spend a bunch of time on a PR. So again, when in doubt, open an issue. + +## Developer Certificate of Origin + +OpenSearch is an open source product released under the Apache 2.0 license (see either [the Apache site](https://www.apache.org/licenses/LICENSE-2.0) or the [LICENSE.txt file](LICENSE.txt)). The Apache 2.0 license allows you to freely use, modify, distribute, and sell your own products that include Apache 2.0 licensed software. + +We respect intellectual property rights of others and we want to make sure all incoming contributions are correctly attributed and licensed. A Developer Certificate of Origin (DCO) is a lightweight mechanism to do that. + +The DCO is a declaration attached to every contribution made by every developer. That representation is important for legal purposes and was the community-developed outcome after a [$1 billion lawsuit by SCO against IBM](https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes). The representation is designed to prevent issues but also keep the burden on contributors low. It has proven very adaptable to other projects, is built into git itself (and now also GitHub), and is in use by thousands of projects to avoid more burdensome requirements to contribute (such as a CLA). + +In the commit message of the contribution, the developer simply adds a `Signed-off-by` statement and thereby agrees to the DCO, which you can find below or at [DeveloperCertificate.org](http://developercertificate.org/). + +``` +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the + best of my knowledge, is covered under an appropriate open + source license and I have the right under that license to + submit that work with modifications, whether created in whole + or in part by me, under the same open source license (unless + I am permitted to submit under a different license), as + Indicated in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including + all personal information I submit with it, including my + sign-off) is maintained indefinitely and may be redistributed + consistent with this project or the open source license(s) + involved. + ``` + +We require that every contribution to OpenSearch is signed with a Developer Certificate of Origin. + +DCO checks are enabled via a [DCO workflow app](https://github.com/apps/dco) across the entire opensearch-project organization, and your PR will fail CI without it. + +Additionally, we kindly ask you to use your real name. A real name does not require a legal name, nor a birth name, nor any name that appears on an official ID (e.g. a passport). Your real name is the name you convey to people in the community for them to use to identify you as you. The key concern is that your identification is sufficient enough to contact you if an issue were to arise in the future about your contribution. Thus, your real name should not be an anonymous id or false name that misrepresents who you are. + +Each commit must include a DCO which looks like this, which includes a real name and a valid email address where you can receive emails: + +``` +Signed-off-by: Jane Smith +``` + +You may type this line on your own when writing your commit messages. However, if your `user.name` and `user.email` are set in your `git config`, you can use `-s` or `--signoff` to add the `Signed-off-by` line to the end of the commit message automatically. + +Forgot to add DCO to a commit? Amend it with `git commit --amend -s`. + +### Troubleshooting Failed DCO Checks + +The DCO workflow app requires signatures on every commit that's part of a PR. + +If you've already signed all your commits and your PR still fails the DCO check, it's likely because the email address you signed the commit with doesn't match the one on your GitHub account. + +To fix: + +1. Go to [your GitHub email settings](https://github.com/settings/emails) and uncheck "Keep my email address private". +2. Following the [GitHub documentation](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#setting-your-commit-email-address-in-git), set your commit email address to your primary GitHub email address. + +## License Headers + +New files in your code contributions should contain the following license header. If you are modifying existing files with license headers, or including new files that already have license headers, do not remove or modify them without guidance. + +### Java + +``` +/* + * Copyright OpenSearch Contributors + * SPDX-License-Identifier: Apache-2.0 + * + * The OpenSearch Contributors require contributions made to + * this file be licensed under the Apache-2.0 license or a + * compatible open source license. + * +*/ +``` + +### Python, Ruby, Shell +``` +# Copyright OpenSearch Contributors +# SPDX-License-Identifier: Apache-2.0 +# +# The OpenSearch Contributors require contributions made to +# this file be licensed under the Apache-2.0 license or a +# compatible open source license. +``` + +## Review Process + +We deeply appreciate everyone who takes the time to make a contribution. We will review all contributions as quickly as possible. As a reminder, [opening an issue](https://github.com/opensearch-project/.github/issues/new/choose) discussing your change before you make it is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction. + +During the PR process, expect that there will be some back-and-forth. Please try to respond to comments in a timely fashion, and if you don't wish to continue with the PR, let us know. If a PR takes too many iterations for its complexity or size, we may reject it. Additionally, if you stop responding we may close the PR as abandoned. In either case, if you feel this was done in error, please add a comment on the PR. + +If we accept the PR, a [maintainer](MAINTAINERS.md) will merge your change and usually take care of backporting it to appropriate branches ourselves. + +If we reject the PR, we will close the pull request with a comment explaining why. This decision isn't always final: if you feel we have misunderstood your intended change or otherwise think that we should reconsider then please continue the conversation with a comment on the PR and we'll do our best to address any further points you raise. + +## Using Feature Branches + +Our recommended approach for development is doing frequent small PR merges to main. This lets us catch integration issues earlier, makes it easier to review your PRs and makes your development visible to everyone. It's okay if it's not the complete feature, as long as the PR won’t break a build or any existing functionality. + +But sometimes it may be useful to create a feature branch. This allows you work on long-running disruptive features in isolation. The reason we don't recommend it is because it still requires maintainer access to merge changes, and the overhead of rebasing is high. If you do want to use a feature branch: + +1. Treat feature branch PR's the same as PR's to `main`. CI should run on all PR's, no incomplete work should be merged, tests are necessary, etc. + a. This maintains the code quality going into each feature making the integration to main PR's much easier and quicker. + b. More visibility during development since it gives reviewers the necessary time to review each PR. +2. Please use Feature specific labels: This helps identify feature related issues and PR's. + +All the safeguard here are not rules but guidelines and should be adopted by each repository based on their specific requirements. This is to ensure that feature branch development is less likely to have code quality issues and massive merge to main PR's. + +For contributors looking to add a new feature that would require the creation of a feature branch, the process begins by opening an issue in the repo with the feature proposal. Depending on the nature of the feature, the maintainers of the project can decide to create a feature branch and use this model. + +## Experimental Features + +Experimental releases are used to gather early feedback on features. Features should only be marked experimental if there is a high likelihood that API or experience will change. We strongly advise people to avoid using experimental features in production as there is no guarantee the API or experience won't change before release. It is best to avoid experimental feature releases unless it is necessary. Our goal is to have all experimental features into production or removed within 2 minor releases. We generally use [Feature Flags](https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md#experimental-development) to isolate experimental features in backend code. \ No newline at end of file diff --git a/FEATURES.md b/FEATURES.md new file mode 100644 index 0000000..ab2bc2a --- /dev/null +++ b/FEATURES.md @@ -0,0 +1,16 @@ +# Proposing Features + +A feature request or proposal is an issue opened on a repo in opensearch-project that states an end-user problem, and proposes a solution in the form of a feature. It should meet the following criteria. + +- Contains a real use-case or describes a problem. +- Is a good fit with existing features and the overall direction of the repo and project. +- Is distinct from existing features. +- Is atomic. + +The primary goal of a feature request is to brainstorm the solutions with the community early. The feature proposal should be opened in the idea stage, or as soon as a problem has been encountered. A technical or an implementation design is not required, but it's recommended to include ideas of possible approaches if you have any. Feature requests are usually labelled as `enhancement` or `feature`, depending on the repo, and often use the [recommended template](.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md). + +Repo maintainers regularly [triage](TRIAGING.md) new feature requests to determine whether they are valid. There should be no expectation that anyone will pickup the feature request and work on it, including the person who opened it. + +Most features can be elevated to the project [roadmap](https://github.com/orgs/opensearch-project/projects/1) by tagging them with a "roadmap" label and a target version number. See [maintaining the project roadmap](RESPONSIBILITIES.md#manage-roadmap) for more information. + +Finally, features should be given time before appreciable work begins, allowing for community to voice opinions. \ No newline at end of file diff --git a/LICENSE.txt b/LICENSE.txt new file mode 100644 index 0000000..f49a4e1 --- /dev/null +++ b/LICENSE.txt @@ -0,0 +1,201 @@ + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + + 4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + + 5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + + 6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + + 7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + + 8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + + 9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + + END OF TERMS AND CONDITIONS + + APPENDIX: How to apply the Apache License to your work. + + To apply the Apache License to your work, attach the following + boilerplate notice, with the fields enclosed by brackets "[]" + replaced with your own identifying information. (Don't include + the brackets!) The text should be enclosed in the appropriate + comment syntax for the file format. We also recommend that a + file or class name and description of purpose be included on the + same "printed page" as the copyright notice for easier + identification within third-party archives. + + Copyright [yyyy] [name of copyright owner] + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. \ No newline at end of file diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 0000000..febb9cf --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,25 @@ +- [Overview](#overview) +- [Current Maintainers](#current-maintainers) +- [Emeritus](#emeritus) + +## Overview + +This document contains a list of maintainers in this repo. See [opensearch-project/.github/RESPONSIBILITIES.md](https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#maintainer-responsibilities) that explains what the role of maintainer means, what maintainers do in this and other repos, and how they should be doing it. If you're interested in contributing, and becoming a maintainer, see [CONTRIBUTING](CONTRIBUTING.md). + +## Current Maintainers + +| Maintainer | GitHub ID | Affiliation | +| ------------------------ | --------------------------------------------------------- | ----------- | +| Navneet Verma | [navneet1v](https://github.com/navneet1v ) | Amazon | +| Rajvaibhav Rahane | [Rajrahane](https://github.com/Rajrahane) | Amazon | +| Vamshi Vijay Nakkirtha | [vamshin](https://github.com/vamshin) | Amazon | +| Yigit Kiran | [yigithub](https://github.com/yigithub) | Amazon | +| Jay Deng | [jed326](https://github.com/jed326) | Amazon | +| Rohan Chitale | [rchitale7](https://github.com/rchitale7) | Amazon | +| Owen Halpert | [owenhalpert](https://github.com/owenhalpert) | Amazon | +| Neetika Singhal | [neetikasinghal](https://github.com/neetikasinghal) | Amazon | + +## Emeritus + +| Maintainer | GitHub ID | Affiliation | +| ------------------------ | --------------------------------------------------------- | ----------- | \ No newline at end of file diff --git a/NOTICE.txt b/NOTICE.txt new file mode 100644 index 0000000..46ffe3b --- /dev/null +++ b/NOTICE.txt @@ -0,0 +1,2 @@ +OpenSearch (https://opensearch.org/) +Copyright OpenSearch Contributors \ No newline at end of file diff --git a/ONBOARDING.md b/ONBOARDING.md new file mode 100644 index 0000000..a42c6df --- /dev/null +++ b/ONBOARDING.md @@ -0,0 +1,90 @@ +- [Getting Started as an OpenSearch Project Contributor](#getting-started-as-an-opensearch-project-contributor) + - [Introduction](#introduction) + - [Who is this for?](#who-is-this-for) + - [What will this guide help you do?](#what-will-this-guide-help-you-do) + - [Key Concepts](#key-concepts) + - [About the OpenSearch Project](#about-the-opensearch-project) + - [How We Work](#how-we-work) + - [Contributor Expectations](#contributor-expectations) + - [Resources and Links](#resources-and-links) + - [Set Up Accounts and Access](#set-up-accounts-and-access) + - [GitHub Account](#github-account) + - [OpenSearch Forum and Slack Accounts](#opensearch-forum-and-slack-accounts) + +# Getting Started as an OpenSearch Project Contributor + +## Introduction + +### Who is this for? + +Anyone who's interested in contributing code (features, fixes, documentation) to one of the OpenSearch Project open-source repositories for the first time. + +### What will this guide help you do? + +1. Understand the key concepts of the OpenSearch Project and how to find additional resources. +2. Set up the accounts you'll need to contribute. + +## Key Concepts + +### About the OpenSearch Project + +- **Read (3 min) [the project homepage](https://opensearch.org/)** to get a sense of what the OpenSearch software does and how it's used. +- **Read (4 min) "[About OpenSearch](https://opensearch.org/about.html)"** to understand the primary project components and development principles. +- Optional - Read founding documents to understand the project history + - Read (2 min) "[Linux Foundation Announces OpenSearch Software Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-opensearch-software-foundation-to-foster-open-collaboration-in-search-and-analytics) from September, 2024. + - Read (8 min) "[Introducing OpenSearch](https://aws.amazon.com/blogs/opensource/introducing-opensearch/)" from April, 2021. + - Read (6 min) "[Stepping up for a truly open source Elasticsearch](https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/)" from January, 2021. + +### How We Work + +We model our way of working on "[the Apache Way](https://apache.org/theapacheway)" (optional - read 4 min). Specifically, we've borrowed and adapted: + +- *Community Over Code:* A healthy community is a higher priority than good code. Strong communities can always rectify problems with their code, whereas an unhealthy community will likely struggle to maintain a codebase in a sustainable manner. +- *Earned Authority:* All individuals are given the opportunity to participate, but their influence is based on publicly earned merit – what they contribute to the community. Merit lies with the individual, does not expire, is not influenced by employment status or employer, and is non-transferable (merit earned in one project cannot be applied to another). +- *Open Communications:* All communications related to code and decision-making should be publicly accessible to ensure asynchronous collaboration, as necessitated by a globally-distributed community. +- *Community of Peers:* Individuals participate, not organizations. Roles are equal irrespective of title, votes hold equal weight, and contributions are made on a voluntary basis (even if paid to work on code). +- *Progress over Perfection:* Struggling with a test failure? Can't quite figure out why that data structure isn't doing what you expect? Feeling defeated by the complexities of that massively distributed compute engine? The community idea exists to help each other through difficult problems. So fail early, commit often, ask for help, and don't be afraid. + +### Contributor Expectations + +Contributors are subject to a code of conduct, and it's essential that all contributions are original work. + +- **Read (6 min) [the OpenSearch Code of Conduct](https://opensearch.org/codeofconduct.html)**. +- **Read (6 min) [the OpenSearch CONTRIBUTING Guide](https://github.com/opensearch-project/.github/blob/main/CONTRIBUTING.md)**. Please make sure you understand the implications of the [Developer Certificate of Origin](https://github.com/opensearch-project/.github/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). + +### Resources and Links + +There are more than 100 [GitHub repositories](https://github.com/orgs/opensearch-project/repositories?q=&type=public&language=&sort=) that are part of the OpenSearch project. Explore the list to get a sense of the project breadth and scope. + +- The [roadmap](https://github.com/orgs/opensearch-project/projects/220) provides a single place to keep track of upcoming releases and current projects. + +Looking for answers? While [the forum](https://forum.opensearch.org/) and [Slack](https://opensearch.org/slack.html) are always a good option, it's worth checking these first. + +- [Frequently Asked Questions](https://opensearch.org/faq). +- [User Documentation](https://opensearch.org/docs/latest/). +- Developer Documentation + - Start with `DEVELOPER_GUIDE.md` in the repository you'll be working in (see [OpenSearch](https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md) or [OpenSearch Dashboards](https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/DEVELOPER_GUIDE.md) guides). + - Most repositories have many other documentation files. To find them, search for Markdown files (`*.md` - [example](https://github.com/search?q=repo%3Aopensearch-project%2FOpenSearch-Dashboards+language%3AMarkdown&type=code&l=Markdown)), either on GitHub or in your editor. + +## Set Up Accounts and Access + +### GitHub Account + +To create issues, leave comments, or submit pull requests, you'll need a GitHub account. Already have a GitHub account? Great! If not, it's quick to get started. (We've summarized the most important steps for the OpenSearch project here, but for more complete information, see the [GitHub documentation](https://docs.github.com/en/get-started/onboarding/getting-started-with-your-github-account).) + +1. **Do (2 min) Sign up for an account** by navigating to https://github.com/ and following the prompts ([source](https://docs.github.com/en/get-started/onboarding/getting-started-with-your-github-account#1-creating-an-account)). +2. **Do (4 min) [Verify your email address](https://docs.github.com/en/get-started/signing-up-for-github/verifying-your-email-address)**. +3. Recommended - Do (20 min) Set up GitHub to connect with SSH + 1. [Check for existing SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/checking-for-existing-ssh-keys). + 2. [Generate new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent). + 3. [Add a new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account). + 4. [Test your SSH connection](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection). +4. Recommended - Do (8 min) [Configure 2-factor authentication](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication). +5. Optional - Read (5 min) If you're new to using GitHub or git, we recommend reviewing "[Using GitHub's tools and processes](https://docs.github.com/en/get-started/onboarding/getting-started-with-your-github-account#part-2-using-githubs-tools-and-processes)". + +### OpenSearch Forum and Slack Accounts + +There are multiple ways to [connect with the OpenSearch community](https://opensearch.org/connect.html), [the forum](https://forum.opensearch.org/) and [Slack](https://www.opensearch.org/slack.html) are the best places to start. + +- **Do (2 min)** [create an OpenSearch forum](https://forum.opensearch.org/) account. +- **Do (2 min)** [create an OpenSearch Slack](https://www.opensearch.org/slack.html) account. \ No newline at end of file diff --git a/OpenSearch.svg b/OpenSearch.svg new file mode 100644 index 0000000..bd4ae0f --- /dev/null +++ b/OpenSearch.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/README.md b/README.md index 7581699..f882d26 100644 --- a/README.md +++ b/README.md @@ -1 +1,53 @@ -# remote-vector-index-builder- \ No newline at end of file +![OpenSearch logo](OpenSearch.svg) +# Remote Vector Index Builder + +- [Welcome!](#welcome) +- [Project Resources](#project-resources) +- [Project Style Guidelines](#project-style-guidelines) +- [Code of Conduct](#code-of-conduct) +- [License](#license) +- [Copyright](#copyright) + +## Welcome! + +**OpenSearch Project** is [a community-driven, open source fork](https://aws.amazon.com/blogs/opensource/introducing-opensearch/) of [Elasticsearch](https://en.wikipedia.org/wiki/Elasticsearch) and [Kibana](https://en.wikipedia.org/wiki/Kibana) licensed under the [Apache v2.0 License](LICENSE.txt). + +OpenSearch is supported by [The OpenSearch Software Foundation](https://foundation.opensearch.org/), a project of [The Linux Foundation](https://www.linuxfoundation.org/). You can read the launch announcement [here](https://www.linuxfoundation.org/press/linux-foundation-announces-opensearch-software-foundation-to-foster-open-collaboration-in-search-and-analytics) and learn more about joining the foundation [here](https://foundation.opensearch.org/). + +For more information, see [opensearch.org](https://opensearch.org/). + +## Project Resources + +* [Project Website](https://opensearch.org/) +* [OpenSearch Software Foundation](https://foundation.opensearch.org/) +* [Downloads](https://opensearch.org/downloads.html) +* [Documentation](https://opensearch.org/docs/latest/) +* Need help? Try [Forums](https://forum.opensearch.org/) +* Talk to other developers? [Slack](https://opensearch.org/slack.html) +* [Communications](https://github.com/opensearch-project/community/blob/main/COMMUNICATIONS.md) +* [Project Principles](https://opensearch.org/about.html#principles-for-development) +* [Contributing to OpenSearch](CONTRIBUTING.md) +* [Proposing Features](FEATURES.md) +* [Onboarding Guide](ONBOARDING.md) +* [Maintainer Responsibilities](RESPONSIBILITIES.md) +* [Release Management](RELEASING.md) +* [Organization Admins](ADMINS.md) +* [Repo Maintainers](MAINTAINERS.md) +* [Issue Triage](TRIAGING.md) +* [Security](SECURITY.md) + +## Project Style Guidelines + +The [OpenSearch Project style guidelines](https://github.com/opensearch-project/documentation-website/blob/main/STYLE_GUIDE.md) and [OpenSearch terms](https://github.com/opensearch-project/documentation-website/blob/main/TERMS.md) documents provide style standards and terminology to be observed when creating OpenSearch Project content. + +## Code of Conduct + +This project has adopted the [Amazon Open Source Code of Conduct](CODE_OF_CONDUCT.md). For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq), or contact [conduct@opensearch.foundation](mailto:conduct@opensearch.foundation) with any additional questions or comments. + +## License + +This project is licensed under the [Apache v2.0 License](LICENSE.txt). + +## Copyright + +Copyright OpenSearch Contributors. See [NOTICE](NOTICE.txt) for details. \ No newline at end of file diff --git a/RESPONSIBILITIES.md b/RESPONSIBILITIES.md new file mode 100644 index 0000000..6c2e657 --- /dev/null +++ b/RESPONSIBILITIES.md @@ -0,0 +1,167 @@ +- [Overview](#overview) +- [Current Maintainers](#current-maintainers) +- [Maintainer Responsibilities](#maintainer-responsibilities) + - [Uphold Code of Conduct](#uphold-code-of-conduct) + - [Prioritize Security](#prioritize-security) + - [Review Pull Requests](#review-pull-requests) + - [Merging a Pull Request](#merging-a-pull-request) + - [Triage Open Issues](#triage-open-issues) + - [Automatically Label Issues](#automatically-label-issues) + - [Be Responsive](#be-responsive) + - [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo) + - [Keep Dependencies up to Date](#keep-dependencies-up-to-date) + - [Manage Roadmap](#manage-roadmap) + - [Add Continuous Integration Checks](#add-continuous-integration-checks) + - [Use SemVer](#use-semver) + - [Release Frequently](#release-frequently) + - [Promote Other Maintainers](#promote-other-maintainers) + - [Describe the Repo](#describe-the-repo) +- [Becoming a Maintainer](#becoming-a-maintainer) + - [Nomination](#nomination) + - [Interest](#interest) + - [Addition](#addition) +- [Removing a Maintainer](#removing-a-maintainer) + - [Moving On](#moving-on) + - [Inactivity](#inactivity) + - [Negative Impact on the Project](#negative-impact-on-the-project) + +## Overview + +This document explains who maintainers are, what they do in various repos of opensearch-project, and how they should be doing it. If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). + +## Current Maintainers + +Each repo contains a [MAINTAINERS.md](MAINTAINERS.md) file that lists current maintainers, and points to this document. + +## Maintainer Responsibilities + +Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows. + +### Uphold Code of Conduct + +Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md). + +### Prioritize Security + +Security is your number one priority. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs. + +Note that this repository is monitored and OpenSearch Security Team, see [Reporting a Vulnerability](SECURITY.md) for details. + +### Review Pull Requests + +It's our responsibility to ensure the content and code in pull requests are correct and of high quality before they are merged. Here are some best practices: + +- Leverage the issue triaging process to review pull requests and assign them to maintainers for review. +- In cases of uncertainty on how to proceed, search for related issues and reference the pull request to find additional collaborators. +- When providing feedback on pull requests, make sure your feedback is actionable to guide the pull request towards a conclusion. +- If a pull request is valuable but isn't gaining traction, consider reaching out to fulfill the necessary requirements. This way, the pull request can be merged, even if the work is done by several individuals. +- Lastly, strive for progress, not perfection. + +### Merging a Pull Request + +It is important that commit messages are helpful in understanding the reasons for a given commit and maintain good commit hygiene by only keeping the relevant information. + +Most repositories in [opensearch-project](https://github.com/opensearch-project) are configured to require commits to be squashed into a single commit when merging pull requests. If the pull request contains multiple commits then messages from all commits will be appended into a single message, which usually requires editing to produce a high quality commit message. When merging pull requests, edit commit messages by following these steps as much as possible: + +- The commit subject should be concise (ideally within 50 characters) and clearly convey what is being merged. +- The commit body should include the details (if any, and possibly within 72 characters) about the commit, typically inline with the PR description. +- The commit body should include the 'Signed-off-by:*' for all committers involved in the change and thereby indicating that all code contributors agree to the [DCO](https://github.com/opensearch-project/.github/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). +- There need to be a matching 'Signed-Off-By:' line for the `This commit will be authored by *` email address otherwise backport DCO checks will fail. + +### Triage Open Issues + +Manage labels, review issues regularly, and triage by labelling them. + +All repositories in this organization have a standard set of labels, including `bug`, `documentation`, `duplicate`, `enhancement`, `good first issue`, `help wanted`, `blocker`, `invalid`, `question`, `wontfix`, and `untriaged`, along with release labels, such as `v1.0.0`, `v1.1.0`, `v2.0.0`, `patch`, and `backport`. + +Use labels to target an issue or a PR for a given release, add `help wanted` to good issues for new community members, and `blocker` for issues that scare you or need immediate attention. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project. + +See [TRIAGING](TRIAGING.md) for more information on how to attend triage meetings. + +#### Automatically Label Issues + +There are many tools available in GitHub for controlling labels on issues and pull requests. Use standard issue templates in the [./.github/ISSUE_TEMPLATE](./.github/ISSUE_TEMPLATE) directory to apply appropriate labels such as `bug` and `untriaged`. Repositories can choose to use GitHub actions such as [add-untriaged.yml](./.github/workflows/add-untriaged.yml) to apply labels automatically. + +### Be Responsive + +Respond to enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in. + +### Maintain Overall Health of the Repo + +Keep the `main` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. + +#### Keep Dependencies up to Date + +Maintaining up-to-date dependencies on third party projects reduces the risk of security vulnerabilities. The Open Source Security Foundation (OpenSSF) [recommends](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool) either [dependabot](https://docs.github.com/en/code-security/dependabot) or [renovatebot](https://docs.renovatebot.com/). Both of these applications generate Pull Requests for dependency version updates. + - Renovate is integrated as part of the Remediate app in [Mend for Github](https://github.com/apps/mend-for-github-com), which is enabled on all opensearch-project repositories. It can be enabled in the `.whitesource` configuration file as described in the [Mend Remediate and Renovate](https://docs.mend.io/bundle/integrations/page/mend_remediate_and_renovate.html#Integration-with-Mend-Renovate) documentation. The [Merge Confidence](https://docs.renovatebot.com/merge-confidence/) feature can be configured to provide maintainers more information on the age, adoption rate, and percent test passing rate of other repositories. Mend maintains a "Dependency Dashboard" Issue in the repository with centralized information on pending version update PRs. + - Dependabot is integrated with GitHub and can be enabled by adding a [`dependabot.yml`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates) file to the repo. Dependabot does not have any centralized management dashboard, so maintainers may use tags or other PR filters to track pending updates. + +### Manage Roadmap + +Ensure the repo highlights features that should be elevated to the project roadmap. Be clear about the feature’s status, priority, target version, and whether or not it should be elevated to the roadmap. Any feature that you want highlighted on the OpenSearch Roadmap should be tagged with "roadmap". The OpenSearch [project-meta maintainers](https://github.com/opensearch-project/project-meta/blob/main/MAINTAINERS.md) will highlight features tagged "roadmap" on the project wide [OpenSearch Roadmap](https://github.com/orgs/opensearch-project/projects/1). + +### Add Continuous Integration Checks + +Add integration checks that validate pull requests and pushes to ease the burden on Pull Request reviewers. + +### Use SemVer + +Use and enforce [semantic versioning](https://semver.org/) and do not let breaking changes be made outside of major releases. + +### Release Frequently + +Make frequent project releases to the community. + +### Promote Other Maintainers + +Assist, add, and remove [MAINTAINERS](MAINTAINERS.md). Exercise good judgement, and propose high quality contributors to become co-maintainers. See [Becoming a Maintainer](#becoming-a-maintainer) for more information. + +### Describe the Repo + +Make sure the repo has a well-written, accurate, and complete description. See [opensearch-project/.github#38](https://github.com/opensearch-project/.github/issues/38) for some helpful tips to describe your repo. + +## Becoming a Maintainer + +You can become a maintainer by actively [contributing](CONTRIBUTING.md) to any project, and being nominated by an existing maintainer. + +### Nomination + +Any current maintainer starts a private e-mail thread (until we have a better mechanism, e-mail addresses can usually be found via MAINTAINERS.md + DCO) with all other maintainers on that repository to discuss nomination using the template below. In order to be approved, at least three positive (+1) maintainer votes are necessary, and no vetoes (-1). In rare cases when there are fewer than three maintainers, the positive (+1) votes from all maintainers are required. Any disagreements can be escalated to the [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md). + +The nomination should clearly identify the person with their real name and a link to their GitHub profile, and the rationale for the nomination, with concrete example contributions. + +### Interest + +Upon receiving at least three positive (+1) maintainer votes, and no vetoes (-1), from existing maintainers after a one week period, the nominating maintainer asks the nominee whether they might be interested in becoming a maintainer on the repository via private e-mail message. + +> This is great work! Based on your valuable contribution and ongoing engagement with the project, the current maintainers invite you to become a co-maintainer for this project. Please respond and let us know if you accept the invitation to become maintainer. + +Individuals accept the nomination by replying, or commenting, for example _"Thank you! I would love to."_ + +### Addition + +Upon receiving three positive (+1) maintainer votes, and no vetoes (-1), from other maintainers, and after having privately confirmed interest with the nominee, the maintainer opens a pull request adding the proposed co-maintainer to MAINTAINERS.md. The pull request is approved and merged. + +> _Content from the above nomination._ +> +> The maintainers have voted and agreed to this nomination. + +The [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md) adjusts the new maintainer’s permissions accordingly, and merges the pull request. + +## Removing a Maintainer + +Removing a maintainer is a disruptive action that the community of maintainers should not undertake lightly. There are several reasons a maintainer will be removed from the project, such as violating the [code of conduct](https://github.com/opensearch-project/.github/blob/main/CODE_OF_CONDUCT.md), or taking other actions that negatively impact the project. + +### Moving On + +There are plenty of reasons that might cause someone to want to take a step back or even a hiatus from a project. Existing maintainers can choose to leave the project at any time, with or without reason, by making a pull request to move themselves to the "Emeritus" section of MAINTAINERS.md, and asking an [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md) to remove their permissions. + +### Inactivity + +Maintainer status never expires. If a maintainer becomes inactive for a time (usually several months), or a maintainer can confirm that they are no longer involved with the project for any reason, the [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md) may make a pull request to move them to the "Emeritus" section of the MAINTAINERS.md, remove them from CODEOWNERS, and upon merging the pull request, revoke the maintainer level access. Any past maintainer can be reinstated via another pull request, and have their permissions restored by the [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md) at any time upon request. + +If the repo is left without any maintainers, either by maintainer inactivity or moving on, the repo is considered unmaintained. The [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md) will seek out new maintainers and note the maintenance status in the repo README file. + +### Negative Impact on the Project + +Actions that negatively impact the project will be handled by the [members of the admin team](https://github.com/opensearch-project/.github/blob/main/ADMINS.md), in coordination with other maintainers, in balance with the urgency of the issue. Examples would be [Code of Conduct](CODE_OF_CONDUCT.md) violations, deliberate harmful or malicious actions, and security risks. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..e738a85 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,91 @@ +# Security Issue Response Process + +## Introduction + +Security issues happen as part of the normal lifecycle of software development of OpenSearch. This document describes the process for reporting these issues, responding to these issues, and ensuring we treat them not only with the appropriate priority but also with respect for the discoverers, software providers and their users, and the OpenSearch community in general. + +If you discover a potential security issue in this project we ask that you notify the OpenSearch Security Team via email to security@opensearch.org. Please do **not** create a public GitHub issue. + +*Giving credit where credit is due, this policy is heavily influenced by the [Xen Project’s security response process](https://xenproject.org/developers/security-policy/), that was put to the test during the [embargo period for XSA-108 back in 2014](https://xenproject.org/2014/10/22/xen-project-security-policy-improvements-get-involved/) and improved its clarity around managing the pre-disclosure list and the deployment of fixes during embargo. We are standing on the shoulders of these battle-tested giants.* + +## Security Response Team (SRT) + +The OpenSearch Security Response Team (SRT) is comprised of a subset of the project’s maintainers responsible for looking after the project’s security, including the security issue response process outlined below. New SRT members are nominated by current SRT members. + +SRT will address reported issues on a best effort basis, prioritizing them based on several factors, including severity. + +### Current Members + +| Security Response Team | GitHub Alias | Affiliation | +| ------------------------ | ----------------------------------------------------------- | ----------- | +| Kunal Khatua | [kkhatua](https://github.com/kkhatua) | Amazon | +| Daniel (dB.) Doubrovkine | [dblock](https://github.com/dblock) | Amazon | +| Varun Lodaya | [varun-lodaya](https://github.com/varun-lodaya) | Amazon | +| Prabhat Chathurvedi | [prabhat-chaturvedi](https://github.com/prabhat-chaturvedi) | Amazon | +| Craig Perkins | [cwperks](https://github.com/cwperks) | Amazon | +| Nils Bandener | [nibix](https://github.com/nibix) | Eliatra | +| Andrew Redko | [reta](https://github.com/reta) | Aiven | +| Andrey Pleskach | [willyborankin](https://github.com/willyborankin) | Aiven | +| Ryan Liang | [RyanL1997](https://github.com/RyanL1997) | Amazon | + +## Process + +Anyone finding an issue that is already publicly disclosed (for example, a CVE in one of the project’s dependencies) should feel free to create an issue and discuss openly on GitHub. The process below is only intended for issues that have not been publicly disclosed yet. + +1. We request that instead of opening a GitHub issue, it is reported via email at security@opensearch.org. Please include a description of the issue, and any other information that could help in the reproduction and creation of a fix (version numbers, configuration values, reproduction steps...) +2. The OpenSearch Security Team will negotiate the conditions for an embargo period and a disclosure timeline with the discoverer (see [Embargo Schedule](#embargo-schedule)). +3. After the vulnerability is confirmed, if no CVE number is already reserved, the OpenSearch Security Team will reserve one, and communicate it to the discoverer and all parties in the pre-disclosure list (see [Pre-disclosure list](#pre-disclosure-list)). +4. As soon as our advisory is available, we will send it, including patches, to members of the pre-disclosure list. In the event that we do not have a patch available 2 working weeks before the disclosure date, we aim to send an advisory that reflects the current state of knowledge to the pre-disclosure list. An updated advisory will be published as soon as available. At this stage, the advisory will be clearly marked with the embargo date. +5. On the day the embargo is lifted, we will publish the advisory and release the new versions containing the fix. +6. If new information and/or better fixes become available, new advisory versions will be released. + +During an embargo period, the OpenSearch Security Team may be required to make potentially controversial decisions in private, since they cannot confer with the community without breaking the embargo. The team will attempt to make such decisions following the guidance of this document and, where necessary, their own best judgement. Following the embargo period, on a best effort basis, the Security Team will disclose any such decisions, including the reasoning behind them, in the interests of transparency and to help provide guidance should a similar decision be required in the future. + +## Embargo Schedule + +Embargo periods will be negotiated on a case-by-case basis depending on the severity of the issue and availability of the fix, where a general starting point is to release an advisory to the pre-disclosure list within 2 weeks of the initial notification, and publicly releasing the advisory within 4 weeks of the advisory pre-release. + +When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honor such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honor the date specified by the discoverer. +Naturally, if a vulnerability is being exploited in the wild, we will make immediately public release of the patch(es.) + +## Pre-disclosure List + +We maintain a pre-disclosure list of contributors, vendors and operators of OpenSearch for two main reasons: + +1. To apply the fixes to large user populations requiring a significant amount of work post-disclosure +2. To privately collaborate with those who can help write and test the fixes so we can release them as soon as possible and with high confidence in their quality + +If there is an embargo, the pre-disclosure list will receive copies of the advisory and patches, with a clearly marked embargo date, as soon as they are available. The pre-disclosure list will also receive copies of public advisories when they are first issued or updated. + +We expect list members to maintain the confidentiality of the vulnerability up to the embargo date. Specifically, prior to the embargo date, pre-disclosure list members should not make available, even to their own customers and partners: + +* The OpenSearch advisory +* Their own advisory +* The impact, scope, set of vulnerable systems or the nature of the vulnerability +* Revision control commits which are a fix for the problem +* Patched software (even in binary form) + +Without prior consultation with the OpenSearch Security Team, list members may make available to their users only: + +* The existence of an issue +* The assigned OpenSearch advisory number +* The planned disclosure date + +List members may, if (and only if) the OpenSearch Security Team grants permission, deploy fixed versions during the embargo. Permission for deployment, and any restrictions, will be stated in the embargoed advisory text. Where the list member is a service provider who intends to take disruptive action such as rebooting as part of deploying a fix: the list member’s communications to its users about the service disruption may mention that the disruption is to correct a security issue, and relate it to the public information about the issue (as listed above). This applies whether the deployment occurs during the embargo (with permission–see above) or is planned for after the end of the embargo. + +Pre-disclosure list members are allowed to share fixes to embargoed issues, analysis, etc., with the OpenSearch Security Team and security teams of other list members. Technical measures must be taken to prevent non-list-member organizations, or unauthorized staff in list-member organizations, from obtaining the embargoed materials. + +## Pre-disclosure list application process + +Organizations who meet the criteria above (i.e. significant work needed post-disclosure to remediate the issue and/or ability to help create or test the potential fixes) should contact the OpenSearch Security Team via email at security@opensearch.org if they wish to be added to the pre-disclosure list. In the email, you must include: + +* The name of your organization +* How you’re using OpenSearch +* A description of why you fit the criteria (number of users, amount of work needed to remediate, ability to collaborate on fixes...) +* Information about your handling of security problems + * Your invitation to members of the public, who discover security problems with your products/services, to report them in confidence to you + * Specifically, the contact information (email addresses or other contact instructions) which such a member of the public should use +* A statement to the effect that you have read this policy and agree to abide by the terms for inclusion in the list, specifically the requirements to regarding confidentiality during an embargo period +* The email(s) you wish added to the pre-disclosure list + +The OpenSearch Security Team will review your application and get back to you with their decision. \ No newline at end of file diff --git a/TRIAGING.md b/TRIAGING.md new file mode 100644 index 0000000..572f22a --- /dev/null +++ b/TRIAGING.md @@ -0,0 +1,77 @@ +## Issue Triage + +When a new issue is opened in a repo in the opensearch-project GitHub org it is automatically labeled as `untriaged`. The maintainers of many active OpenSearch Project repos facilitate [weekly triage meetings](https://www.meetup.com/opensearch/events/) that are open to all, and attendance is encouraged for anyone who hopes to contribute, discuss a new or existing issue, or learn more about the project. Some examples include [core](https://github.com/opensearch-project/OpenSearch/blob/main/TRIAGING.md) and [security triage](https://github.com/opensearch-project/security/blob/main/TRIAGING.md). In addition, a "catch all" weekly triage meeting is held to quickly review untriaged issues in less active repos and ensure that no new issue is left unattended. + +### What is the purpose of triage meetings? + +The purpose of the triage meetings is to ensure every issue created in the opensearch-project GitHub org receives a response, and no security-related issue remains unattended. Many issues receive immediate engagement and do not need to be triaged. Triage meetings ensure that every issue is filed in the most appropriate repo and contains enough information to be actionable. Triage meetings do not seek to resolve or close all issues, as follow-up discussion and eventual resolution will happen on the issue itself. + +### Which triage meeting should I attend? + +You should attend the meeting for the repo where your issue was opened, or the "catch all" triage if your issue has not seen much traction for an extended period of time. + +### Do I need to attend for my issue to be addressed/triaged? + +Attendance is always welcome, but requesters are not required to attend triage meetings in order for their issue to be addressed. + +### What happens if my issue does not get covered this time? + +During each meeting we seek to address all new issues. However, should we run out of time before your issue is discussed, you are always welcome to attend the next meeting or to follow up on the issue post itself. + +### How do I join triage? + +Meetings are hosted regularly and can be joined via the links posted on the [OpenSearch Meetup Group](https://www.meetup.com/opensearch/events/) list of events. The events are typically titled `Development Backlog & Triage Meeting`. + +After joining the virtual meeting, you can enable your video/voice to join the discussion. If you do not have a webcam or microphone available, you can still join in via the text chat. + +If you have an issue you'd like to bring forth please consider getting a link to the issue so it can be presented to everyone in the meeting. + +### Is there an agenda for each week? + +Meetings are typically 60 minutes and structured as follows: + +1. Initial Gathering: As we gather, feel free to turn on video and engage in informal and open-to-all conversation. After a bit a volunteer will share their screen and proceed with the agenda. +2. Announcements: If there are any announcements to be made they will happen at the start of the meeting. +3. Review of New Issues: The meetings always start with reviewing all untriaged issues. For example, the "catch all" meeting reviews [untriaged issues](https://github.com/search?q=label%3Auntriaged+is%3Aopen++org%3Aopensearch-project&type=issues&ref=advsearch&s=created&o=asc), oldest first. +4. Untriaged Items: Review any issues that might have had the `untriaged` label removed, but require additional triage discussion. +5. Pull Request Discussion: Review the status of outstanding pull requests if there's time. +6. Open Discussion: Allow for members of the meeting to surface any topics without issues filed or pull request created. + +There is no specific ordering within each category. + +### How does an issue get "triaged"? + +1. Attendees of triage meetings copy-paste links to their GitHub accounts into chat. +2. A volunteer that runs a triage meeting prepares a label such as `[[Triage](https://github.com/opensearch-project/.github/blob/main/TRIAGING.md) [1](...) [2](...)]` where the `[1](...)`, `[2](...)`, ... tags are links to GitHub accounts of the attendees. +3. The `untriaged` label is removed from every issue being reviewed. +4. The issue gets a comment using the above-mentioned label and any other comments as needed. + +### Do I need to have already contributed to the project to attend a triage meeting? + +No, all are welcome and encouraged to attend. Attending the Backlog & Triage meetings is a great way for a new contributor to learn about the project as well as explore different avenues of contribution. + +### What if I have an issue that is almost a duplicate, should I open a new one to be triaged? + +You can always open an issue including one that you think may be a duplicate. However, in cases where you believe there is an important distinction to be made between an existing issue and your newly created one, you are encouraged to attend the triage meeting to explain. + +### What if I have follow-up questions on an issue? + +If you have an existing issue you would like to discuss, you can always comment on the issue itself. Alternatively, you are welcome to come to the triage meeting to discuss. + +### Is this where I should bring up potential security vulnerabilities? + +No. Due to the sensitive nature of security vulnerabilities, please report all potential vulnerabilities directly by following the steps outlined in [SECURITY.md](https://github.com/opensearch-project/.github/blob/main/SECURITY.md). Do not create security issues on GitHub. + +### What does an issue comment that says `[Catch All Triage - [1](...), [2](...)]` mean? + +This means the issue was flagged as untriaged for more than 2 weeks during "catch all" triage. The GitHub profiles of the community members attending are linked as `[1]`, `[2]`, etc. The issue was quickly reviewed for validity and urgency, the "untriaged" label was removed, and this comment was added. + +If you are a community member contributing to a repo that received this comment, please step up to establish a regular triage and avoid seeing the issue in the "catch all" one. + +### Who should I contact if I have further questions? + +We recommend using the [forum](https://forum.opensearch.org/) or [public Slack](https://opensearch.org/slack.html). + +### Code of Conduct + +All hosts and participants involved in Triage are expected to follow the [OpenSearch Project Code of Conduct](CODE_OF_CONDUCT.md). \ No newline at end of file diff --git a/profile/README.md b/profile/README.md new file mode 100644 index 0000000..7836a56 --- /dev/null +++ b/profile/README.md @@ -0,0 +1,34 @@ +![OpenSearch logo and name on top of a dark blue background with a slight honeycomb pattern](https://raw.githubusercontent.com/opensearch-project/.github/main/profile/banner.jpg) + +OpenSearch Project is a community-driven, Apache 2.0-licensed open source search and analytics suite that makes it easy to ingest, search, visualize, and analyze data. Developers build with OpenSearch for use cases such as application search, log analytics, data observability, data ingestion, and more. + +OpenSearch is supported by [The OpenSearch Software Foundation](https://foundation.opensearch.org/), a project of [The Linux Foundation](https://www.linuxfoundation.org/). You can read the launch announcement [here](https://www.linuxfoundation.org/press/linux-foundation-announces-opensearch-software-foundation-to-foster-open-collaboration-in-search-and-analytics) and learn more about joining the foundation [here](https://foundation.opensearch.org/). + +## Using + +Download and try [OpenSearch](https://opensearch.org/docs/latest/opensearch/install/docker/) 🔎 or use the demo [OpenSearch Dashboards](https://playground.opensearch.org/auth/anonymous) 🖥. Integrate your application using one of many [client libraries](https://opensearch.org/docs/latest/clients/) 📚. + +## Contributing ✍️ + +We are built 🧱 by the community for the community. There are many ways to contribute. + +- 📖 Read our [step-by-step onboarding guide](../ONBOARDING.md) to help you get oriented and prepared to contribute. +- 👀 Check out a project's [contributing guide](../CONTRIBUTING.md) to learn how to contribute code. +- ✍️ Write [a blog post](https://github.com/opensearch-project/project-website). +- 📘 Help author [documentation](https://github.com/opensearch-project/documentation-website). + +## Get Involved in our Community! + +There are several places where our community meets. Make sure to check them out! + +- 📝 [Forum](https://forum.opensearch.org/) +- 💬 [Slack](https://opensearch.org/slack.html) +- 🗣️ [User Groups & Triage meetings](https://www.meetup.com/pro/opensearchproject/) +- ▶️ [YouTube](https://www.youtube.com/c/OpenSearchProject) +- 🧑‍💼 [LinkedIn](https://www.linkedin.com/company/opensearch-project/) +- 🐘 [Mastodon](https://fosstodon.org/@OpenSearchProject) +- 🐤 [Twitter](https://twitter.com/OpenSearchProj) + +---- + +This project has adopted the [OpenSearch Software Foundation Code of Conduct](https://github.com/opensearch-project/.github/blob/main/CODE_OF_CONDUCT.md). Copyright OpenSearch Contributors. See [NOTICE](https://github.com/opensearch-project/.github/blob/main/NOTICE.txt) for details. OpenSearch is a registered trademark of The Linux Foundation. diff --git a/profile/banner.jpg b/profile/banner.jpg new file mode 100644 index 0000000..bac19f9 Binary files /dev/null and b/profile/banner.jpg differ