Andreas/LibreChat
1
0
Fork 0
mirror of https://github.com/danny-avila/LibreChat.git synced 2026-02-08 18:44:22 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

update documentation structure (#220)

Browse source 
* documentation refactor

* Update README.md

* Delete README.MD.md

* Delete LOCAL_INSTALL.md

* Rename LICENSE.MD.md to LICENSE.MD

* Update LICENSE.md

* Delete LICENSE.MD

* Rename CONTRIBUTORS.MD.md to CONTRIBUTORS.md

* Rename CHANGELOG.MD.md to CHANGELOG.md

* new documents layout

* Update README.md

* Rename mac_install (1).md to mac_install.md

* Rename docker_install.md to docker_install.md

* Rename linux_install.md to linux_install.md

* Update and rename mac_install.md to mac_install.md

* Rename windows_install.md to windows_install.md

* Update docker_install.md

* Update linux_install.md

* Update mac_install.md

* Update windows_install.md

* Update windows_install.md

* Update linux_install.md

* Update tech_stack.md

* Update roadmap.md

* Update project_origin.md

* Update bing_jailbreak_info.md

* Update user_auth_system.md

* Update proxy.md

* Update google_search.md

* Update heroku.md

* Update testing.md

* Update pull_request_template.md

* Update documentation_guidelines.md

* Update contributor_guidelines.md

* Update code_of_conduct.md

* Update README.md

* Update README.md

* Update README.md

* Update roadmap.md

* Update tech_stack.md

* Update feature_request_template.md

* Update bug_report_template.md

* Update custom_issue_template.md

* Update README.md

fix redirect

* Update README.md

dynamic toc

* Update README.md

hide plugins section for now

* Update README.md

removed plugins from TOC

* Update README.md

* Update README.md

* Update documentation_guidelines.md

* Update documentation_guidelines.md

* Update documentation_guidelines.md

directives update

* Update README.md

update shortcut

* Update CHANGELOG.md

* Update roadmap.md

add public trello link

* Update linux_install.md
This commit is contained in:
Fuegovic 2023-05-09 13:47:14 -04:00 • committed by GitHub
parent 177028aafc
commit e2dc994b63
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
24 changed files with 1429 additions and 533 deletions
Download patch file Download diff file Expand all files Collapse all files

132
documents/contributions/code_of_conduct.md Normal file
View file

@ -0,0 +1,132 @@
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, religion, or sexual identity
and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the
overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
https://t.me/proffapt.
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series
of actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or
permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within
the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
##
## [Go Back to ReadMe](../../README.md)

177
documents/contributions/contributor_guidelines.md Normal file
View file

@ -0,0 +1,177 @@
# Contributor Guidelines
Thank you to all the contributors who have helped make this project possible! We welcome various types of contributions,
such as bug reports, documentation improvements, feature requests, and code contributions.
## Contributing Guidelines
When contributing to this repository, please first discuss the change you wish to make via [issue](https://github.com/danny-avila/chatgpt-clone/issues) or
join our discord [Discord community](https://discord.gg/NGaa9RPCft).
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions when necessary.
## To contribute to this project, please adhere to the following guidelines:
## 1. Git Workflow
We use a GitFlow workflow to manage changes to this project's codebase. Follow these general steps when contributing code:
1. Fork the repository and create a new branch with a descriptive slash based name (e.g., new/feature/x).
2. Implement your changes and ensure that all tests pass.
3. Commit your changes using conventional commit messages with GitFlow flags. Begin the commit message with a tag indicating the change type, such as "feat" (new feature), "fix" (bug fix), "docs" (documentation), or "refactor" (code refactoring), followed by a brief summary of the changes (e.g., `feat: Add new feature X to the project`).
4. Submit a pull request with a clear and concise description of your changes and the reasons behind them.
5. We will review your pull request, provide feedback as needed, and eventually merge the approved changes into the main branch.
## 2. Commit Message Format
We have very precise rules over how our Git commit messages must be formatted.
This format leads to **easier to read commit history**.
Each commit message consists of a **header**, a **body**, and a **footer**.
```
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
The `header` is mandatory and must conform to the [Commit Message Header](#commit-header) format.
The `body` is mandatory for all commits except for those of type "docs".
When the body is present it must be at least 20 characters long and must conform to the [Commit Message Body](#commit-body) format.
The `footer` is optional. The [Commit Message Footer](#commit-footer) format describes what the footer is used for and the structure it must have.
#### <a name="commit-header"></a>Commit Message Header
```
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: common|plays (2048, analog-clock, basic-calculator, etc.)|infra|etc.
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
```
The `<type>` and `<summary>` fields are mandatory, the `(<scope>)` field is optional.
##### Type
Must be one of the following:
* **build**: Changes that affect the build system or external dependencies
* **ci**: Changes to our CI configuration files and script
* **docs**: Documentation only changes
* **feat**: A new feature
* **fix**: A bug fix
* **perf**: A code change that improves performance
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **test**: Adding missing tests or correcting existing tests
##### Summary
Use the summary field to provide a succinct description of the change:
* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize the first letter
* no dot (.) at the end
#### <a name="commit-body"></a>Commit Message Body
Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".
Explain the motivation for the change in the commit message body. This commit message should explain _why_ you are making the change.
You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.
#### <a name="commit-footer"></a>Commit Message Footer
The footer can contain information about breaking changes and deprecations and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to.
For example:
```
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>
```
or
```
DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>
```
Breaking Change section should start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
Similarly, a Deprecation section should start with "DEPRECATED: " followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.
### Revert commits
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
The content of the commit message body should contain:
- information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`,
- a clear description of the reason for reverting the commit message.
Each commit message should start with a tag indicating the change type and a brief summary of the changes. This format enables quick identification of each commit's purpose and can be used to generate changelogs.
## 3. Pull Request Process
### Note: Submit a pull request with a clear and concise description of your changes and the reasons behind them. Be sure to include the steps to test the PR.
1. Ensure any install or build dependencies are removed before the end of the layer when doing a
build.
2. Update the README.md with details of changes to the interface, this includes new environment
variables, exposed ports, useful file locations and container parameters.
3. Increase the version numbers in any examples files and the README.md to the new version that this
Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
Ensure that your changes meet the following criteria when submitting a pull request:
- All tests pass.
- The code is well-formatted and adheres to our coding standards.
- The commit history is clean and easy to follow. (Use Squash to clean your commit history)
- The pull request description clearly outlines the changes and the reasons behind them.
## 4. Naming Conventions
Apply the following naming conventions to branches, labels, and other Git-related entities:
- Branch names: descriptive and slash based (e.g., new/feature/x)
- Labels: descriptive and snake_case (e.g., `bug_fix`).
- Directories and file names: descriptive and snake_case (e.g., `config_file.yaml`).
##
## [Go Back to ReadMe](../../README.md)

13
documents/contributions/documentation_guidelines.md Normal file
View file

@ -0,0 +1,13 @@
# Documentation Guidelines
- ## ⚠️Keep it organized and structured⚠️
- For new features, create new documents and place them in the appropriate folder(s)
- When you create a new document, do not forget to add it to the table of content
- Add a shortcut that point back to the [README.MD](../../README.md) in the new documents
- Do not add unrelated information to an existing document, create a new one if needed
- For incremental updates, you need to update the main **README.MD** and **CHANGELOG.MD**
- In the main README update the part where the last version is shown and the features section if needed
##
## [Go Back to ReadMe](../../README.md)

40
documents/contributions/pull_request_template.md Normal file
View file

@ -0,0 +1,40 @@
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
## Type of change
Please delete options that are not relevant.
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
# How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
- [ ] Test A
- [ ] Test B
**Test Configuration**:
* Firmware version:
* Hardware:
* Toolchain:
* SDK:
# Checklist:
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules
##
## [Go Back to ReadMe](../../README.md)

69
documents/contributions/testing.md Normal file
View file

@ -0,0 +1,69 @@
# Locally test the app during development
### Run the app
#### Option 1: Run the app using Docker
For reproducibility and ease of use, you can use
the provided docker-compose file:
1. Comment out the portion pointing at the already built image
```yaml
image: chatgptclone/app:0.3.3
```
2. Uncomment the portion pointing at the local source code
```yaml
# image: node-api
# build:
# context: .
# target: node-api
```
3. Build your local source code for the `node-api` target
```shell
docker build `
--target=node-api `
-t node-api `
.
```
4. Docker-compose up
```shell
docker-compose up
```
#### Option 2: Run the app by installing on your machine
1. Install the prerequisites on your machine.
See [section above](#install-the-prerequisites-on-your-machine).
2. Run the app on your machine.
See [section above](#run-the-app).
### Run the tests
1. Install the global dependencies
```shell
npm ci
npx playwright install --with-deps
```
2. Run tests
```shell
npx playwright test
```
If everything goes well, you should see a `passed` message.
<img src="https://user-images.githubusercontent.com/22865959/235321489-9be48fd6-77d4-4e21-97ad-0254e140b934.png">
##
## [Go Back to ReadMe](../../README.md)