Collaborative DHS Suite Roadmap #
DHS#4 #
- Finalization of the Collaborative IAM prototype
- DHS Suite Software and Collaborative IAM Engagment: Integration Testing Phase
- Collaborative Website Development
- Transformation Framework: Resource consumption calculation for processing tasks
- COPSI: Graphical User Interface for displaying list of products present in GSS-Catalogue on a world map (2D and 3D) with footprint visualization
- Semantic Framework: Integration with Keycloak
- GSS: Initial prototype for a data retrieval and distribution solution allowing integration of the Collaborative ESA Nodes for data retrieval purpose
- Security: Definition and application of Security checks for dependencies
DHS#5 #
- DHS Suite Software and Collaborative IAM Engagment: Integration Testing Phase
- Collaborative Website launch
- Transformation Framework: New CSC OData API Interface support
- GSS: Improvements, GDPR compliance introduction, configuration via Admin-API, integration of CDSE Data Source for data retrieval purpose
- COPSI: Advanced Search, Geographical Search and Edit Profile implementation
- Automatic DHS Suite installation: “All-in-one” deployment solution
- Security: Definition and application of Security checks for Broken Access Control
DHS#6 #
- Transformation Framework: Integration of EOPF module for product format transformation
- GSS: Deletion, subscription and notification functions
- COPSI: Advanced Search and footprint selection improvement and multiple detail panels
- Automatic DHS Suite installation: “Distributed Services” deployment solution
- Security: Definition and application of Security checks for Cryptographic Failures
- Semantic Framework: NLP functionality for semantic searches and improvement of the output results in order to provide information useful for interferometry
Governance Model for Software contribution #
User Taxonomy #
Here below the users taxonomy in the frame of the Contributing process.
- Users = People who use the software but aren’t submitting code, documentation or performing issue triage. They may add value to the project raising issues, commenting on an issue or pull request.
- Contributors = People who are submitting code or documentation (i.e. as a pull request on GitHub) but need someone to give them code review and merge their contribution. They do not have commit access to merge their own changes.
- Maintainers = People who review and merge contributors from contributors and generally run the project. They have commit access.
- Service Board (Council) = Group composed by Service Manager, ESA Technical Officer, Maintenance Manager and Maintainers. DHR users can apply to join the Service Board. The main tasks of this group are:
- setting overall technical direction for the project (high-level goals and low-level specifics regarding features and functionality).
- setting and maintaining standards covering contributions of code, documentation and other materials.
- approval of contributions coming from contributors users (Collaborative/OpenSource users).
- making decisions regarding the Collaborative DHS Service.
Contributing governance structure #
Open-Source Framework contributing governance can be split according to the involved entities, and it is organized into tasks within the pre and post stages, as follows hereafter.
- Pre-phase:
- Open-source framework repository organization
- Verification of compliance
- Developer’s guidelines
- Software contribution development
- Onboarding
- Registration/access
- Roles association
- Post-phase:
- Contribution approval
- Contribution merge in repository
- Notification to Contributor
Pre-phase #
In the frame of the pre-phase the pre-requisites for contributing are set up.
Individual access to GitHub #
The access on GitHub is needed to explore all the software repositories maintained in the frame of Collaborative DHS software. The Collaborative/OpenSource user can access to GitHub with its individual account credentials before a proper registration on GitHub system.
GitHub repository inspection #
Collaborative DHS software repositories are Public and organized in GitHub Organizations, making it easier to work with external collaborators. The Collaborative/OpenSource user can navigate through the repositories identifying the suitable one where to participate with its contribution.
The list of repositories maintained in the frame of Collaborative DHS Service are the ones listed in the following table. All repositories are licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).
| Software Area | GitHub Organization Name | GitHub Repository name | GitHub Repository link |
|---|---|---|---|
| DHuS | SentinelDataHub | dhus-distribution | https://github.com/SentinelDataHub/dhus-distribution |
| DAFNE | DHS-DataflowNetworkEnvironment | DAFNE-Deployment DAFNE-Front-End DAFNE-Back-End | https://github.com/DHS-DataflowNetworkEnvironment/DAFNE-Deployment https://github.com/DHS-DataflowNetworkEnvironment/DAFNE-Front-End https://github.com/DHS-DataflowNetworkEnvironment/DAFNE-Back-End |
| Transformation Framework | DHS-TransformationFramework | esa_tf | https://github.com/DHS-TransformationFramework/esa_tf |
| Semantic Framework | DHS-SemanticFramework | SemanticFramework SF-DataReceiver SF-NaturalLanguage | https://github.com/DHS-SemanticFramework/SemanticFramework https://github.com/DHS-SemanticFramework/SF-DataReceiver https://github.com/DHS-SemanticFramework/SF-Natural-Language |
| GSS | gss GaelSystems | cdh-compose cdh-toolbox cdh-ingest cdh-catalogue cdh-admin-api cdh-notification cdh-distribution | https://repository.gael-systems.com/repository/thirdparty/fr/gael/gss/cdh-compose/<VERSION>/cdh-compose-<VERSION> https://repository.gael-systems.com/repository/thirdparty/fr/gael/gss/cdh-toolbox/<VERSION>/cdh-toolbox-<VERSION> https://repository.gael-systems.com/repository/thirdparty/fr/gael/gss/cdh-ingest/<VERSION>/cdh-ingest-<VERSION> https://repository.gael-systems.com/repository/thirdparty/fr/gael/gss/cdh-catalogue/<VERSION>/cdh-catalogue-<VERSION> https://repository.gael-systems.com/repository/thirdparty/fr/gael/gss/cdh-admin-api/<VERSION>/cdh-admin-api-<VERSION> https://repository.gael-systems.com/repository/thirdparty/fr/gael/gss/cdh-notification/<VERSION>/cdh-notification-<VERSION> https://gitlab.com/GaelSystems/cdh-distribution/-/tree/<VERSION> |
| COPSI | DHS-CopernicusSpaceInterface | COPSI COPSI-Deployment | https://github.com/DHS-CopernicusSpaceInterface/COPSI https://github.com/DHS-CopernicusSpaceInterface/COPSI-Deployment |
| DHS Suite Easy Deploy | DHS-Components | dhs-suite-easy-deploy | https://github.com/DHS-Components/dhs-suite-easy-deploy |
Roles and Responsibilities identification #
The goal of this task is to define user roles and responsibilities in the Collaborative DHS Open-Source Framework contributing process, by looking at how users are interacting with the project. There are different ways to participate in the OSF project and community, and not all of them involve contributing source code to the project. Simply participating filing bug reports or enhancement requests is a valuable form of participation.
Developers’ guidelines adoption #
Contributors can participate to the Collaborative DHS Open-Source Framework in the form of new implementations, new plugins and/or bug fixing.
The main steps in a developer’s contribution process are listed below:
- GitHub installation and configuration in order to start with the development.
- Forking and Cloning the repository of interest to allow active development in the forked repository without impacting the original one.
- Modifying the source code adding new features or fixing a bug, and then pushing the changes in the forked repository.
- Rebasing the modified branch to get a much cleaner project history.
- Issuing a Pull Request to request contribution inclusion in the original repository master branch. It is recommended to send Pull Requests from dedicated branch, so that follow-up commits can be pushed to update the Pull Request if necessary.
Software contribution development #
Contributors can provide valuable contribution to the Collaborative DHS Service developing new features, new plugins, or fixing bugs.
The following Mandatory Rules and Best Practices are identified:
- All commit messages should have the relevant GitHub issue number. If an issue does not exist, create it as a new issue or as a sub-task of the overall issue.
- All contributions must be written under AGPL-3.0 license.
- Write unit tests before coding, to verify bug and desired behaviour.
- Ensure build is not broken before committing. Fix build issues immediately in case.
- In case of doubts, contact the Maintainers asking for support.
Post-phase #
In the frame of the post-phase the contributing process is set up and followed until completion.
Contribution approval #
The aim of this task is to detail the steps followed to review and approve contribution from Contributors in the Collaborative DHS Open-Source Framework.
The applied process is the following:
- Contribution is submitted by Contributor via GitHub Pull Request in one of the Collaborative DHS Public repositories.
- The relevant Maintainers review the Pull Request to assess the value of the contribution.
- If the contribution is valuable for the project, the Contribution is submitted to the Service Board.
- The Service Board examines the contribution and approves it (in case). In addition, the scheduled release where to include the contribution is defined according to defined prioritization, evaluating the adherence to the Evolution Roadmap and the impact on the project (integration/validation).
Contribution not relevant for the project or not approved by the Service Board can be rejected or put on-hold.
Contribution merge in repository #
All contributions approved by the Service Board are merged in the master branch of the original Public GitHub repository. As result, future releases of the involved software will also contain the contribution from the external Contributor, reaching the entire Open-Source community.
Notification to Contributor #
Open-Source Contributors are always notified about their Pull Request approval decision via GitHub comments/feedback. The following possibilities are defined:
- contribution selected and implemented
- contribution rejected
- contribution on-hold
Developers’ guidelines for DHS modules evolutions #
We do have a few guidelines in place to help you be successful with your contribution to DHS Suite.
Checklist #
Here’s a quick checklist for a good Pull Request:
- A GitHub Issue with a good description associated with the PR
- One feature/change per PR
- PR rebased on main branch
- Includes functional/integration test
- Includes documentation
- One commit per PR
Developers’ Steps #
Create a GitHub issue #
Create a GitHub Issue containing a good summary and description associated with the feature/idea to implement.
This may be the first thing a Maintainer will look at what you are proposing, and it will also be used by the community in the future to find about what new features and enhancements are included in new releases.
Implementing #
Fork and Clone the repository of interest to allow active development in the forked repository without impacting the original one.
Modify the source code adding new features or fixing a bug according to the created GitHub issue.
Rebase the modified branch to get a much cleaner project history.
Do not change code not directly related to your PR. Do not format or refactor code that is not directly related to your contribution.
Testing #
Write unit tests before coding, to verify bug and desired behaviour. Ensure build is not broken before committing. Fix build issues immediately in case.
Please make sure you verify changes properly and include a description of what you have tested in the PR description.
Documentation #
Contributions should always include relevant documentation. Include relevant changes in your PR.
Submitting your Pull Request #
Make sure your branch is rebased on the main branch from the project repository.
Submit PR using a single commit; this helps the Maintainers reviewing PR and also makes it easier the maintenance of the repository.
Commit message should be prefixed by the issue number (for example “#23 PR Summary”).
Once you have submitted your PR please monitor it for comments/feedback.
