Skip to content

Latest commit

 

History

History
81 lines (61 loc) · 3 KB

CONTRIBUTING.md

File metadata and controls

81 lines (61 loc) · 3 KB

Contributing to Eclipse Jifa

Thanks for your interest in this project.

Here is a (non-exclusive, non-prioritized) list of things you might be able to help us with:

  • bug reports
  • bug fixes
  • improvements regarding code quality e.g. improving readability, performance, modularity etc.
  • documentation (Getting Started guide, Examples etc)
  • features (both ideas and code are welcome)
  • test cases

In order to get you started as fast as possible we need to go through some organizational issues first, though.

Eclipse Contributor Agreement

Before your contribution can be accepted by the project team contributors must electronically sign the Eclipse Contributor Agreement (ECA).

Commits that are provided by non-committers must have a Signed-off-by field in the footer indicating that the author is aware of the terms by which the contribution has been provided to the project. The non-committer must additionally have an Eclipse Foundation account and must have a signed Eclipse Contributor Agreement (ECA) on file.

For more information, please see the Eclipse Committer Handbook: https://www.eclipse.org/projects/handbook/#resources-commit

License Header

Please make sure any file you newly create contains a proper license header like this:

/********************************************************************************
 * Copyright (c) 2020 Contributors to the Eclipse Foundation
 *
 * See the NOTICE file(s) distributed with this work for additional
 * information regarding copyright ownership.
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0
 *
 * SPDX-License-Identifier: EPL-2.0
 ********************************************************************************/

Making your Changes

  1. Fork the repository on GitHub
  2. Create a new branch for your changes
  3. Make your changes
  4. Make sure you include test cases for non-trivial features/changes
  5. Make sure the test suite runs successfully after you made your changes
  6. Commit your changes into the branch you created in step 2
  7. Use descriptive and meaningful commit messages
  8. If you have a lot of commits squash them into a single commit
  9. Make sure you use the -s flag when committing as explained above
  10. Push your changes to your branch in your forked repository

Submitting the Changes

Submit a pull request via the normal GitHub UI.

After Submitting

  • Do not use your branch for any other development, otherwise further changes that you make will be visible in the PR.