Skip to content

Latest commit

 

History

History
163 lines (124 loc) · 12.1 KB

CONTRIBUTING.md

File metadata and controls

163 lines (124 loc) · 12.1 KB
Raw

HELLO!! WELCOME TO CONTRIBUTING TO SCRIVENER :)

Thanks for being here and taking your time to contribute.

The following is a set of guidelines for contributing to "SCRIVENER" and its packages, which are hosted in the Scrivener on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table of Contents

Code of Conduct
How can I Contribute
Suggesting Enhancements
Style Guide
References

Code of Conduct

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].

How can I Contribute

Reporting Bugs

This section gives detailed information on how to report bugs. Reporting a bug will help the community and maintainers of the repository.
Before reporting any bug, make sure it is correct and you have all the details with you. Fot creating any bug report, please fill out the required template. This template will give us necessary information to help solve a bug faster.

Before Submitting A Bug Report

The following is a list of items you need to check before submitting a bug report.

debugging guide. Check out this debugging guide, which helps you to find the cause of the problem and you may fix it by yourself manually.
cursory search A cursory search is necessary to check if the reported bug is already mentioned before or not. You can add to the existing bug report if the issue is still open.

To Submit A Good Bug Report

GitHub issues You can track the bugs from this. For the repository that has bug, create an issue and fill out the template to give details of the bug.

  • To identify the problem, give the issue a clear and informative term.
  • Describe in as much detail as possible to duplicate the problem. Explain the problem and explain about the exact command sused in the terminal which caus ethe bug to occur.
  • To demonstrate the steps, give specific examples. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
  • Specify what is the problem beavior and what you expected to see and why
  • If possible, include screenshots and animated GIFs that clearly demonstrate the problem. this tool- to record GIFs on macOS and Windows, and this tool or this tool on Linux.
  • To include a crash report, add a stack trace from the operating system. For macOS, Console.app under "Diagnostic and usage information" > "User diagnostic reports" has crash report. Include the crash report in the issue in a code block, a file attachment, or put it in a gist and provide link to that gist.
  • For performance or memory issues, include a CPU profile capture with your report.

Provide more context by answering these questions:

  • If the problem started happening recently then try downloading the old version of the packages and the code.
  • Include details about your configuration and environment.
  • What is the name and version of the OS you're using?
  • Are you running the project in a virtual environment?
  • Which packages have installed in your system? You can get a list of packages installed by running 'apm list --installed'

Suggesting Enhancements

Any suggesting enhancements like adding new features or imporving existing functionalities, etc can done by following the below guidelines. They help maintainers understand your improvement.
the template- this template is to be filled to add suggestions. These can include the steps that you imagine you would take if the feature you're requesting existed.

Before Submitting An Enhancement Suggestion

debugging guide. Check out this debugging guide, which helps you to find the cause of the problem and you may fix it by yourself manually.
cursory search A cursory search is necessary to check if the reported bug is already mentioned before or not. You can add to the existing bug report if the issue is still open.

To Submit A Good Enhancement Suggestion

GitHub issues You can track the bugs from this. For the repository that has bug, create an issue and fill out the template to give details of the bug.

  • To identify the problem, give the issue a clear and informative term.
  • Describe in as much detail as possible to duplicate the problem. Explain the problem and explain about the exact command sused in the terminal which caus ethe bug to occur.
  • To demonstrate the steps, give specific examples. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
  • Specify what is the problem beavior and what you expected to see and why
  • If possible, include screenshots and animated GIFs that clearly demonstrate the problem. this tool- to record GIFs on macOS and Windows, and this tool or this tool on Linux.
  • To include a crash report, add a stack trace from the operating system. For macOS, Console.app under "Diagnostic and usage information" > "User diagnostic reports" has crash report. Include the crash report in the issue in a code block, a file attachment, or put it in a gist and provide link to that gist.
  • For performance or memory issues, include a CPU profile capture with your report.

Start Your Contribution

beginner and help-wanted issues can help you getting started to contribute your first contribution:

  • [Beginner issues][beginner] - issues which should only require a few lines of code, and a test or two.
  • [Help wanted issues][help-wanted] - issues which should be a bit more involved than beginner issues.

Local development

For developing the project, each section is done locally.

Pull Requests

The goals to be considered are:

  • Focus of problems that are more valuable to users of the platform
  • Engage the community in working toward the best possible solution
  • To review contributions, enable a sustainable system for the maintainers

Please follow these steps to have your contribution considered by the maintainers:

  1. Follow the styleguides
  2. Verify that all status checks are passing once the pull request is submitted.
    What if the status checks are failing?If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.

While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.

Styleguides

Git Commit Messages

  • 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

CoffeeScript Styleguide

  • Set parameter defaults without spaces around the equal sign
    • clear = (count=1) -> instead of clear = (count = 1) ->
  • Use spaces around operators
    • count + 1 instead of count+1
  • Use spaces after commas (unless separated by newlines)
  • Use parentheses if it improves code clarity.
  • Prefer alphabetic keywords to symbolic keywords:
    • a is b instead of a == b
  • Avoid spaces inside the curly-braces of hash literals:
    • {a: 1, b: 2} instead of { a: 1, b: 2 }
  • Include a single line of whitespace between methods.
  • Capitalize initialisms and acronyms in names, except for the first word, which should be lower-case:
    • getURI instead of getUri
    • uriToOpen instead of URIToOpen
  • Use slice() to copy an array
  • Add an explicit return when your function ends with a for/while loop and you don't want it to return a collected array.
  • Use this instead of a standalone @
    • return this instead of return @
  • Place requires in the following order:
    • Built in Node Modules (such as path)
    • Local Modules (using relative paths)
  • Place class properties in the following order:
    • Class methods and properties (methods starting with a @)
    • Instance methods and properties

Documentation Styleguide

  • Use Markdown.
  • Reference methods and classes in markdown with the custom {} notation:
    • Reference classes with {ClassName}
    • Reference instance methods with {ClassName::methodName}
    • Reference class methods with {ClassName.methodName}

References

Contributing.md