Conversation
|
|
|
The created documentation from the pull request is available at: docu-html |
anmittag
force-pushed
the
pmp-pm-updates
branch
from
c9a7b60 to
a853a29
Compare
- added diagram - added verification report - added itf to index.rst
Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>
update link to release notes add link to maturity levels
anmittag
requested review from
a team,
PandaeDo and
aschemmel-tech
as code owners
|
@anmittag content wise it looks good to me. Only concern is the number of commits. Please squash them or use a squash merge when merging, so the main branch history stays clean and readable. |
There was a problem hiding this comment.
We discussed to change here: Legend, Project Management Plan Res.. -> Plan Responsibility
Development Team -> Delivery Team, may also change in the image
Docu -> Documentation Management Plan
Cross Functional Communities -> Communities, compare your headers below, should be 1:1 map
| .. _PRCMBRS: https://github.com/eclipse-score/process_description/blob/main/.github/CODEOWNERS | ||
| .. _PRCLD: https://github.com/eclipse-score/process_description/blob/main/.github/CODEOWNERS | ||
| .. _PRCMM: https://github.com/eclipse-score/score/wiki/PRCM | ||
| .. _PRCSLC: https://sdvworkinggroup.slack.com/archives/C0864L05332 |
There was a problem hiding this comment.
Clicking on the link opens an empty page, but not the Meeting Minutes Working Stream?
There was a problem hiding this comment.
will be installed accordingly as soon as I have write access
| .. _pmp_pm_feature_teams: | ||
|
|
||
| Feature Teams | ||
| ^^^^^^^^^^^^^ |
There was a problem hiding this comment.
well, I have to disagree, otherwise you have to adapt each and everything:
There was a problem hiding this comment.
we said, Improvement can be triggered by any Process
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
see inline comments
| - **-----------------------** | ||
|
|
||
| * - - Decisions about strategical topics | ||
| - Review and approval of contributions, e.g. Feature Requests, which add or modify features |
There was a problem hiding this comment.
Previously we had also the "Decision on which new software modules should be added or removed from the project." - @FScholPer asked specifically about this. Note that it is really about adding/removing repositories (which in the process metamodel are called "Delivery Containers". And what about "Decision to create new feature team"?
| Org Chart and Main Platform Management Plan Responsibilities | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| .. image:: _assets/score_project_management_organization_orgchart.drawio.svg |
There was a problem hiding this comment.
Please rename "Development Team" to "Delivery Team" in the picture.
There was a problem hiding this comment.
Renamed to Feature Team. In case there is an agreement and decision to rename all feature teams to delivery teams not only in the process community this has to be changed in EVREY place ...
| Team* setup should initiate committer elections for all software developers in the *Codeowner GitHub team*. | ||
| All other Technical Leads who are already committers in the S-CORE project are expected to support these | ||
| elections by voting positively, provided there are no specific objections. | ||
| A *Feature Request* represents an independent work package used to describe and |
There was a problem hiding this comment.
It is not clear in this description if a "Feature Request" is an 1. introduction of a new feature 2. change of an existing feature or both.
| **Component Request** | ||
|
|
||
| Open points from the meetings will be handled by *GitHub Issues* in the *S-CORE* main repository and can be filtered via *project_lead_circle* label. | ||
| A *Component Request* represents an independent work package used to describe modifications inside a *Feature*. |
There was a problem hiding this comment.
Actually my understanding of a "Component Request" was that it is used to "create a new component" or "change a component".
| Open points from the meetings will be handled by *GitHub Issues* in the *S-CORE* main repository and can be filtered via *project_lead_circle* label. | ||
| A *Component Request* represents an independent work package used to describe modifications inside a *Feature*. | ||
| *Component Request* work packages can be linked to other work packages, but they must not be treated as parent work packages. They are in the responsibility of the | ||
| :ref:`Architecture Community <pmp_pm_arc>` and the issues are part of the :ref:`Root Repository <pmp_pm_root_repository>`. |
There was a problem hiding this comment.
based on the above understanding I would not see the architecture community as responsible here - this should be decided by the Feature Teams.
20 participants
closes #2401, closes #2379 , closes #2411