add links and fix wording (#257)

CONTRIBUTING.md

@@ -1,109 +1,101 @@
 # Contributing
 
-This document describes how you can build the solution from scratch, submit 
-your code contributions and make releases.
+Thank you for your interest in contributing to our project! This document outlines the steps for building the solution from scratch, submitting code
+contributions, and making releases.
 
-In a nutshell, our development workflow is:
+## Development Workflow
 
-* Create a feature branch
-* Make your changes locally
-* Run checks locally
-* Commit & push your changes
-* Wait for the remote checks to pass
-* Squash & merge
+Our development workflow follows these steps:
+
+1. Create a feature branch
+2. Make your changes locally
+3. Run checks locally
+4. Commit & push your changes
+5. Wait for the remote checks to pass
+6. Squash & merge
 
 ## Building Locally
 
-We provide a powershell script to build the solution:
+To build the solution locally, we provide a PowerShell script:
 
-```
-.\src\BuildForRelease.s1
+```powershell
+.\src\BuildForRelease.ps1
 ```
 
-This script will install all the solution dependencies before the build. Please
-inspect the script if you would like to build only parts of the solution.
+This script will install all necessary dependencies before building. If you prefer to build only parts of the solution, please inspect the script for specific
+commands.
 
-## Locally Packaging for Release
+## Packaging for Release Locally
 
-Once the solution has been built, you can build your own local release bundles
-(compressed as zip archives) with:
+After building the solution, you can create local release bundles (compressed as zip archives) with the following script:
 
-```
+```powershell
 .\src\PackageForRelease.ps1
 ```
 
-Note that these local release bundles are only meant for testing.
-We set up our continuous integration on GitHub to remotely build, package and
-publish the releases in automatic manner.
+Please note that these local release bundles are meant for testing purposes only. Our continuous integration system on GitHub automatically builds, packages,
+and publishes official releases.
 
 ## Local Pre-commit Checks
 
-We run a couple of checks to ensure the quality of the code (*e.g.*, checking
-that the code format is consistent).
+To ensure code quality (e.g., consistent code formatting), we run several checks. GitHub will automatically run these checks on every push, but it’s faster to
+run them locally first during development.
 
-GitHub will run these checks automatically on every push. However, this can take
-some time, so you usually run these checks locally first to speed up the 
-development.
+### Formatting Code
 
-Please format your code before running the checks with the following script:
+Format your code with the following script:
 
-```
+```powershell
 .\src\FormatCode.ps1
 ```
 
-Run the checks:
+### Running Checks
 
-```
+Run the checks with:
+
+```powershell
 .\src\Check.ps1
 ```
 
 ## Submitting Your Code
 
 ### Branching
 
-**If you are part of admin-shell-io GitHub organization:**
-create a branch prefixed with your Github username using dashes to 
-describe the change (*e.g.*, `mristin/Add-a-shiny-new-feature-B`).
+**If you are part of the `Eclipse AASX Package Explorer and Server`GitHub organization:**
+Create a branch prefixed with your GitHub username using dashes to describe the change (e.g., `mristin/Add-a-shiny-new-feature-B`).
 
-**Otherwise:** Since only members of the organization can create branches,
-you need to fork the repository and create your feature branch on the fork (see 
-[GitHub documentation about forking][github-fork]).
+**Otherwise:** If you are not a member of the organization, you need to fork the repository and create your feature branch on the fork. 
+See the [GitHub documentation about forking][github-fork].
 
 [github-fork]: https://docs.github.com/en/github/getting-started-with-github/fork-a-repo
 
 ### Commit and Pull Request
 
-Commit your local changes and push them to the remote. Make sure the commit 
-message complies to https://chris.beams.io/posts/git-commit/ guidelines:
-
-* Separate subject from body with a blank line
-* Limit the subject line to 50 characters
-* Capitalize the subject line
-* Do not end the subject line with a period
-* Use the imperative mood in the subject line
-* Wrap the body at 72 characters
-* Use the body to explain what and why (instead of how)
-
-You can use special hints in the commit messages to disable checks or building
-of a docker image:
-
-* `The workflow build-and-publish-docker-images was intentionally skipped.` 
-  (no docker images will be created)
-
-* `The workflow check-release was intentionally skipped.`
-  (no release check, in particular no build)
-
-* `The workflow check-style was intentionally skipped.`
-  (no checks for code style)
-
-Here is an example commit message:
-
+Commit your local changes and push them to the remote repository. Ensure your commit message adheres to the guidelines outlined at 
+[Chris Beams' Git Commit Guidelines](https://chris.beams.io/posts/git-commit/):
+
+* Separate subject from body with a blank line.
+* Limit the subject line to 50 characters.
+* Capitalize the subject line.
+* Do not end the subject line with a period.
+* Use the imperative mood in the subject line.
+* Wrap the body at 72 characters.
+* Use the body to explain what and why (instead of how).
+
+You can use special hints in the commit messages to disable checks or the building of a Docker image:
+
+* `The workflow build-and-publish-docker-images was intentionally skipped.` (No Docker images will be created)
+* `The workflow check-release was intentionally skipped.` (No release check, particularly no build)
+* `The workflow check-style was intentionally skipped.` (No checks for code style)
+
+#### Example Commit Message
+
 ```
 Add a shiny new feature B
 
-Previously, the solution could not perform A and it was confusing for
+Previously, the solution could not perform A, and it was confusing for
 the users how to use `SomeModule`. This change introduces a
-new feature B which solves A as well as the problem with C.
+new feature B, which solves A as well as the problem with C.
 
 This is important because D now runs much faster and has a clearer 
 structure. Moreover, feature B is particularly practical for use cases 
@@ -115,31 +107,30 @@ in these concrete use cases E and F.
 The workflow build-and-publish-docker-images was intentionally skipped.
 ```
 
-Once all the checks pass, push your commit and create a pull request (see 
-[this GitHub documentation page about pull requests][pull-request]).
+Once all checks pass, push your commit and create a pull request. Refer to [GitHub's documentation about pull requests][pull-request] for guidance.
 
 [pull-request]: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request
 
 ### Merging
 
-We usually squash & merge the pull requests into master.
+We typically squash and merge pull requests into our 'main' branch.
 
 ### Releasing
 
-We publish a new version using [GitHub Releases][release] in the web 
-browser. The workflow `./github/workflows/build-and-package-release.yml` will 
-automatically build and package the release bundles and attach them to the 
-GitHub release.
+We publish new versions using [GitHub Releases][release] via the web browser. The workflow `./github/workflows/build-and-package-release.yml` will 
+automatically build, package, and attach the release bundles to the GitHub release.
 
 [release]: https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository
 
+### Contributors
+
+For a complete list of all contributing individuals and companies, please visit our [CONTRIBUTORS](CONTRIBUTORS.md) page.
+
 ### Appendix: GitHub Workflows
 
-We use [GitHub Workflows][workflows] to automatically perform tasks such as 
-pre-commit checks, building, packaging and publishing the release bundles 
-as well as building and publishing docker images for demonstration.
+We use [GitHub Workflows][workflows] to automate tasks such as pre-commit checks, building, packaging, publishing release bundles, and building and 
+publishing Docker images for demonstration.
 
-Please see the directory `./.github/workflows` for the source code of 
-the work flows.
+Please see the `./.github/workflows` directory for the source code of our workflows.
 
 [workflows]: https://docs.github.com/en/actions/configuring-and-managing-workflows

README.md

@@ -478,5 +478,6 @@ https://github.com/admin-shell-io/aasx-server/issues/new).
 
 ## Contributing
 
-Code contributions are very welcome! Please see
-[CONTRIBUTING.md](CONTRIBUTING.md) for more information.
+Please see [CONTRIBUTING](CONTRIBUTING.md) for instructions on joining the development and general contribution guidelines.
+For a complete list of all contributing individuals and companies, please visit our [CONTRIBUTORS](CONTRIBUTORS.md) page.
+