For Contributors

Learn how to work with repositories and projects with developers from the Neurosell team and community

Contributor Covenant Code of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, 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 <%= ask("author.email", "Email address?") %>. 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.

---

Forks and Development Guides

Our development flow

We stick to a fairly simple and easy to understand floo work, which we've outlined for you below:

• Initially, work is done in the develop branch for small updates, or separate branches for work on large features;

• Then a pull-request is made to the test branch for large changes, or to main for small changes;

• Each pull-request must go through code-review and internal testing before publishing to main;

• Test branches are merged into main only after QA review, and main is turned into a release only after QA.

Our products lifetime workflow

Work with specific products versions

In order to work with a specific version of any products and not be distracted by updates, we recommend grabbing the latest version from the main branch from our official products repository by making a fork. Later, you can update any product version by pushing the latest changes into your fork from our repository using the commands:

# Add the remote, call it "upstream":
git remote add upstream https://github.com/Neurosell/[REPO_LINK].git

# Fetch all the branches of that remote into remote-tracking branches
git fetch upstream

# Make sure that you're on your main branch:
git checkout main

# Rewrite your main branch so that any commits of yours that
# aren't already in upstream/main are replayed on top of that
# other branch:
git rebase upstream/main

Deployment and CI/CD

We recommend doing deploy applications from your Git repository where you host fork systems. The entire system is already ready to run in application containers and you won't lose content or any other changes when upgrading.

Prerequisites for working in containers:

1. Do not save changes to the filesystem, as upgrading from git container will erase those changes. Use download to S3, or to databases (the extension system downloads the required version of the extension again when updating the application in the container and repackages it);

2. Store configurations in a container environment variable, or in a database. Or upload an .env file to your repository.

---

And if you want to become one of the developers contributing to the platform, check out our GitHub guidelines for collaborators:

• Use only pull-request to develop / custom feature branches, not in main;

• Please, describe detailed any commit and pull-request;

• Please, create issue for any updates;