You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@solr.apache.org by ja...@apache.org on 2023/01/16 22:59:55 UTC
[solr] branch branch_9x updated: SOLR-16544: Adding documentation for how to contribute to Solr (#1177)
This is an automated email from the ASF dual-hosted git repository.
janhoy pushed a commit to branch branch_9x
in repository https://gitbox.apache.org/repos/asf/solr.git
The following commit(s) were added to refs/heads/branch_9x by this push:
new ab9bedf547f SOLR-16544: Adding documentation for how to contribute to Solr (#1177)
ab9bedf547f is described below
commit ab9bedf547f401cc136938d0f8af56a0b009c085
Author: Justin Sweeney <ju...@fullstory.com>
AuthorDate: Mon Jan 16 23:42:07 2023 +0100
SOLR-16544: Adding documentation for how to contribute to Solr (#1177)
Co-authored-by: Jan Høydahl <ja...@users.noreply.github.com>
---
CONTRIBUTING.md | 55 +++++++++++++++
dev-docs/FAQ.adoc | 56 +++++++++------
help/IDEs.txt => dev-docs/IDEs.adoc | 12 ++--
dev-docs/README.adoc | 81 ----------------------
dev-docs/how-to-contribute.adoc | 26 +++++++
dev-docs/jvms.adoc | 14 ++++
dev-docs/running-in-docker.adoc | 28 ++++++++
dev-docs/solr-source-code.adoc | 48 +++++++++++++
gradle/help.gradle | 2 -
help/jvms.txt | 18 -----
solr/CHANGES.txt | 2 +
solr/solr-ref-guide/antora.template.yml | 1 +
.../how-to-contribute/how-to-contribute-nav.adoc | 18 +++++
.../how-to-contribute/pages/how-to-contribute.adoc | 25 +++++++
14 files changed, 259 insertions(+), 127 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000000..e6562df0e4a
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,55 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You 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.
+ -->
+
+# Contribute To Solr
+
+Thank you for your interest in contributing to the Apache Solr project. Solr continues to improve via the many contributions of developers around the world and new contributions are welcomed and encouraged.
+
+Your suggestions and comments can be made directly through the [Apache Solr JIRA](https://issues.apache.org/jira/projects/SOLR/issues).
+
+There are many ways to participate in and contribute to Solr, such as: code implementation, test implementation, documentation improvements.
+
+If you have any questions along the way, you can reach out to the community using the resources provided [here](https://solr.apache.org/community.html#mailing-lists-chat).
+
+## How To Contribute
+
+Information on how to contribute can be found in the [How To Contribute developer documentation](dev-docs/how-to-contribute.adoc).
+
+## Contributing Documentation
+
+One very helpful area for contribution to Solr is via documentation improvements and additions to help make Solr easier to use for others. You can read more about how to modify and update Solr documentation in the [Solr Reference Guide README](solr/solr-ref-guide/README.adoc).
+
+Additionally, you can contribute to improve the [Solr developer documentation](dev-docs) to make the contribution process easier for future developers.
+
+Finally, changes to the Solr website (solr.apache.org) can be made in the [solr-site repository](https://github.com/apache/solr-site).
+
+## Working With Solr Source Code
+
+Information on how to work with Solr source code and the build system can be found in the [Solr Source Code developer documentation](dev-docs/solr-source-code.adoc).
+
+## IDE Support
+
+Information on IDE support can be found in the [IDEs developer documentation](dev-docs/IDEs.adoc).
+
+## JVM Support
+
+Information on JVMs can be found in the [JVMs developer documentation](dev-docs/jvms.adoc).
+
+## FAQs
+
+Frequently asked questions can be found in the [FAQ developer documentation](dev-docs/FAQ.adoc)
+
diff --git a/dev-docs/FAQ.adoc b/dev-docs/FAQ.adoc
index c4f2b002592..267b137bad1 100644
--- a/dev-docs/FAQ.adoc
+++ b/dev-docs/FAQ.adoc
@@ -19,35 +19,51 @@ branch to avoid extra mailing list traffic etc.
Periodically review https://github.com/apache/solr/branches/all to see if you have
created a branch that can be deleted.
-=== Running Solr in Docker
+=== How do I run Solr in Docker?
-You can run Solr in Docker via the [official image](https://hub.docker.com/_/solr).
+You can review instructions for running Solr in Docker in the xref:running-in-docker.adoc[Running in Docker developer doc].
-To run Solr in a container and expose the Solr port, run:
+=== Whats the fastest build lifecycle for frontend work on Solr Admin?
-`docker run -p 8983:8983 solr`
+Run `gradle dev`, and then `cd ./packaging/build/dev/`. Fire up your cluster
+via `bin/solr start -e cloud -noprompt` and then as you make changes to assets in `/solr/webapp/web`,
+run `gradle dev` to redeploy the web assets. Do a hard refresh in your browser
+to pick up your changes.
-In order to start Solr in cloud mode, run the following.
+=== How do we ensure coding standards and quality?
-`docker run -p 8983:8983 solr solr-fg -c`
+We use a number of tools for ensuring that Solr's codebase follows our community standards.
+The most important tool is the very rich testing infrastructure that Solr enjoys.
+We strive for testing of every aspect of Solr.
+If you find a bug, write a test demonstrating it, so we can ensure that once the bug is squashed, it stays squashed.
-For documentation on using the official docker builds, please refer to the [DockerHub page](https://hub.docker.com/_/solr).
-Up to date documentation for running locally built images of this branch can be found in the [local reference guide](solr/solr-ref-guide/src/running-solr-in-docker.adoc).
+Beyond testing, we also have some tools for ensuring coding standards are followed.
+https://github.com/diffplug/spotless[Spotless] is used to format the Java source code so that everyone uses the same formatting patterns.
+Run Spotless via:
-There is also a gradle task for building custom Solr images from your local checkout.
-These local images are built identically to the official image except for retrieving the Solr artifacts locally instead of from the official release.
-This can be useful for testing out local changes as well as creating custom images for yourself or your organization.
-The task will output the image name to use at the end of the build.
+`./gradlew tidy`
-`./gradlew docker`
+Learn more via `./gradlew :helpFormatting`.
-For more info on building an image, run:
+The Eclipse IDE's linting tool ECJ is applied as part of the `check` task.
-`./gradlew helpDocker`
+https://errorprone.info/[Error Prone] goes beyond static type checking and recommends fixes for common bug patterns.
+Error Prone is run during the CI build on Jenkins, however to run it locally (and skip the tests) do:
-=== Whats the fastest build lifecycle for frontend work on Solr Admin?
+`./gradlew check -Pvalidation.errorprone=true -x test`
-Run `gradle dev`, and then `cd ./packaging/build/dev/`. Fire up your cluster
-via `bin/solr start -e cloud -noprompt` and then as you make changes to assets in `/solr/webapp/web`,
-run `gradle dev` to redeploy the web assets. Do a hard refresh in your browser
-to pick up your changes.
+In the same space as Errorprone is https://lift.sonatype.com/[Sonatype Lift], an automated code reviewer that is run when you push your PR to Github.
+As with human reviewers, it's a good practice to respond to each comment to reflect on the recommendation.
+Of course, automated code analysis will turn up false-positives.
+Tip: There is no point in responding to Lift with the ignore command because we don't gate PRs on Lift.
+
+There are Java classes and methods that Solr doesn't allow.
+This exclusion is enforced by the https://github.com/policeman-tools/forbidden-apis[Forbidden APIs] tool and is applied as part of the `check` task.
+Learn more about using Forbidden APIs via `./gradlew :helpForbiddenApis`.
+
+To run a check for dependencies of Solr that have security vulnerabilities using the https://plugins.gradle.org/plugin/org.owasp.dependencycheck[OWASP] Gradle plugin.
+Run via:
+
+`./gradlew owasp`
+
+There are a number of other tasks that get run to validate the source code, and you can find them in the ./gradle/validation source tree.
diff --git a/help/IDEs.txt b/dev-docs/IDEs.adoc
similarity index 79%
rename from help/IDEs.txt
rename to dev-docs/IDEs.adoc
index 3ad5b85ec49..f6c03ce1bf8 100644
--- a/help/IDEs.txt
+++ b/dev-docs/IDEs.adoc
@@ -1,15 +1,15 @@
-IntelliJ IDEA
-=============
+# IDEs
+
+## IntelliJ IDEA
Importing the project as a gradle project should just run out of the box.
-Eclipse
-=======
+## Eclipse
Run the following to set up Eclipse project files:
-./gradlew eclipse
+`./gradlew eclipse`
then import the project into Eclipse with:
@@ -17,4 +17,4 @@ File -> Import... -> Existing Project into Workspace
Please note that Eclipse does not distinguish between sub-projects
and package sets (main/ test) so pretty much all the sources and dependencies
-are available in one large bin.
+are available in one large bin.
\ No newline at end of file
diff --git a/dev-docs/README.adoc b/dev-docs/README.adoc
index 781cd72cd54..bb0d17d75f9 100644
--- a/dev-docs/README.adoc
+++ b/dev-docs/README.adoc
@@ -29,84 +29,3 @@ However, the Ref Guide hosts it's own documentation on how to write Ref Guide co
There are a number of tools related to doing development on Solr available in the `/dev-tools`
directory.
-
-## Building Solr from Source
-Download the Java 11 JDK (Java Development Kit) or later. We recommend the OpenJDK
-distribution Eclipse Temurin available from https://adoptium.net/.
-You will need the JDK installed, and the $JAVA_HOME/bin (Windows: %JAVA_HOME%\bin)
-folder included on your command path. To test this, issue a "java -version" command
-from your shell (command prompt) and verify that the Java version is 11 or later.
-
-Download the Apache Solr distribution, from https://solr.apache.org/downloads.html.
-Unzip the distribution to a folder of your choice, e.g. C:\solr or ~/solr
-Alternately, you can obtain a copy of the latest Apache Solr source code
-directly from the Git repository:
-
-<https://solr.apache.org/community.html#version-control>
-
-Solr uses [Gradle](https://gradle.org/) as the build
-system. Navigate to the root of your source tree folder and issue the `./gradlew tasks`
-command to see the available options for building, testing, and packaging Solr.
-
-`./gradlew dev` will create a Solr executable suitable for development.
-cd to `./solr/packaging/build/dev` and run the `bin/solr` script
-to start Solr.
-
-NOTE: `gradlew` is the "Gradle Wrapper" and will automatically download and
-start using the correct version of Gradle for Solr.
-
-NOTE: `./gradlew help` will print a list of high-level tasks. There are also a
-number of plain-text files in <source folder root>/help.
-
-The first time you run Gradle, it will create a file "gradle.properties" that
-contains machine-specific settings. Normally you can use this file as-is, but it
-can be modified if necessary.
-
-Note as well that the gradle build does not create or copy binaries throughout the
-source repository so you need to switch to the packaging output folder `./solr/packaging/build`;
-the rest of the instructions below remain identical. The packaging directory
-is rewritten on each build.
-
-If you want to build the documentation, type `./gradlew -p solr documentation`.
-
-`./gradlew check` will assemble Solr and run all validation tasks unit tests.
-
-To build the final Solr artifacts run `./gradlew assemble`.
-
-Lastly, there is developer oriented documentation in `./dev-docs/README.adoc` that
-you may find useful in working with Solr.
-
-
-### Gradle build and IDE support
-
-- *IntelliJ* - IntelliJ idea can import the project out of the box.
- Code formatting conventions should be manually adjusted.
-- *Eclipse* - Not tested.
-- *Netbeans* - Not tested.
-
-
-### Running Solr in Docker
-
-You can run Solr in Docker via the [official image](https://hub.docker.com/_/solr).
-
-To run Solr in a container and expose the Solr port, run:
-
-`docker run -p 8983:8983 solr`
-
-In order to start Solr in cloud mode, run the following.
-
-`docker run -p 8983:8983 solr solr-fg -c`
-
-For documentation on using the official docker builds, please refer to the [DockerHub page](https://hub.docker.com/_/solr).
-Up to date documentation for running locally built images of this branch can be found in the [local reference guide](solr/solr-ref-guide/src/running-solr-in-docker.adoc).
-
-There is also a gradle task for building custom Solr images from your local checkout.
-These local images are built identically to the official image except for retrieving the Solr artifacts locally instead of from the official release.
-This can be useful for testing out local changes as well as creating custom images for yourself or your organization.
-The task will output the image name to use at the end of the build.
-
-`./gradlew docker`
-
-For more info on building an image, run:
-
-`./gradlew helpDocker`
diff --git a/dev-docs/how-to-contribute.adoc b/dev-docs/how-to-contribute.adoc
new file mode 100644
index 00000000000..ef82760399e
--- /dev/null
+++ b/dev-docs/how-to-contribute.adoc
@@ -0,0 +1,26 @@
+# How To Contribute
+
+The Apache Solr Github Repository is located here: https://github.com/apache/solr. Typically all contributions to Solr are developed on a fork of the Solr repository, then opened as PRs against the `main` branch in the solr repository. These PRs are then linked to an open JIRA issue and members of the community will review, comment, approve, and commit changes.
+
+Please keep in mind that the project is community driven, with many members taking their own personal time to help respond to issue and review PRs. Be open to feedback and discussions and maintain a respectful approach. Read our https://solr.apache.org/community.html#code-of-conduct[code of conduct] for more.
+
+## Setup for Contributing
+In order to get setup you will need a fork of the Apache Solr repository and an account in the ASF Jira (usable for all Apache projects).
+
+1. Create a fork of the https://github.com/apache/solr[Solr repository] into your own personal account or a your corporate organization account using the Github instructions provided here: https://docs.github.com/en/get-started/quickstart/fork-a-repo.
+2. If you do not already have one, you will need to create an account in the ASF Jira: https://issues.apache.org/jira/login.jsp which you will use to create new issues. You can request a new account if you do not already have one by contacting the https://solr.apache.org/community.html[Solr users mailing list].
+
+
+## Making a New Contribution
+In order to make a new contribution to Solr you will use the fork you have created above.
+
+1. Create a new Jira issue in the Solr project: https://issues.apache.org/jira/projects/SOLR/issues
+2. Create a new branch in your Solr fork to provide a PR for your contribution on the newly created issue. Make any necessary changes for the given bug/feature in that branch. You can use additional information in these dev-docs to build and test your code as well as ensure it passes code quality checks.
+3. Once you are satisfied with your changes, get your branch ready for a PR by running `./gradlew tidy updateLicenses check -x test`. This will format your source code, update licenses of any dependency version changes and run all pre-commit tests. Commit the changes.
+4. Open a PR of your branch against the `main` branch of the apache/solr repository. When you open a PR on your fork, this should be the default option.
+* The title of your PR should include the Solr Jira issue that you opened, i.e. `SOLR-12345: New feature`.
+* The PR description will automatically populate with a pre-set template that you will need to fill out.
+* The PR will run a gradle pre-commit task that will do some basic checks of your changes. This is run as a Github Action and the results can be viewed from your PR.
+* If you properly named your PR you will see it automatically linked to your Jira issue when you view the issue.
+* If your PR is still a work in progress, you can use the https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests[PR Draft feature] of Github to denote draft status.
+5. At this point, you will need a Solr committer to review your change and help to get it merged upstream. You can use the https://solr.apache.org/community.html[Solr Developers Mailing List] to get attention to your issue.
\ No newline at end of file
diff --git a/dev-docs/jvms.adoc b/dev-docs/jvms.adoc
new file mode 100644
index 00000000000..d5d485daed0
--- /dev/null
+++ b/dev-docs/jvms.adoc
@@ -0,0 +1,14 @@
+# Compiling and testing against different JVMs
+
+By default tests are executed with the same Java Gradle is using internally.
+
+To run tests against a different Java version, define a property called `runtime.java.home` or define an environment variable `RUNTIME_JAVA_HOME` pointing at the JDK installation folder.
+
+If property is being used, it can be a system property (-D...) or a project property (-P...).
+
+*Example:*
+
+`gradlew test -p solr/test-framework --tests TestLogLevelAnnotations -Dtests.verbose=true -Druntime.java.home=/jvms/jdk14`
+
+Note that an alternative JVM can also be made the "default" setting
+by adding it to (project-local) gradle.properties.
\ No newline at end of file
diff --git a/dev-docs/running-in-docker.adoc b/dev-docs/running-in-docker.adoc
new file mode 100644
index 00000000000..e2471bc10c8
--- /dev/null
+++ b/dev-docs/running-in-docker.adoc
@@ -0,0 +1,28 @@
+# Running Solr in Docker
+
+You can run Solr in Docker via the https://hub.docker.com/_/solr[official image].
+
+To run Solr in a container and expose the Solr port, run:
+
+`docker run -p 8983:8983 solr`
+
+In order to start Solr in cloud mode, run the following.
+
+`docker run -p 8983:8983 solr solr-fg -c`
+
+For documentation on using the official docker builds, please refer to the https://hub.docker.com/_/solr[DockerHub page].
+Up to date documentation for running locally built images of this branch can be found in the xref:_running_solr_in_docker[local reference guide].
+
+There is also a gradle task for building custom Solr images from your local checkout.
+These local images are built identically to the official image except for retrieving the Solr artifacts locally instead of from the official release.
+This can be useful for testing out local changes as well as creating custom images for yourself or your organization.
+The task will output the image name to use at the end of the build.
+
+`./gradlew docker`
+
+For more info on building an image, run:
+
+`./gradlew helpDocker`
+
+## Additional Information
+You can find additional information in the https://solr.apache.org/guide/solr/latest/deployment-guide/solr-in-docker.html[Solr Ref Guide Docker Page]
\ No newline at end of file
diff --git a/dev-docs/solr-source-code.adoc b/dev-docs/solr-source-code.adoc
new file mode 100644
index 00000000000..9f9cf79e021
--- /dev/null
+++ b/dev-docs/solr-source-code.adoc
@@ -0,0 +1,48 @@
+# Working With Solr Source Code
+
+## Building Solr from Source
+
+Download the Java 11 JDK (Java Development Kit) or later. We recommend the OpenJDK
+distribution Eclipse Temurin available from https://adoptium.net/.
+You will need the JDK installed, and the $JAVA_HOME/bin (Windows: %JAVA_HOME%\bin)
+folder included on your command path. To test this, issue a "java -version" command
+from your shell (command prompt) and verify that the Java version is 11 or later. See the xref:jvms.adoc[JVM developer doc] for more information on Gradle and JVMs.
+
+Clone the latest Apache Solr source code directly from the Git repository: <https://solr.apache.org/community.html#version-control>.
+Alternatively, you can download the Apache Solr distribution, from https://solr.apache.org/downloads.html and unzip the distribution to a folder of your choice, e.g. C:\solr or ~/solr.
+
+Solr uses https://gradle.org/[Gradle] as the build
+system. Navigate to the root of your source tree folder and issue the `./gradlew tasks`
+command to see the available options for building, testing, and packaging Solr.
+
+`./gradlew dev` will create a Solr executable suitable for development.
+cd to `./solr/packaging/build/dev` and run the `bin/solr` script
+to start Solr.
+
+NOTE: `gradlew` is the "Gradle Wrapper" and will automatically download and
+start using the correct version of Gradle for Solr.
+
+NOTE: `./gradlew help` will print a list of high-level tasks. There are also a
+number of plain-text files in <source folder root>/help.
+
+The first time you run Gradle, it will create a file "gradle.properties" that
+contains machine-specific settings. Normally you can use this file as-is, but it
+can be modified if necessary.
+
+Note as well that the gradle build does not create or copy binaries throughout the
+source repository so you need to switch to the packaging output folder `./solr/packaging/build`;
+the rest of the instructions below remain identical. The packaging directory
+is rewritten on each build.
+
+If you want to build the documentation, type `./gradlew -p solr documentation`.
+
+`./gradlew check` will assemble Solr and run all validation tasks unit tests.
+
+To build the final Solr artifacts run `./gradlew assemble`.
+
+Lastly, there is developer oriented documentation in `./dev-docs/README.adoc` that
+you may find useful in working with Solr.
+
+## Additional Information
+
+You can review the https://github.com/apache/solr/blob/main/CONTRIBUTING.md[contribution guide] for information on how to contribute. There are also additional helpful docs https://github.com/apache/solr/blob/main/help[in the help directory].
\ No newline at end of file
diff --git a/gradle/help.gradle b/gradle/help.gradle
index bf45a3e48ad..b6b64f9a567 100644
--- a/gradle/help.gradle
+++ b/gradle/help.gradle
@@ -23,13 +23,11 @@ configure(rootProject) {
["Ant", "help/ant.txt", "Ant-gradle migration help."],
["Tests", "help/tests.txt", "Tests, filtering, beasting, etc."],
["Formatting", "help/formatting.txt", "Code formatting conventions."],
- ["Jvms", "help/jvms.txt", "Using alternative or EA JVM toolchains."],
["Deps", "help/dependencies.txt", "Declaring, inspecting and excluding dependencies."],
["ForbiddenApis", "help/forbiddenApis.txt", "How to add/apply rules for forbidden APIs."],
["LocalSettings", "help/localSettings.txt", "Local settings, overrides and build performance tweaks."],
["Git", "help/git.txt", "Git assistance and guides."],
["ValidateLogCalls", "help/validateLogCalls.txt", "How to use logging calls efficiently."],
- ["IDEs", "help/IDEs.txt", "IDE support."],
["Publishing", "help/publishing.txt", "Release publishing publishing, signing, etc."],
["Docker", "solr/docker/gradle-help.txt", "Building Solr Docker images."],
]
diff --git a/help/jvms.txt b/help/jvms.txt
deleted file mode 100644
index 3e14a8d5fd5..00000000000
--- a/help/jvms.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Compiling and testing against different JVMs
-============================================
-
-By default tests are executed with the same Java Gradle is using internally.
-
-To run tests against a different Java version, define a property called
-"runtime.java.home" or define an environment variable "RUNTIME_JAVA_HOME"
-pointing at the JDK installation folder.
-
-If property is being used, it can be a system property (-D...) or a project
-property (-P...).
-
-Example:
-
-gradlew test -p solr/test-framework --tests TestLogLevelAnnotations -Dtests.verbose=true -Druntime.java.home=/jvms/jdk14
-
-Note that an alternative JVM can also be made the "default" setting
-by adding it to (project-local) gradle.properties.
diff --git a/solr/CHANGES.txt b/solr/CHANGES.txt
index f90dcb75d4a..e03d61e9310 100644
--- a/solr/CHANGES.txt
+++ b/solr/CHANGES.txt
@@ -194,6 +194,8 @@ Other Changes
* SOLR-13243: Correct the initial capacity of the ZK operations to run in ShardLeaderElectionContextBase#runLeaderProcess (Haythem Khiri)
+* SOLR-16544: Improve documentation on how to contribute to Solr (Justin Sweeney)
+
================== 9.1.1 ==================
Bug Fixes
diff --git a/solr/solr-ref-guide/antora.template.yml b/solr/solr-ref-guide/antora.template.yml
index c600c494aad..8f3d62e5522 100644
--- a/solr/solr-ref-guide/antora.template.yml
+++ b/solr/solr-ref-guide/antora.template.yml
@@ -31,6 +31,7 @@ nav:
- modules/indexing-guide/indexing-nav.adoc
- modules/query-guide/querying-nav.adoc
- modules/upgrade-notes/upgrade-nav.adoc
+- modules/how-to-contribute/how-to-contribute-nav.adoc
# The asciidoc attributes must be the last entry in this file
asciidoc:
diff --git a/solr/solr-ref-guide/modules/how-to-contribute/how-to-contribute-nav.adoc b/solr/solr-ref-guide/modules/how-to-contribute/how-to-contribute-nav.adoc
new file mode 100644
index 00000000000..b74aa8b0d8d
--- /dev/null
+++ b/solr/solr-ref-guide/modules/how-to-contribute/how-to-contribute-nav.adoc
@@ -0,0 +1,18 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you 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.
+
+* xref:how-to-contribute.adoc[]
diff --git a/solr/solr-ref-guide/modules/how-to-contribute/pages/how-to-contribute.adoc b/solr/solr-ref-guide/modules/how-to-contribute/pages/how-to-contribute.adoc
new file mode 100644
index 00000000000..e4779b425bf
--- /dev/null
+++ b/solr/solr-ref-guide/modules/how-to-contribute/pages/how-to-contribute.adoc
@@ -0,0 +1,25 @@
+= How To Contribute
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you 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.
+
+Thank you for your interest in contributing to the Solr OSS Community! Solr continues to improve via the many contributions of developers around the world and new contributions are welcomed and encouraged.
+
+Instructions for how to contribute are located in Github alongside the Solr code here: https://github.com/apache/solr/blob/main/CONTIRBUTING.md.
+
+You can also get in contact with the community for additional assistance using the various avenues here: https://solr.apache.org/community.html.
+
+We look foward to your participation in the community!