adoption_request.md

name	about	title	labels	assignees
Adoption Request	Submit your feature to the project	Adoption Request	adoption

Adoption Request

Thank you for wanting to contribute to the project! We are very happy to see the functionalities of the EDC being extended. Providing this open-source is a great opportunity for others with similar requirements and to avoid additional work.

For any details about the guidelines for submitting features, please take a look at the contribution categories.

General information

Please provide some information about your project or code contribution.

If you choose to be referenced as a "friend", these will be added to the known friends list. If you choose to add your feature as a core EDC component, links to your current code and correlated issues, discussions, and pull requests are of great importance.

Title	Description	Contact	Links
My awesome project	This is an example.	e-mail-address	link to repository, homepage, discussion, etc.

Adoption level

Next, please tell us what level of adoption you intend to provide. (pick only one)

• Reference a feature as "friend"
• Incorporate a feature as core EDC component

Adoption in EDC core

If you chose to add your feature as a core EDC component, please answer the following questions.

Why should this contribution be adopted?

Please argue why this feature must be hosted upstream and be maintained by the EDC core team.

Could it be achieved with existing functionality? If not, why?

If there is any existing code that can achieve the same thing with little modification, that is usually the preferable way for the EDC core team. We aim to keep the code succinct and want to avoid similar/duplicate code. Make sure you understand the EDC code base well!

Are there multiple use cases or applications who will benefit from the contribution?

Basically, we want you to motivate who will use that feature and why, thereby arguing the fact that it is well-suited to be adopted in the core code base. One-off features are better suited to be maintained externally.

Can it be achieved without introducing third-party dependencies? If not, which ones?

EDC is a platform rather than an application, therefore we are extremely careful when it comes to introducing third party libraries. The reasons are diverse: security, license issues and over all JAR weight, just to mention a few important ones.

Would this feature limit platform independence in any way? If so, how and why?

Features that do not work well in clustered environments are difficult to adopt, since EDC is designed from the ground up to be stateless and clusterable. Similarly, features, that have dependencies onto certain operating systems are difficult to argue.

Is it going to be a self-contained feature, or would it cut across the entire code base?

Features that have a large impact on the code base are very complex to thoroughly test, they have a high chance to destabilize the code and require careful inspection. Self-contained features on the other hand are easier to isolate and test.