diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000..ffb3cfc140 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,233 @@ +# Contributing + +We would ❤️ for 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, 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 our next section explaining what kind of help is needed and where you can get involved. You can reach out with questions on our [Discord](https://appwrite.io/discord) server. You can also submit an issue and a maintainer can guide you! + +## Repo Structure + +``` +├── src +│ ├── lib // All non-route components, accessible over "import ... from '$lib'" +│ │ ├── components // Re-usable components +│ │ ├── elements // Re-usable elements +│ │ ├── layout // Global components for the layout (Nav/Content/Container) +│ │ └── stores // Global stores (state management) +│ └─── routes +│ ├── console // Routes that need authentication +│ │ ├──[project] +│ │ │ ├── database // Database Service +│ │ │ │ ├── [collection] // Nested Route for the collection "/console/[PROJECT_ID]/database/[COLLECTION_ID]" +│ │ │ │ ├── _create.svelte // Component to Create collections +│ │ │ │ └── index.svelte // Entrypoint for "/console/[PROJECT_ID]/database" +│ │ │ ├── storage // Storage Service "/console/[PROJECT]/storage" +│ │ │ └── auth // Users Service "/console/[PROJECT]/auth" +│ │ └──... +│ ├── login.svelte // Component for Login "/console/login" +│ └── register.svelte // Component for Register "/console/register" +├── build // Compiled application +└── static // Static assets +``` + +## Development + +Once you've created a project and installed dependencies with `npm install`, start a development server: + +```bash +npm run dev +``` + +### Build + +```bash +npm run build +``` + +> You can preview the built app with `npm run preview`, regardless of whether you installed an adapter. This should _not_ be used to serve your app in production. + +### Tests + +```bash +npm test +``` + +This will run tests in the `tests/` directory. + +### Format + +Code should like everywhere the same, for this reason a code-formatter is mandatory. + +```bash +npm run format +``` + +### Linter + +```bash +npm run lint +``` + +### Diagnostics + +Diagnostic tool that checks for following: + +- Unused CSS +- Svelte A11y hints +- TypeScript compiler errors + +```bash +npm run check +``` + +## Submit a Pull Request 🚀 + +Branch naming convention is as follows + +`TYPE-ISSUE_ID-DESCRIPTION` + +example: + +``` +doc-548-submit-a-pull-request-section-to-contribution-guide +``` + +When `TYPE` can be: + +- **feat** - is 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!** + +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: + +1. Before creating a new branch, pull the changes from upstream to make sure your default branch is be up to date. + +``` +$ git pull +``` + +2. Create a new branch from the default branch. For example `doc-548-submit-a-pull-request-section-to-contribution-guide` + +``` +$ git checkout -b [name_of_your_new_branch] +``` + +3. Work - commit - repeat ( be sure to be in your branch ) +4. Push changes to GitHub + +``` +$ git push origin [name_of_your_new_branch] +``` + +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. +7. Start a Pull Request (PR) by clicking on `Create pull request`. Make sure to update the PR description following the template provided. +8. Wait for a code review. +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. + +![Re-Request a Review](https://docs.github.com/assets/cb-4714/images/help/pull_requests/request-re-review.png) + +10. After approval, your PR will be merged. +11. You can delete your branch after it has been merged. + +## Guidelines + +### Consistency + +Before commiting always make sure to run all available tools to improve the codebase: + +- Formatter + - `npm run format` +- Tests + - `npm test` +- Diagnostics + - `npm run check` + +### Performance + +Page load times are a key consideration for users of all browsers and device types. + +There are some general things we can do in front-end development: + +- Minimise HTTP requests +- Minimise blocking – content should be readable before client side processing +- Lazy load 'supplementary' content (especially images) + +### Don't Repeat Yourself (DRY) + +If you repeat anything that has already been defined in code, refactor it so that it only ever has one representation in the codebase. + +If you stick to this principle, you will ensure that you will only ever need to change one implementation of a feature without worrying about needing to change any other part of the code. + +### Separation of concerns + +Separate _structure_ from _presentation_ from _behaviour_ to aid maintainability and understanding. + +- Keep CSS (presentation), JS (behaviour) and HTML (structure) in the same respective Svelte component +- Avoid writing inline CSS or Javascript in HTML +- Avoid writing CSS or HTML in Javascript +- Don't choose HTML elements to imply style +- Where appropriate, use CSS or Svelte rather than Javascript for animations and transitions +- Try to use templates when defining markup in Javascript + +### Write code to be read + +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. + +### Identify technical debt + +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. + +Don't use `@fixme` (which defines things that are broken) - you shouldn't be committing broken code to the repo. + +### Dependencies + +Please avoid introducing new dependencies to Appwrite without consulting the team. New dependencies can be very helpful but also introduce new security and privacy issues, complexity, and impact total docker image size. + +Adding a new dependency should have vital value on the product with minimum possible risk. + +## Introducing New Features + +We would 💖 you to contribute to Appwrite, but we would also like to make sure Appwrite is as great as possible and loyal to its vision and mission statement 🙏. + +For us to find the right balance, please open an issue explaining your ideas before introducing a new pull request. + +This will allow the Appwrite community to have sufficient discussion about the new feature value and how it fits in the product roadmap and vision. + +This is also important for Appwrite maintainers to discuss the feature's design and architecture to help the contribution fit in organically in the Appwrite codebase. Some bigger features might need to go through our [RFC process](https://github.com/appwrite/rfc). + +## Other Ways to Help + +Pull requests are great, but there are many other areas where you can help Appwrite. + +### Blogging & Speaking + +Blogging, speaking about, or creating tutorials about one of Appwrite’s many features. 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 + +Presenting 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 & 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 about 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 can think about your new idea and it's 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. Spelling or grammar fixes will be very much appreciated. + +### Helping Someone + +Searching for Appwrite on Discord, GitHub, or StackOverflow and helping someone else who needs help. You can also help by teaching others how to contribute to Appwrite's repo! + +## 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). diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000000..8dcd0631cf --- /dev/null +++ b/LICENSE @@ -0,0 +1,12 @@ +Copyright (c) 2019 Appwrite (https://appwrite.io) and individual contributors. +All rights reserved. + +Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: + + 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. + + 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. + + 3. Neither the name Appwrite nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. \ No newline at end of file diff --git a/README.md b/README.md index 16063cf7ec..0dd0948949 100644 --- a/README.md +++ b/README.md @@ -1,156 +1,52 @@ -![Appwrite](github.png) +# Console 🖥️ + +[![Discord](https://img.shields.io/discord/564160730845151244?label=discord&style=flat-square)](https://appwrite.io/discord) +[![Twitter Account](https://img.shields.io/twitter/follow/appwrite?color=00acee&label=twitter&style=flat-square)](https://twitter.com/appwrite) +[![appwrite.io](https://img.shields.io/badge/appwrite-.io-f02e65?style=flat-square)](https://appwrite.io) -# @appwrite/console +![Appwrite](github.png) -This is the base project for the new dashboard for Appwrite. +[Appwrite](https://appwrite.io) Console is the Graphical User Interface that developers interact with when accessing their Appwrite instance in the web browser. -Built with: +Appwrite Console has been built with the following frameworks: - [Svelte](https://svelte.dev/) - [Svelte Kit](https://kit.svelte.dev/) -- [@appwrite/ui](https://github.com/appwrite/ui) - -Table of Contents: - -- [Development](#development) - - [Build](#build) - - [Tests](#tests) - - [Format](#format) - - [Linter](#linter) - - [Diagnostics](#diagnostics) -- [Contributing](#contributing) - - [Guidelines](#guidelines) - - [Structure](#structure) - -# Development - -Once you've created a project and installed dependencies with `npm install`, start a development server: - -```bash -npm run dev -``` - -## Build - -```bash -npm run build -``` - -> You can preview the built app with `npm run preview`, regardless of whether you installed an adapter. This should _not_ be used to serve your app in production. - -## Tests - -```bash -npm test -``` - -This will run tests in the `tests/` directory. - -## Format -Code should like everywhere the same, for this reason a code-formatter is mandatory. +## Developer Experience -```bash -npm run format -``` +Developer experience has always been a priority for Appwrite since its inception. The web console is one of the most important pieces of the developer experience puzzle. The new web console not only looks better but serves a functional purpose. -## Linter +### Simplicity -```bash -npm run lint -``` - -## Diagnostics - -Diagnostic tool that checks for following: - -- Unused CSS -- Svelte A11y hints -- TypeScript compiler errors - -```bash -npm run check -``` - -# Contributing - -## Guidelines +The new UI reduces visual load with more purposeful color use and more selective inclusion of information. ### Consistency -Before commiting always make sure to run all available tools to improve the codebase: - -- Formatter - - `npm run format` -- Tests - - `npm test` -- Diagnostics - - `npm run check` - -### Performance - -Page load times are a key consideration for users of all browsers and device types. - -There are some general things we can do in front-end development: - -- Minimise HTTP requests -- Minimise blocking – content should be readable before client side processing -- Lazy load 'supplementary' content (especially images) - -### Don't Repeat Yourself (DRY) - -If you repeat anything that has already been defined in code, refactor it so that it only ever has one representation in the codebase. - -If you stick to this principle, you will ensure that you will only ever need to change one implementation of a feature without worrying about needing to change any other part of the code. +The new Appwrite Console uses a consistent UI library, so navigating from page to page and task to task will flow seamlessly. -### Separation of concerns +### Accessibility -Separate _structure_ from _presentation_ from _behaviour_ to aid maintainability and understanding. +Console 2.0 is designed to be accessible, from design to code. Console 2.0 is also designed to be accessible to developers of all skill levels. Complex workflows will provide more guidance for newer developers and promote good technical decisions. -- Keep CSS (presentation), JS (behaviour) and HTML (structure) in the same respective Svelte component -- Avoid writing inline CSS or Javascript in HTML -- Avoid writing CSS or HTML in Javascript -- Don't choose HTML elements to imply style -- Where appropriate, use CSS or Svelte rather than Javascript for animations and transitions -- Try to use templates when defining markup in Javascript +### Scalability and Collaboration -### Write code to be read +The new console is more maintainable and welcoming to community contributions. Console 2.0 is built using Svelte instead of our own library. It’s better documented and well-known, making it easier for developers to contribute to Appwrite. -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. +## Contributing -### Identify technical debt +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. -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. +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). -Don't use `@fixme` (which defines things that are broken) - you shouldn't be committing broken code to the repo. +## Security -### Dependencies +For security issues, kindly email us at [security@appwrite.io](mailto:security@appwrite.io) instead of posting a public issue on GitHub. -Please avoid introducing new dependencies to Appwrite without consulting the team. New dependencies can be very helpful but also introduce new security and privacy issues, complexity, and impact total docker image size. +## Follow Us -Adding a new dependency should have vital value on the product with minimum possible risk. +Join our growing community around the world! See our official [Blog](https://medium.com/appwrite-io). Follow us on [Twitter](https://twitter.com/appwrite), [Facebook Page](https://www.facebook.com/appwrite.io), [Facebook Group](https://www.facebook.com/groups/appwrite.developers/), [Dev Community](https://dev.to/appwrite) or join our live [Discord server](https://appwrite.io/discord) for more help, ideas, and discussions. -## Structure +## License -``` -├── src -│ ├── lib // All non-route components, accessible over "import ... from '$lib'" -│ │ ├── components // Re-usable components -│ │ ├── elements // Re-usable elements -│ │ ├── layout // Global components for the layout (Nav/Content/Container) -│ │ └── stores // Global stores (state management) -│ └─── routes -│ ├── console // Routes that need authentication -│ │ ├──[project] -│ │ │ ├── database // Database Service -│ │ │ │ ├── [collection] // Nested Route for the collection "/console/[PROJECT_ID]/database/[COLLECTION_ID]" -│ │ │ │ ├── _create.svelte // Component to Create collections -│ │ │ │ └── index.svelte // Entrypoint for "/console/[PROJECT_ID]/database" -│ │ │ ├── storage // Storage Service "/console/[PROJECT]/storage" -│ │ │ └── auth // Users Service "/console/[PROJECT]/auth" -│ │ └──... -│ ├── login.svelte // Component for Login "/console/login" -│ └── register.svelte // Component for Register "/console/register" -├── build // Compiled application -└── static // Static assets -``` +This repository is available under the [BSD 3-Clause License](./LICENSE). diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..86446ee1a0 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,12 @@ +# Security Policy + +## Supported Versions + +| Version | Supported | +| -------- | ------------------ | +| <= 1.0.3 | :x: | +| 1.1.x | :white_check_mark: | + +## Reporting a Vulnerability + +For security issues, kindly email us at security@appwrite.io instead of posting a public issue in GitHub. diff --git a/github.png b/github.png index fd96e8923f..69c93cc000 100644 Binary files a/github.png and b/github.png differ