Skip to content

Latest commit

 

History

History
112 lines (69 loc) · 5.68 KB

CONTRIBUTING.adoc

File metadata and controls

112 lines (69 loc) · 5.68 KB
Raw

Contributing to Eclipse uProtocol

Thanks for your interest in this project. Contributions are welcome!

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF BCP14 (RFC2119 & RFC8174)

Developer Resources

Best information about the project:

We use the Eclipse-SDV Slack workspace for day-2-day discussions in the developer community. Sign up is easy by clicking here. Once you’re in the workspace, the channels you’ll want to subscribe to are #uprotocol to start.

We hold a weekly sync up meeting every Thursday at 2pm CET (8AM EST), zoom details are below:

Join Zoom Meeting https://eclipse.zoom.us/j/87919934501?pwd=7CI4VuAIRNq4pstQbFtHhb8mM0XwQR.1 Meeting ID: 879 1993 4501 Passcode: 640538

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

Best Current Practices (BCPs)

The following section will elaborate on the best practices we (the contributor community) will apply to each repositories in the Eclipse-uProtocol project.

  • Projects that are intended to be used in production MUST adhere to BCPs listed below.

If the project is not intended to be used for production:

  • MUST clearly labeled in your repos README.adoc as NOT INTENDED FOR PRODUCTION USE

Code Contributions

Contribution pull requests MUST contain the following:

  • Commit Description: Properly formatted subject for the commit including a detailed description of the change. the subject line is pulled into the automatic release generation

  • GitHub Issue: Commits for adding new features/functions SHOULD have an associated github issue

  • Documentation: Interfaces must be properly documented with functional hyperlinks

  • Test Coverage: Code MUST have associated test coverage

Repositories

The following are BCPs for newly created repositories under the Eclipse-uProtocol project:

  • GitHub actions MUST be used to create CI/CD workflows for validating build, test, and documentation for every pull request for main branch

  • "Branch Protection Rules" MUST be enabled with the minimal settings below (replace verify-pr for the target that runs the build, test, and documentation workflows):

branch_protection_rules: [
        orgs.newBranchProtectionRule('main') {
          required_approving_review_count: 1,
          required_status_checks+: [
            "verify-pr"
          ],
        },
      ],

  • Release MUST follow http://semver.org requirements and begin with v0.1.0-dev. Each subsequent release will have the MAJOR, MINOR, and PATCH number incremented following semver requirements

  • Initial commit MUST include the following legal documents:

  • SHOULD NOT contain CONTRIBUTORS.adoc as the information can be fetched from the git history

If NOTICE information cannot be autogenerated: * MUST include NOTICE.adoc

Why Apache 2.0 and not MIT or BSD?

The Apache 2.0 License and the MIT License are both popular open-source licenses, but they have some differences in terms of their requirements and provisions. Here are the key distinctions:

  • Scope: The Apache 2.0 License is more comprehensive and covers patents, trademarks, and attribution requirements, while the MIT License is simpler and primarily focuses on copyright.

  • Patent Grant: The Apache 2.0 License includes a patent grant, which means that it provides explicit permission for users to use any patents held by the licensor. The MIT License does not include a specific patent grant.

  • Redistribution: Both licenses allow for the redistribution of the software, but the Apache 2.0 License includes specific requirements for preserving notices, disclaimers, and license terms in derivative works.

  • Copyleft: The MIT License is considered a permissive license, allowing for more flexibility in how the software is used and integrated into other projects. The Apache 2.0 License has some copyleft provisions, requiring modifications and derivative works to be licensed under the same license.

  • Compatibility: Both licenses are generally considered compatible with other open-source licenses. However, the Apache 2.0 License is more explicitly compatible with the GNU General Public License (GPL) version 3, while the MIT License is compatible with a wider range of licenses.

Contact

Contact the project developers via the project’s "dev" list or on slack.