Overview

#Welcome to erxes community 👋

erxes is a community-oriented project with an emphasis on transparency. We put our heart to share our vision and build the future of erxes together with our community. erxes the roadmap is open for community members to have an insights and envolve in the project in right direction.

Your ideas and opinions are always welcome!

Ways to contribute

• We welcome pull requests, but we do have several guidelines for contributing and for our sanity. Please read our contributing guide before submitting a Pull Request to the project.
• As part of our effort to grow and invest in the community, we are excited to share this investment opportunity with you.
• We have a marketplace that you can place your plugins that you have developed and earn from it. This is the complete guideline to show you how you can make it happen. It’s for anyone who wants to make money doing what they love.

✨ Community

erxes documentation contains instructions for everything you need to know about erxes. If you still have questions, please contact us! We are happy to help :)

For additional information, you can use any of these channels to get the answer you are looking for:

• Discord For live discussion with the Community
• GitHub Bug reports, Contributions
• Community forum Questions and Discussions
• Feedback section Roadmap, Feature requests & bugs
• Twitter Get the news fast

Need Additional Help?

If you need any additional help while contributing, you can join our Discord and ask erxes core team as well as the community any questions.

Contribute to codebase

Thank you for considering contributing to erxes! This document will outline how to submit changes to this repository and which conventions to follow. If you are ever in doubt about anything, we encourage you to reach out by submitting an issue here or via Discord.

Prerequisites

• You have to be familiar with GitHub Issues and Pull Requests
• You should to read the docs.
• You make sure you set up a test project with erxes

Issues before PRs

1. Before you start working on a change, please make sure there is an issue with what you will be working on. You can either find an existing issue or open a new issue if none exists. Doing this ensures that others can contribute with thoughts or suggest alternatives, ultimately ensuring that we only add changes that make the most sense for erxes future.
2. When you are ready to start working on a change, you should first fork the erxes repo and branch out from the develop branch.
3. Make your changes.
4. Open a pull request towards the development branch in the erxes repo. Within a couple of days, erxes team members will review, comment, and eventually approve your PR.

Workflow

Branches

All changes should be part of a branch and submitted as a pull request - your branches should be prefixed with one of:

• fix/ for bug fixes
• feat/ for features
• docs/ for documentation changes

Commits

Strive towards keeping your commits small and isolated - this helps the reviewer understand what is going on and makes it easier to process your requests.

Pull Requests

Once your changes are ready, you must submit your branch as a pull request. Your pull request should be opened against the development branch in the main erxes repo.

In your PR's description, you should follow the structure:

• What - what changes are in this PR
• Why - why are these changes relevant
• How - how have the changes been implemented
• Testing - how have the changes been tested or how can the reviewer test the feature

We highly encourage that you do a self-review prior to requesting a review. To do a self-review click the review button in the top right corner, go through your code and annotate your changes. This makes it easier for the reviewer to process your PR.

Merge Style

All pull requests are squashed and merged.

Testing

All PRs should include tests for the changes that are included. We have two types of tests that must be written:

• Unit tests found under packages//src/services/tests and packages//src/api/routes/*/tests
• Integration tests found in integration-tests/*/tests

Documentation

• We generally encourage to document your changes through comments in your code.
• If you alter user-facing behavior, you must provide documentation for such changes.
• All methods and endpoints should be documented using JSDoc and swagger-inline.

Release

The erxes team will regularly create releases from the develop branch.

Contribute to documentation

Thank you for your interest in contributing to the documentation! You will be helping the open source community and other developers interested in learning more about erxes and using them.

Site Setup

The documentation website is built with Docusaurus, a framework that optimizes documentation creation. If you’re not familiar with Docusaurus, it’s recommended to check out the Installation documentation on their website to understand Docusaurus better, how it works, its structure, and more details. The documentation codebase is hosted as part of the erxes repository on GitHub. You’ll find the code that runs the docusaurus website under the www/docs directory.

Documentation Content

The documentation content is written in Markdown format. If you’re not familiar with Markdown, check out this cheat sheet for a quick start. You’ll also find MDX files. MDX files combine the power of Markdown with React. So, the content of the file can contain JSX components and import statements, among other features. You can learn more about MDX in docusaurus’s guide.

What You Can Contribute To

• You can contribute to the Docusaurus codebase to add a new plugin or fix a bug in the documentation website.
• You can contribute to the documentation content either by fixing errors you find or adding documentation pages.

Style guide

When you contribute to the documentation content, make sure to follow the documentation style guide.

How to Contribute

If you’re fixing errors in an existing documentation page, you can scroll down to the end of the page and click on the “Edit this page” link. You’ll be redirected to the GitHub edit form of that page and you can make edits directly and submit a pull request (PR). If you’re adding a new page or contributing to the codebase, fork the repository, create a new branch, and make all changes necessary in your repository. Then, once you’re done creating a PR in erxes repository. For more details on how to contribute, check out the contribution guidelines on our repository.

• Branch Name When you make edit to an existing documentation page or fork the repository to make changes to the documentation, you have to create a new branch. Make sure that the branch name starts with docs/. For example, docs/fix-services.

• Pull Request Conventions When you create a pull request, prefix the title with “docs:”. Make sure to keep “docs” in small letters. In the body of the PR, explain clearly what the PR does. If the PR solves an issue, use closing keywords with the issue number. For example, “Closes #1333”.

Sidebar

When you add a new page to the documentation, you must add the new page in www/docs/sidebars.js under the tutorialSidebar. You can learn more about the syntax used here.

-Terminology When the documentation page is a conceptual or overview documentation, the label in the sidebar should start with a noun. When the documentation page is a tutorial documentation, the label in the sidebar should start with a verb. An exception of this rule are integration documentations and upgrade guides.

Notes and Additional Information

When displaying notes and additional information in a documentation page, use Admonitions. Make sure the type of admonition used matches the note’s importance to the current document.

Need Additional Help

If you need any additional help while contributing, you can join our Discord and ask erxes core team as well as the community any questions.

Documentation style guide

You can write content using GitHub-flavored Markdown syntax.

Markdown Syntax

To serve as an example page when styling markdown based Docusaurus sites.

Headers

H1 - Create the best documentation

H2 - Create the best documentation

H3 - Create the best documentation

H4 - Create the best documentation

H5 - Create the best documentation

H6 - Create the best documentation

Emphasis

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this.

Lists

1. First ordered list item
2. Another item ⋅⋅* Unordered sub-list.
3. Actual numbers don't matter, just that it's a number ⋅⋅1. Ordered sub-list
4. And another item.

⋅⋅⋅You can have properly indented paragraphs within list items. Notice the blank line above, and the leading spaces (at least one, but we'll use three here to also align the raw Markdown).

⋅⋅⋅To have a line break without a paragraph, you will need to use two trailing spaces.⋅⋅ ⋅⋅⋅Note that this line is separate, but within the same paragraph.⋅⋅ ⋅⋅⋅(This is contrary to the typical GFM line break behaviour, where trailing spaces are not required.)

• Unordered list can use asterisks
• Or minuses
• Or pluses

Links

I'm an inline-style link

I'm an inline-style link with title

I'm a reference-style link

I'm a relative reference to a repository file

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com or http://www.example.com and sometimes example.com (but not on Github, for example).

Some text to show that the reference links can follow later.

Images

Here's our logo (hover to see the title text):

Inline-style:

Reference-style:

Code

var s = 'JavaScript syntax highlighting';
alert(s);)

s = "Python syntax highlighting"
print(s)

No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.

function highlightMe() {
  console.log('This line can be highlighted!');
}

Tables

Colons can be used to align columns.

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.

Blockquotes

Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.

Quote break.

This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.

Inline HTML

Definition list Is something people use sometimes. Markdown in HTML Does * not * work ** very ** well.Use HTML tags.

Line Breaks

Here's a line for us to start with.

This line is separated from the one above by two newlines, so it will be a separate paragraph.

This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.

Admonitions