docs: fix findings in PR

Fix multiple findings in the PR

Author: antonkri

docs/contribute/contribution_request/feature_request.rst

@@ -29,38 +29,53 @@ This Guideline is based on or references following documents:
 
 Creation of Feature Request
 ================================
-* As the very first step, you will need to become of an official contributor, as described in
-  `Actions to Ensure Proper Contribution  <https://eclipse-score.github.io/score/main/contribute/general/contribution_attribution.html#contribution-attribution>`_
-
-* Afterwards you will be able to create a GitHub Issue and mark it
-
-  * with label *feature_request* if you want to propose a new feature, or
-  * with label *feature_modification* if you want to propose changes to an existing feature,
-
-  as described in the :ref:`Change Management Plan <change_mgmt_plan>`.
-
-  Please put a short description of your *feature request* into the GitHub Issue description, so that
-  everyone can immediately understand, what the *feature request* is about.
-
-  Technical Leads review regularly all new incoming *feature requests* (GitHub Issues labeled as *feature_request* or *feature_modification*).
-  This happens normally on Monday in the `Technical Lead circle <https://github.com/orgs/eclipse-score/discussions/104>`_.
-  As soon as you've labeled your GitHub Issue with *feature request*/*feature_modification* label,
-  TLs will see the *feature request* and will add it to the special GitHub project,
-  `Feature Request GitHub Project <https://github.com/orgs/eclipse-score/projects/4>`_.
-  Inside of this *Feature Request GitHub Project* additional states are used for a better tracking of the *feature requests*.
-  These states symbolize the status of the *feature request* and not the "GitHub" states of the issue, therefore we will further speak about
-  *feature request status*. The initial status of every *feature request* is set to "Draft".
-
-* After you have created a GitHub Issue, next step would be to start working on the *feature request*.
-  First of all, change the status of *Feature Request* to "in Progress" state.
-  *Feature Requests*, that stay in the status "Draft" for a longer period of time, will be deleted.
-  Afterwards create a PR with your proposal in the `/docs/features <https://github.com/eclipse-score/score/tree/main/docs/features>`_ score repository.
-  There you will find currently existing features as subfolders. Please choose the one that fits your *feature request* the most or
-  create a new subfolder, if none of existing feature match your *feature request*. Please take care, that the PR follows the :ref:`Feature Template <chm_feature_templates>`.
-  You should try to put as much information as possible, as a good exhaustive description is a prerequisite for *feature request* to be accepted.
+1. As the very first step, you will need to become an official contributor, as described in
+`Actions to Ensure Proper Contribution  <https://eclipse-score.github.io/score/main/contribute/general/contribution_attribution.html#contribution-attribution>`_
+
+2. Afterwards you will be able to create a GitHub Issue in the main `score repository <https://github.com/eclipse-score>`_
+and mark it
+
+* with label *feature_request* if you want to propose a new feature, or
+* with label *feature_modification* if you want to propose changes to an existing feature,
+
+as described in the :ref:`Change Management Plan <change_mgmt_plan>`.
+
+Please put a short description of your *feature request* into the GitHub Issue description, so that
+everyone can immediately understand, what the *feature request* is about.
+
+Technical Leads review regularly all new incoming *feature requests* (GitHub Issues labeled as *feature_request* or *feature_modification*).
+This happens normally on Monday in the `Technical Lead circle <https://github.com/orgs/eclipse-score/discussions/104>`_.
+As soon as you've labeled your GitHub Issue with *feature request*/*feature_modification* label,
+TLs will see the *feature request* and will add it to the special GitHub project,
+`Feature Request GitHub Project <https://github.com/orgs/eclipse-score/projects/4>`_.
+Inside of this *Feature Request GitHub Project* additional states, as shown in the table below,
+are used for a better tracking of the *feature requests*.
+These states symbolize the status of the *feature request* and not the "GitHub" states of the issue, therefore we will further speak about
+*feature request status*. The initial status of every *feature request* is set to "Draft".
+
+======================       ====================
+FR status                    Description
+======================       ====================
+**Draft**                    Feature Request is in the initial state
+**In Progress**              This is actively being worked on
+**In Review**                Feature Request should be reviewed by the technical leads
+**Accepted**                 Feature Request was accepted
+**Rejected**                 Feature request was rejected
+**Changes Requested**        Changes requested
+**POC Needed**               "Proof of concept" in incubation repository is needed
+======================       ====================
+
+3. After you have created a GitHub Issue, next step would be to start working on the *feature request*.
+First of all, change the status of *Feature Request* to "in Progress" state.
+*Feature Requests*, that stay in the status "Draft" longer as 4 weeks, will be deleted.
+Afterwards create a PR with your proposal in the `/docs/features <https://github.com/eclipse-score/score/tree/main/docs/features>`_ score repository.
+There you will find currently existing features as subfolders. Please choose the one that fits your *feature request* the most or
+create a new subfolder, if none of existing feature match your *feature request*. Please take care, that the PR follows the :ref:`Feature Template <chm_feature_templates>`.
+You should try to put as much information as possible, as a good exhaustive description is a prerequisite for *feature request* to be accepted.
 
 It is important to understand, that *feature request* consists of an GitHub Issue, that is used to track organizational information and
-PR, that contains the technical content. GitHub Issue always stays assigned to the owner of the *feature request*.
+PR, that contains the technical content. This is explained once again in detailed in the :ref:`Change Management Worlflow <change_mgmt_workflow>`
+chapter of :ref:`Change Management Plan <change_mgmt_plan>` document. GitHub Issue always stays assigned to the owner of the *feature request*.
 *Feature Request* PR will always be assigned to the owner of the *feature request* as well, but will additionally get the list of reviewers, that
 should review this *feature request* PR.
 
@@ -80,7 +95,8 @@ Review of Feature Request
 
   * In case of big architectural impact, Technical Lead circle can additionally decide to request a review for *feature request* PR from software architecture community.
 
-* The outcome of the review could be like following:
+* After the review is done, the TL circle will set the status of the *feature request* accordingly and will
+  also put all further necessary information as GitHub Issue comments. The outcome of the review could be like following:
 
   * **Accepted** - You *feature request* is accepted. The *feature request* GitHub Issue should contain now a link to a new GitHub issue of type 'Epic',
     that was created by Technical Leads, where detailed information regarding your feature is documented.
@@ -98,6 +114,7 @@ Review of Feature Request
     The review comments will be done directly in the *feature request* PR.
   * **POC needed** - We generally like your idea, but we don't have enough technical understanding of the *feature request*,
     e.g. technical scope is too big, and we need a POC to be able to understand better,
-    how the proposed *feature request* fits into the overall solution. You will find in the GitHub issue comments the information what your POC should focus on.
+    how the proposed *feature request* fits into the overall solution. You will find in the GitHub issue comments
+    the decsription for both the scope of the PoC and the requirements and the acceptance criteria for the requested PoC.
     Also, a so called *incubation repository* will be created by the reviewers of the *feature request*, where you should implement your POC.
     Please be aware, that POC is not a guarantee, that you *feature request* will be accepted.

docs/platform_management_plan/change_management.rst

@@ -141,6 +141,8 @@ description.
 :need:`[[title]] <gd_req__change__attr_milestone>` is defined by the Milestone of a ISSUE.
 
 
+.. _change_mgmt_workflow:
+
 Change Request Workflow
 ^^^^^^^^^^^^^^^^^^^^^^^