Conversation
| - GEMS Language | ||
| - GemsPy | ||
| - Antares2GEMS Converter | ||
| - PyPSA2GEMS Converter |
There was a problem hiding this comment.
Please give the URL of the concerned repos
|
|
||
| # 1. Development Starting Point | ||
|
|
||
| All changes **MUST start from a tracked GitHub Issue**. |
There was a problem hiding this comment.
We should precise/discuss where the GitHub Issue should be written. My opinion: each repo should own its GitHub issues.
There was a problem hiding this comment.
Indeed, that's the plan!
| The issue **MUST include**: | ||
|
|
||
| - purpose of the change | ||
| - affected repository or repositories |
There was a problem hiding this comment.
I am not sure this a responsibility of the GitHub issue writer to enumerate impacts on other repos. It can help, but it is not mandatory and we shouldn't expect this for any GitHub issue.
There was a problem hiding this comment.
Merge last expected impact and compatibility impact
There was a problem hiding this comment.
affected repository or repositories is excluded
| ## Scope | ||
| List affected components, modules, or repositories. | ||
|
|
||
| ## Compatibility Impact |
There was a problem hiding this comment.
See my remark above: I am not sure this is the reponsibility of a repo to warn the downstream repo. This is rather the responsibility of each repo to "observer" the upstream repo.
There was a problem hiding this comment.
Totally agree, repositories are excluded, but we will still have compatibility impact.
2 participants
This PR introduces Pull-Request Lifycycle Workflow Management with following rules and steps: