Skip to content

Commit 9721758

Browse files
authored
Merge pull request #4 from appwrite/docs-guides
Readme and contribution
2 parents 87ac673 + 1721ed8 commit 9721758

File tree

3 files changed

+191
-0
lines changed

3 files changed

+191
-0
lines changed

.env.example

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
OPENAI_API_KEY=YOUR_OPENAI_API_KEY

CONTRIBUTING.md

Lines changed: 157 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,157 @@
1+
# Contributing
2+
3+
We would ❤️ for you to contribute to Appwrite and help make it better! We want your experience while contributing to Appwrite to be fun, enjoyable, and educational for anyone and everyone. All contributions are welcome, including issues, and new docs, as well as updates and tweaks, blog posts, workshops, and more.
4+
5+
## How to Start?
6+
7+
If you are worried about or don’t know where to start, check out the next section that explains what kind of help is needed and how you can get involved. You can reach out with any questions on our [Discord](https://appwrite.io/discord) server. You can also submit an issue and a maintainer can guide you!
8+
9+
## Development
10+
11+
### 1. Clone the repository with git
12+
13+
```bash
14+
git clone https://github.com/appwrite/console.git appwrite-assistant
15+
```
16+
17+
### 2. Install dependencies with pnpm
18+
19+
Navigate to the Appwrite Assistant repository and install dependencies.
20+
21+
```bash
22+
cd appwrite-assistant && pnpm install
23+
```
24+
25+
### 3. Setup environment variables
26+
27+
Add a `.env` file by copying the `.env.example` file as a template in the project's root directory.
28+
29+
Finally, start a development server:
30+
31+
```bash
32+
npm run dev
33+
```
34+
35+
## Submit a Pull Request 🚀
36+
37+
The branch naming convention is as follows
38+
39+
`TYPE-ISSUE_ID-DESCRIPTION`
40+
41+
example:
42+
43+
```
44+
doc-548-submit-a-pull-request-section-to-contribution-guide
45+
```
46+
47+
When `TYPE` can be:
48+
49+
- **feat** - is a new feature
50+
- **doc** - documentation only changes
51+
- **cicd** - changes related to CI/CD system
52+
- **fix** - a bug fix
53+
- **refactor** - code change that neither fixes a bug nor adds a feature
54+
55+
**All PRs must include a commit message with a description of the changes made!**
56+
57+
Start by forking the project and use the `git clone` command to download the repository to your computer. A standard procedure for working on an issue would be to:
58+
59+
1. Before creating a new branch, pull the changes from upstream to make sure your default branch is up to date.
60+
61+
```
62+
$ git pull
63+
```
64+
65+
2. Create a new branch from the default branch. For example `doc-548-submit-a-pull-request-section-to-contribution-guide`
66+
67+
```
68+
$ git checkout -b [name_of_your_new_branch]
69+
```
70+
71+
3. Work - commit - repeat ( be sure to be in your branch )
72+
4. Push changes to GitHub
73+
74+
```
75+
$ git push origin [name_of_your_new_branch]
76+
```
77+
78+
6. Submit your changes for review. If you go to your repository on GitHub, you'll see a `Compare & pull request` button. Click on that button.
79+
7. Start a Pull Request (PR) by clicking on `Create pull request`. Make sure to update the PR description following the template provided.
80+
8. Wait for a code review.
81+
9. If you need to make changes based on feedback, make sure to re-request a review from your reviewer after you've made the necessary changes.
82+
83+
![Re-Request a Review](https://docs.github.com/assets/cb-4714/images/help/pull_requests/request-re-review.png)
84+
85+
10. After approval, your PR will be merged.
86+
11. You can delete your branch after it has been merged.
87+
88+
## Guidelines
89+
90+
### Write code to be read
91+
92+
Follow the principles of ['Keep It Simple, Stupid'](http://en.wikipedia.org/wiki/KISS_principle) (KISS); hard-to-read or obfuscated code is difficult to maintain and debug. Don't be too clever; write code to be read.
93+
94+
### Identify technical debt
95+
96+
Use code comment annotations (`@todo`) to mark parts of your code that require further work. This will allow the measurement and management of technical debt.
97+
98+
Don't use `@fixme`, which defines things that are broken. Don't commit broken code in to the repo.
99+
100+
### Dependencies
101+
102+
Please avoid introducing new dependencies to Appwrite without consulting the team. New dependencies can be very helpful, but they also introduce new security and privacy issues, complexity, and impact total docker image size.
103+
104+
Adding a new dependency should contribute vital value to the product with minimum possible risk.
105+
106+
## Updating the Documentation
107+
108+
We created a python script, located at `scrape.py`, that fetches various links in the Appwrite documentation, and saves them to JSON files in the `docs` folder. To run the script, execute the following command.
109+
110+
```bash
111+
python3 -m pip install -r requirements.txt
112+
python3 scrape.py
113+
```
114+
115+
To update the documentation, you can change which files are fetched by editing the `scrape.py` file.
116+
117+
## Introducing New Features
118+
119+
We would 💖 you to contribute to Appwrite, but we also want to ensure Appwrite is loyal to its vision and mission statement 🙏.
120+
121+
For us to find the right balance, please open an issue explaining your ideas before introducing a new pull request.
122+
123+
This will allow the Appwrite community to sufficiently discuss the new feature value and how it fits within the product roadmap and vision.
124+
125+
This is also important for the Appwrite lead developers to be able to provide technical input and potentially a different emphasis regarding the feature design and architecture. Some bigger features might need to go through our [RFC process](https://github.com/appwrite/rfc).
126+
127+
## Other Ways to Help
128+
129+
Pull requests are great, but there are many other areas where you can help Appwrite.
130+
131+
### Blogging & Speaking
132+
133+
When blogging, speaking about, or creating tutorials about one of Appwrite's many features, mention [@appwrite](https://twitter.com/appwrite) on Twitter and/or email [[email protected]](mailto:[email protected]) so we can give pointers and tips and help you spread the word by promoting your content on the different Appwrite communication channels. Please add your blog posts and videos of talks to our [Awesome Appwrite](https://github.com/appwrite/awesome-appwrite) repo on GitHub.
134+
135+
### Presenting at Meetups
136+
137+
Presenting at meetups and conferences about your Appwrite projects is another excellent way to get the word out about Appwrite. Your unique challenges and successes in building things with Appwrite can provide great speaking material. We’d love to review your talk abstract/CFP, so get in touch with us if you’d like some help!
138+
139+
### Sending Feedback & Reporting Bugs
140+
141+
Sending feedback is an excellent way for us to understand different use cases for Appwrite. If you have any issues or want to share your experience, feel free to do so on our GitHub issues page or our [Discord channel](https://discord.gg/GSeTUeA).
142+
143+
### Submitting New Ideas
144+
145+
If you think Appwrite could use a new feature, please open an issue on our GitHub repository, stating as much information as you can think about your new idea and its implications. We would also use this issue to gather more information, get more feedback from the community, and have a proper discussion about the new feature.
146+
147+
### Improving Documentation
148+
149+
Submitting documentation updates, enhancements, designs, or bug fixes help us to improve our documentation. Spelling or grammar fixes are also very much appreciated.
150+
151+
### Helping Someone
152+
153+
You can also help by teaching others how to contribute to Appwrite's repo! Please consider searching for Appwrite on Discord, GitHub, or StackOverflow and helping someone else who needs help.
154+
155+
## Code of Conduct
156+
157+
Help us keep Appwrite open and inclusive. Please read and follow our [Code of Conduct](https://github.com/appwrite/.github/blob/main/CODE_OF_CONDUCT.md).

README.md

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
# Assistant ✨
2+
3+
[![Discord](https://img.shields.io/discord/564160730845151244?label=discord&style=flat-square)](https://appwrite.io/discord)
4+
[![Twitter Account](https://img.shields.io/twitter/follow/appwrite?color=00acee&label=twitter&style=flat-square)](https://twitter.com/appwrite)
5+
[![appwrite.io](https://img.shields.io/badge/appwrite-.io-f02e65?style=flat-square)](https://appwrite.io)
6+
7+
Appwrite Assistant is an AI-powered API that helps you with Appwrite-related tasks, powered by the official Appwrite documentation.
8+
9+
## Installation
10+
11+
Make sure you have [pnpm](https://pnpm.io/) installed.
12+
13+
To install, run the following command.
14+
15+
```bash
16+
pnpm i
17+
```
18+
19+
## Usage
20+
21+
To run the server, execute the `main.js` file with node, or run the `dev` command to hot-restart the server on file changes.
22+
23+
```bash
24+
node main.js
25+
# Or
26+
pnpm run dev
27+
```
28+
29+
## Contributing
30+
31+
All code contributions, including those of people having commit access, must go through a pull request and be approved by a core developer before being merged. This is to ensure a proper review of all the code.
32+
33+
We truly ❤️ pull requests! If you wish to help, you can learn more about how you can contribute to this project in the [contribution guide](CONTRIBUTING.md).

0 commit comments

Comments
 (0)