Contributing

Contribution guidelines. Please read before raising issues or creating pull requests.

Getting started

Before you begin:

• This library is powered by Node.js v14

• Check out the existing issues & see if we accept contributions for your type of issue.

Navigating a new codebase can be challenging, so we're making that a little easier. you may come across a piece of code that you want to make an update to but before you make your changes, check to see if an issue exists for the change you want to make.

Don't see your issue? Open one

If you spot something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix. Please use the template provided at [click me] to open your issue.

pageIssue Template

Ready to make a change? Fork the repo

Fork using GitHub Desktop:

• Getting started with GitHub Desktop will guide you through setting up Desktop.

• Once Desktop is set up, you can use it to fork the repo!

Fork using the command line:

• Fork the repo so that you can make your changes without affecting the original project until you're ready to merge them.

Fork with GitHub Codespaces:

• Fork, edit, and preview using GitHub Codespaces without having to install and run the project locally.

Make your update:

Make your changes to the file(s) you'd like to update. Here are some tips and tricks for using the docs codebase.

• Are you making changes to the application code? You'll need Node.js v14 to build the library locally.

Open a pull request

When you're done making changes and you'd like to propose them for review, use the pull request template at [click me] to open your PR (pull request).

pagePull Request Template

Submit your PR & get it reviewed

• Once you submit your PR, others from the Docs community will review it with you. The first thing you're going to want to do is a self review.

• After that, we may have questions, check back on your PR to keep up with the conversation.

• Did you have an issue, like a merge conflict? Check out our git tutorial on how to resolve merge conflicts and other issues.

Your PR is merged!

Congratulations! The whole LottieFiles community thanks you. ✨

Once your PR is merged, you will be proudly listed as a contributor in the contributor chart.

Keep contributing as you use Lottie Js

Now that you're a part of the LottieFiles community, you can keep participating in many ways.

Types of contributions 📝

You can contribute to the LottieFiles in several ways. This repo is a place to discuss and collaborate on the Lottie JS Object model! Our small, but mighty 💪 OSS team is maintaining this repo, to preserve our bandwidth, off topic conversations will be closed.

🐞 Issues

Issues are used to track tasks that contributors can help with. If an issue has a triage label, we haven't reviewed it yet and you shouldn't begin work on it.

If you've found something in the content or the website that should be updated, search open issues to see if someone else has reported the same thing. If it's something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix.

🛠️ Pull requests

A pull request is a way to suggest changes in our repository.

When we merge those changes, they should be deployed to the live site within 24 hours. 🌍 To learn more about opening a pull request in this repo, see Opening a pull request below.

❓ Support

We are a small team working hard to keep up with the documentation demands of a continuously changing product. Unfortunately, we just can't help with support questions in this repository. If you are experiencing a problem with a Lottie or LottieFiles, unrelated to our documentation, please contact LottieFiles Support directly. Any issues, discussions, or pull requests opened here requesting support will be given information about how to contact LottieFiles Support, then closed and locked.

Starting with an issue

You can browse existing issues to find something that needs help!

Labels

Labels can help you find an issue you'd like to help with.

• The help wanted label is for problems or updates that anyone in the community can start working on.

• The good first issue label is for problems or updates we think are ideal for beginners.

• The content label is for problems or updates in the content on docs.github.com. These will usually require some knowledge of Markdown.

• The engineering label is for problems or updates in the docs.github.com website. These will usually require some knowledge of JavaScript/Node.js or YAML to fix.

Opening a pull request

You can use the GitHub user interface ✏️ for some small changes, like fixing a typo or updating a readme. You can also fork the repo and then clone it locally, to view changes and run your tests on your machine.

Working in the LottieFiles/lottie-js repository

Here's some information that might be helpful while working on a Docs PR:

• Bundling - Rollup is used to bundle the code and compile it into a module

• Commit Linting - It is advisable to use a tool like commitizen to create commits

Reviewing

We (usually the OSS team, but sometimes engineering leads and support staff!) review every single PR. The purpose of reviews is to create the best we can for people who use the library.

💛 Reviews are always respectful, acknowledging that everyone did the best possible job with the knowledge they had at the time. 💛 Reviews discuss code and functionality, not the person who created it. 💛 Reviews are constructive and start conversations around feedback.

Self review

You should always review your own PR first.

For content changes, make sure that you:

• Confirm that the changes address every part of the issue (if there are differences, explain them).

• Review the content for technical accuracy.

• Copy-edit the changes for grammar, spelling, and adherence to the style guide.

• Check new or updated Liquid statements to confirm that versioning is correct.

• Check that all of your changes render correctly in staging. Remember, that lists and tables can be tricky.

• If there are any failing checks in your PR, troubleshoot them until they're all passing.

Pull request template

When you open a pull request, you must fill out the Pull Request Template before we can review your PR. This template helps reviewers understand your changes and the purpose of your pull request.

Suggested changes

We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.

As you update your PR and apply changes, mark each conversation as resolved.