Contribution Guidelines

Thank you for your interest in the EDC! This document provides guidelines and steps members are asked to follow when contributing to the project.

Table of Contents

Code Of Conduct

All community members are expected to adhere to the Eclipse Code of Conduct.

How to Contribute

If you want to share a feature idea or discuss a potential use case, first check the existing issues and discussions to see if it has already been raised. If not, open a discussion (not an issue).

Creating an Issue

If you have identified a bug first check the existing issues to see if it has already been identified. If not, create a new issue in the appropriate GitHub repository. Keep in mind the following:

  • We use GitHub’s default label set extended by custom ones to classify issues and improve findability.
  • If an issue appears to cover changes that will significantly impact the codebase, open a discussion before creating an issue.
  • If an issue covers a topic or the response to a question that may be interesting for further discussion, it should be converted to a discussion instead of being closed.

Submitting a Pull Request

Before submitting code to EDC, you should complete the following prerequisites:

Eclipse Contributor Agreement

Before your contribution can be accepted by the project, you need to create and electronically sign an Eclipse Contributor Agreement (ECA):

  1. Log in to the Eclipse foundation website. You will need to create an account within the Eclipse Foundation if you have not already done so.
  2. Click on “Eclipse ECA”, and complete the form.

Be sure to use the same email address in your Eclipse Account that you intend to use when committing to GitHub.

Stale Issues and PRs

In order to keep our backlog clean, EDC uses a bot that labels and closes old issues and PRs. The following table outlines this process:

Stale AfterClosed After Stale
Issue without assignee14 days7 days
Issue with assignee28 days7 days
PR7 days7 days

Note that updating an issue, for example by commenting, will remove the stale label and reset the counters. However, we ask the community not to abuse this feature (e.g., periodically commenting “what’s the status?” would qualify as abuse). If an issue receives no attention, usually there are reasons for it. To avoid closed issues, it’s recommended to clarify in advance whether a feature fits into the project roadmap by opening a discussion, which are not automatically closed.

Reporting Flaky Tests

If you discover a randomly failing (“flaky”) test, please check whether an issue for that already exists. If not, create one, making sure to provide a meaningful description and a link to the failing run. Also include the Bug and FlakyTest labels and assign it to an author of the relevant code. If assigning the issue is not possible due to missing rights, just comment and @mention the author/last editor.

Be sure not restart the run, as this will overwrite the results. Instead, push an empty commit to trigger another run.

git commit --allow-empty -m "trigger CI" && git push

Note that issues labeled with Bug and FlakyTest are prioritized.

Non-Code Contributions

Non-code contributions are another valued way to contribute. Examples include:

  • Evangelizing EDC
    • Helping to develop the community by hosting events, meetups, summits, and hackathons
  • Community education
    • Answering questions on GitHub, Discord, etc.
    • Writing documentation
    • Other writing (Blogs, Articles, Interviews)

Project and Milestone Planning

We use milestones to set a common focus for a period of 6 to 8 weeks. The group of committers chooses issues based on customer needs and contributions we expect.

Milestones

Milestones are organized at the GitHub Milestones page. They are numbered in ascending order. There, contributors, users, and adopters can track the progress.

Please note that the due date of a milestone does not imply any guarantee that all linked issued will be resolved by then.

When closing the current milestone, issues that were not resolved within a milestone phase will be reviewed to evaluate their relevance and priority, before being assigned to the next milestone.

Issues

Every issue that should be addressed during a milestone phase is assigned to it by using the Milestone feature for linking both items. This way, the issues can easily be filtered by milestones.

Pull Requests

Pull requests are not assigned to milestones as their linking to issues is sufficient to track the relations and progresses.

Projects

The GitHub Projects page provides a general overview of the project’s working items. Every new issue is automatically assigned to the “Dataspace Connector” project. It can be unassigned or moved to any other project that is provided.

In every project, an issue passes four stages: Backlog, In progress, Review in progress, and Done, independent of their association to a specific milestone.

Releases

Please find more information about our release approach here.

Contact Us

If you have questions or suggestions, do not hesitate to contact the project developers via the project’s “dev” list. You may also want to join our Discord server.

The project holds a biweekly meeting on fridays 2-3 p.m. (CET) to give community members the opportunity to get in touch with the committer team. We meet in the “general” voice channel. Schedule details are on GitHub.

If you have a “contributor” or “committer” status, you will also have access to private channels.