Skip to content

Latest commit

 

History

History
199 lines (137 loc) · 13.4 KB

contributing-guidelines.md

File metadata and controls

199 lines (137 loc) · 13.4 KB
Raw

Contributing Guidelines

Legesher's Contributing Guideline👐

First off, thank you for just being here.

It's people like you who have a heart❤️ to serve and desire to create something bigger than themselves that we want to be part of our team. So thank you, because by choosing to contribute to Legesher we're one step closer to creating a world where innovation, creativity and collaboration aren't lost in translation. This is so much more than a product, it's an opportunity that opens doors. Thank YOU for making all of this possible.

Here's a high level overview of what this guide entails. It is designed to be read and revisited as you become more involved with the project.

Our Reason Why🔑

We all have the same goal:

Programming with Legesher's dev tools empowers any developer to create without losing the art of innovation💡, creativity🎨, or collaboration🤝 in translation.

To learn why Madi created this project, more information can be found here.

You Can Be A Part🤝

This is a space for you to share your talents, gifts, and abilities to serve one another. There are many ways to contribute (even if you don't know how to code - yet)! From writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests, translating to another language or writing code, we would love to have you share your God-given abilities with us!

Legesher Resources📚

Here are some important and helpful resources for Legesher:

Contribute on Github Watch on Twitch chat on Discord follow on Instagram follow on Twitter Read on Medium Subscribe on Mailchimp

Contributing📖

There are many ways for you to get involved in Legesher. One of the biggest misconceptions I want to clarify before going forward, is that you can contribute even if you do not code. Following these guidelines will help to get the best product in the hands of the people that need it most. In respecting the time of the developers managing and developing this open source project, your issues will be addressed, changes assessed, and pull requests finalized with our help.

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

Ground Rules🎋

When contributing it is important to make sure we follow the same guidelines:

  • Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. (Read More)
  • Ensure cross-platform compatibility for every change that's accepted. (Windows, Mac, Debian & Ubuntu Linux)
  • Ensure that code that goes into core meets all requirements in this checklist
  • Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
  • Don't add any classes to the codebase unless absolutely needed. Err on the side of using functions.
  • Keep feature versions as small as possible, preferably one new feature per version.
  • Cover features with tests, examples and documentation.

My First Contribution➕

Contributing to an open source project can be very intimidating and overwhelming, but we've tried to make your first contribution as easy as possible. On top of sharing your gifts with the community that needs it, upon merging your first contribution, you'll get a free starter pack and a big welcome into the community!

One great way to begin contributing is to look for one of the following issues labels:

  • Technical Experience: None
  • Technical Experience: Beginner
  • up-for-grabs
  • first-timers-only
  • help wanted
  • good first issue

If you've never contributed to an open source project before Here are a couple of friendly tutorials that may help:

Review Process💚

Program Enhancements✅

TESTS
If you are changing the code base of the project, you will need to perform the provided tests before your changes can be merged. If you add new features to the project, please include tests with your pull request.

To run the tests, run the following command (or make sure to add this as a testing script):

DOCUMENTATION
The more documentation we have the easier it will be for our project to be used. Documentation will change constantly, as we improve the way the product works and we gain better ways of explaining.

TUTORIALS
If there was anything you do not currently understand or did not while going through the current tutorials, please update them to improve their usefulness. This is for the betterment of our community, we all thank you for it!

For updates larger than a one or two line fix: 1. Create your own fork of the code 2. Do the changes in your fork 3. If you like the change and think the project could use it:

  • Be sure you have followed the code style for the project.
  • Note the Legesher Code of Conduct.
  • Send a pull request and be open for feedback.
  • The pull request will need to be reviewed by at least one member of the maintainer community before it can be merged into the project.

Language Translations📢

  • A language is first introduced when an individual raises their hand to add in their dialect.
  • After the initial translation is added, the translated file will need to be reviewed by at least 3 different community members to make sure it is appropriate and the best translation that will allow the developer to best understand the foundation of programming. (additional reviewers are highly encouraged)
  • After 3 approved reviews, all 4(or more) contributors will be given credit for the addition of the language when it is merged with the project.

Style Guide🎨

Commit Message Guidelines📝

A good commit message should describe what changed and why. This project uses semantic commit messages to streamline the release process.

Semantic Prefixes: Before a pull request can be merged, it must have a pull request title with a semantic prefix.

Examples of commit messages with semantic prefixes:

  • fix: don't overwrite prevent_default if default wasn't prevented
  • feat: add app.isPackaged() method
  • docs: app.isDefaultProtocolClient is now available on Linux

Common prefixes:

  • fix: A bug fix
  • feat: A new feature
  • docs: Documentation changes
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system
  • ci: Changes to our Continuous Integration configuration files and scripts
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (linting)
  • vendor: Bumping a dependency like node

Other things to keep in mind when writing a commit message:

  1. The first line should:
  • Contain a short description of the change (preferably 50 characters or less, and no more than 72 characters)
  • Be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like function/variable names
  1. Keep the second line blank.
  2. Wrap all other lines at 72 columns.
  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • When only changing documentation, include [ci skip] in the commit title
  • Consider starting the commit message with an applicable emoji:
    • 🎨 :art: when improving the format/structure of the code
    • 🐎 :racehorse: when improving performance
    • 🚱 :non-potable_water: when plugging memory leaks
    • 📝 :memo: when writing docs
    • 🐧 :penguin: when fixing something on Linux
    • 🍎 :apple: when fixing something on macOS
    • 🏁 :checkered_flag: when fixing something on Windows
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when removing code or files
    • 💚 :green_heart: when fixing the CI build
    • ✅ :white_check_mark: when adding tests
    • 🔒 :lock: when dealing with security
    • ⬆️ :arrow_up: when upgrading dependencies
    • ⬇️ :arrow_down: when downgrading dependencies
    • 👕 :shirt: when removing linter warnings

Breaking Changes: A commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with Major in semantic versioning). A breaking change can be part of commits of any type. e.g., a fix:, feat: & chore: types would all be valid, in addition to any other type.

See conventionalcommits.org for more details.

Submitting Issues⚠️

Bug Reports🐛

When reporting a bug, answer the questions in the issue templates in each repository.

Feature or Enhancement Suggestions🚀

When suggesting a feature or enhancement, answer the questions in the issue templates in each repository.

Security Reports🚓

If you find a security vulnerability, do NOT open an issue. Email [email protected] instead. In order to determine whether you are dealing with a security issue, ask yourself these two questions:

  • Can I access something that's not mine, or something I shouldn't have access to?
  • Can I disable something for other people?

If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [email protected].