Docs: Add public docs

.github/workflows/markdown-table-workflow/index.js

@@ -37,7 +37,7 @@ const uniqueTemplates = [...new Set(templates)];
 
 const rows = uniqueTemplates.map((template) => {
     const languagesSupport = runtimes.map((runtime) => {
-        return fs.existsSync(path.join('.', `../../../${runtime}/${template}`)) ? `[✅](/${runtime}/${template})` : '';
+        return fs.existsSync(path.join('.', `../../../${runtime}/${template}`)) ? `[✅](/${runtime}/${template})` : '❌';
     })
 
     return [template, ...languagesSupport];

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity, expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## 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
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers 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, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at team@appwrite.io. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,164 @@
+# Contributing
+
+We would ❤️ you to contribute to Appwrite and help make it better! We want 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.
+
+## How to Start?
+
+If you are worried or don’t know where to start, check out the next section that explains what kind of help we could use and where you can get involved. You can send your questions to [@appwrite](https://twitter.com/appwrite) on Twitter or to anyone from the [Appwrite team on Discord](https://appwrite.io/discord). You can also submit an issue, and a maintainer can guide you!
+
+## Code of Conduct
+
+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).
+
+## Submit a Pull Request 🚀
+
+Branch naming convention is as following
+
+`TYPE-ISSUE_ID-DESCRIPTION`
+
+example:
+
+```
+doc-548-submit-a-pull-request-section-to-contribution-guide
+```
+
+When `TYPE` can be:
+
+- **feat** - a new feature
+- **doc** - documentation only changes
+- **cicd** - changes related to CI/CD system
+- **fix** - a bug fix
+- **refactor** - code change that neither fixes a bug nor adds a feature
+
+**All PRs must include a commit message with the description of the changes made!**
+
+For the initial start, fork the project and use git clone command to download the repository to your computer. A standard procedure for working on an issue would be to:
+
+1. `git pull`, before creating a new branch, pull the changes from upstream. Your master needs to be up to date.
+
+```
+$ git pull
+```
+
+2. Create a new branch from `master` like: `doc-548-submit-a-pull-request-section-to-contribution-guide`.<br/>
+
+```
+$ git checkout -b [name_of_your_new_branch]
+```
+
+3. Work - commit - repeat (make sure you're on the correct branch!)
+
+4. Push changes to GitHub.
+
+```
+$ git push origin [name_of_your_new_branch]
+```
+
+5. 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.
+6. Start a Pull Request
+   Now submit the pull request and click on `Create pull request`.
+7. Get a code review approval/reject.
+8. After approval, merge your PR.
+9. GitHub will automatically delete the branch after the merge is done. (they can still be restored).
+
+### File Structure
+
+```bash
+.
+├── node # Runtime name
+│   ├── starter # Template name
+│   │   ├── ... # Runtime & template specific files
+│   │   └── README.md # Template documentation
+│   └── ... # More templates
+├── ... # More runtimes
+├── _README_TEMPLATE.md # README template to use for new templates
+└── ... # License and documentation
+```
+
+## Coding Standards
+
+All code in templates should be formatted. Use formatter that is most common in runtime for which you are developing the template. If there isn't popular one in a runtime, you can use [Prettier](https://prettier.io/).
+
+## Security and Privacy
+
+Security and privacy are extremely important to Appwrite, developers, and users alike. Make sure to follow the best industry standards and practices.
+
+## Dependencies
+
+Usage of dependencies is welcomed for purpose of simplifying template code. Please only use libraries that are well-known, and popular.
+
+## Introducing New Templates
+
+### 1. Starting a Discussion
+
+We would 💖 you to contribute to Appwrite, but we also want to ensure Appwrite is loyal to its vision and mission statement 🙏.
+
+For us to find the right balance, please open an issue explaining your template idea before introducing a new pull request.
+
+This will allow the Appwrite community to sufficiently discuss the new template value.
+
+### 2. Preparing the Template
+
+Once you have the go-ahead, you can proceed to create a PR from your issue.
+
+The preparation process is largely dependent on the runtime environment you choose to work with. We recommend starting with Node.JS and then moving on to other runtimes, after receiving feedback. Here's a generic process that could be applied to most runtimes:
+
+1. **Create a new folder** in the directory for your specific runtime with the name of your template.
+
+2. **Initialize your project**. In Node.js for example, you could run `npm init` in the new folder.
+
+3. **Add a `.gitignore` file** to the new directory, to ignore files and directories that don't need to be version controlled.
+
+4. **Add configuration files specific to your runtime**. This may include formatter configurations, lockfiles or others.
+
+5. **Install necessary dependencies**. Using Node.js as an example, you could run `npm install <package-name>`.
+
+6. **Create an entrypoint in the `src` folder**. This will be the main file where the template logic resides.
+
+> Tip: Be sure to take a look at `starter` templates templates to get a better understanding of how they are structured.
+
+### 3. Building the Template Logic
+
+With the template setup, you can proceed to writing the template logic in the entrypoint file.
+
+The writing process should focus more on readability, maintainability and simplicity. It's essential to write code that tells a story. If the logic begins to look complex, consider breaking it down into smaller, manageable files or re-using services from existing templates where applicable.
+
+> Tip: Be sure to look at some of the existing templates to understand how we expect the code
+
+### 4. Writing the Template Documentation
+
+After completing the template logic, the next step is to document the template. This will be very useful to anyone who wants to understand or use your template in the future.
+
+The `_README_TEMPLATE.md` file serves as a guide for writing your template documentation. Ensure you complete all the fields and remove any that are not relevant to your template.
+> Note: You don't need to update the table within the `README.md` file in the root of the repository. This will be done automatically once the template is merged.
+
+Once all the steps are completed, you can submit your PR for review. Make sure to include any necessary details in the PR description. This makes it easier for the reviewers to understand the context and provide constructive feedback.
+
+## Other Ways to Help
+
+Pull requests are great, but there are many other ways you can help Appwrite.
+
+### Blogging & Speaking
+
+Blogging, speaking about, or creating tutorials about one of Appwrite’s many features are great ways to get the word out about Appwrite. Mention [@appwrite](https://twitter.com/appwrite) on Twitter and/or [email team@appwrite.io](mailto:team@appwrite.io) 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.
+
+### Presenting at Meetups
+
+We encourage our contributors to present at meetups and conferences about your Appwrite projects. 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!
+
+### Sending Feedbacks and Reporting Bugs
+
+Sending feedback is a great way for us to understand your different use cases of Appwrite better. If you had any issues, bugs, or want to share your experience, feel free to do so on our GitHub issues page or at our [Discord channel](https://discord.gg/GSeTUeA).
+
+### Submitting New Ideas
+
+If you think Appwrite could use a new feature, please open an issue on our GitHub repository, stating as much information as you have 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.
+
+### Improving Documentation
+
+Submitting documentation updates, enhancements, designs, or bug fixes, as well as spelling or grammar fixes is much appreciated.
+
+### Helping Someone
+
+Consider searching for Appwrite on Discord, GitHub, or StackOverflow to help someone who needs help. You can also help by teaching others how to contribute to Appwrite's repo!

README.md

@@ -1,9 +1,37 @@
-# Templates
+# 📚 Appwrite Templates
 
-Repository to hold all the starter templates for Appwrite Functions.
+[![We're Hiring](https://img.shields.io/static/v1?label=We're&message=Hiring&color=blue&style=flat-square)](https://appwrite.io/company/careers)
+[![Hacktoberfest](https://img.shields.io/static/v1?label=hacktoberfest&message=ready&color=191120&style=flat-square)](https://hacktoberfest.appwrite.io)
+[![Discord](https://img.shields.io/discord/564160730845151244?label=discord&style=flat-square)](https://appwrite.io/discord?r=Github)
+[![Twitter Account](https://img.shields.io/twitter/follow/appwrite?color=00acee&label=twitter&style=flat-square)](https://twitter.com/appwrite)
+
+Templates for [Appwrite](https://appwrite.io/) Functions. These templates can be used as starters for your functions, or for learning purposes.
+
+# List of Templates
 
 <!-- TABLE:START -->
-| Template | C++               | Dart               | Deno               | .NET                 | Java               | Kotlin               | Node.js            | PHP               | Python               | Ruby               | Swift               |
-| -------- | ----------------- | ------------------ | ------------------ | -------------------- | ------------------ | -------------------- | ------------------ | ----------------- | -------------------- | ------------------ | ------------------- |
-| starter  | [✅](/cpp/starter) | [✅](/dart/starter) | [✅](/deno/starter) | [✅](/dotnet/starter) | [✅](/java/starter) | [✅](/kotlin/starter) | [✅](/node/starter) | [✅](/php/starter) | [✅](/python/starter) | [✅](/ruby/starter) | [✅](/swift/starter) |
-<!-- TABLE:END -->
+<!-- TABLE:END -->
+
+✅ = Done - Function is implemented in this runtime.
+❌ = Missing - Function isn't implemented in this runtime yet. Contributions are welcomed.
+
+## Contributing
+
+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.
+
+All functions should have the exactly same functionality as their other language counterparts and if possible you should avoid using any third-party libraries to keep the functions simple and secure.
+
+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](https://github.com/open-runtimes/.github/blob/main/CONTRIBUTING.md).
+
+
+## Security
+
+For security issues, kindly email us at [security@appwrite.io](mailto:security@appwrite.io) instead of posting a public issue on GitHub.
+
+## Discord Server
+
+Join our live [Discord server](https://appwrite.io/discord) for more help, ideas, and discussions.
+
+## License
+
+This repository is available under the [MIT License](./LICENSE).

deno/starter/README.md

@@ -35,7 +35,7 @@ Sample `200` Response:
 
 ## ⚙️ Configuration
 
-| Setting           | Value    -----------     |
+| Setting           | Value                    |
 |-------------------|--------------------------|
 | Runtime           | Deno (1.35)              |
 | Entrypoint        | `src/main.ts`            |

node/starter/README.md

@@ -1,4 +1,4 @@
-# ⚡ Starter Function
+# ⚡ Node.js Starter Function
 
 A simple starter function. Edit `src/main.js` to get started and create something awesome! 🚀