docs: feature_request proposal

Initial proposal for feature request

Author: antonkri

docs/contribute/contribution_request/feature_request.rst

@@ -0,0 +1,78 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2024 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+
+Feature Request Guideline
+##############################
+
+.. document:: Feature Request Guideline
+  :id: doc__feature_request_guideline
+  :status: valid
+
+This Feature Request Guideline is a "How-To for Dummies" for proposing/contributing a new feature or changes to an existing feature.
+This Guideline is based on or references following documents:
+* :ref:`Contribution Guideline <contribute_contribution_guideline>`
+* :ref:`Change Management Plan <change_mgmt_plan>`
+* :ref:`Feature Template <chm_feature_templates>`
+
+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 *Change Management Plan*.
+
+* Technical Leads review regulary all new incoming feature requests (GitHub Issues labeled as *feature_request* or *feature_modification*). This happens normally on Monday in the Technical Lead cirle.
+  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 *Feature Request GitHub Project* we use additional states for a better tracking of the *feature request*.
+  These states symbolizes the status of the *feature request* and not the "GitHub" states of the issue. The initial status of every *feature request* will be set to "Draft".
+* Next step would be to start working on the *feature request*. First of all, change the status of *Feature Request* into "in Progress" state.
+  *Feature Requests*, that stay in the status "Draft" for a longer period of time, will be deleted. Depending on the maturity of the *feature request*, following two options are possible:
+
+  * If the *feature request* is "just an idea" and you do not have any concrete requirements,
+    feature architecture diagramms  or source code, then you could put the description of you *feature request* directly to the description of the *GitHub Issue*.
+    A good exhaustive description is a prerequisite for feature request to be accepted.
+  * If you already have some requirements, feature architecture description or code, then you could create a PR in the `score repository <https://github.com/eclipse-score/score/tree/main/docs/features>`_
+    with your proposal. The PR should follow following template: :ref:`Feature Template <chm_feature_templates>`.
+
+Review of Feature Request
+================================
+* As soon as you're done with description of your *feature request*, please put the status into "Ready for Review" so that Technical Leads know, that they can starting with the process of reviewing the *feature request*.
+  Technical Leads will do a short review of your *feature request*:
+
+  * In case the impact of your *feature request* is trivial, then TLs can process your *feature request* immediately.
+  * Normally, TL circle will assign it to the lead of appropriate *CFT* or *Community* for better analysis. This team will change the status to "in Review" as soon as they will start
+    reviewing your *feature request*.
+
+      * In case a *feature request* can not be clearely assigned to any already existing team, Technical Lead circle will pick at least two suitable candidates from the project to review the *feature request*.
+
+  * In case of big architectural impact, Technical Lead cirlce can additionally decide to request a review from software architecture community.
+
+* The outcome of the review could be like following:
+
+  * **Accepted** - You *feature request* is accepted. Your PR will be merged and the Issue will be closed. The technical leads will create a new GitHub issue of type 'Epic',
+    where detailed information regarding your feature will be documented. Afterwards the epic will be assigned to the corresponding team (CFT/Community).
+    If none of the CFTs/Communities match the new *feature request*, then a new CFT/Community will be founded. You will be invited to the CFT/Community for break down of the *feature request* and planning.
+  * **Rejected** - You *feature request* was rejected. It could be either because you description was not mature enough or because the proposal technically doesn't fit into S-CORE roadmap or architecture.
+    You will be able to find the result of the review in the corresponding GitHub issue comments.
+  * **Changes Requested** - We like your idea, but we would like to request some modifications. This could be rather technical topics or also syntax issues in the description.
+    You will find all necessary information in GitHub Issue comments.
+  * **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.
+    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/contribute/contribution_request/index.rst

@@ -179,3 +179,9 @@ The figure below shows options to report something.
   :alt: Reporting options overview
 
   Reporting options overview
+
+.. toctree::
+   :hidden:
+   :maxdepth: 2
+
+   feature_request

docs/platform_management_plan/change_management.rst

@@ -19,6 +19,8 @@
    :tags: platform_management
    :realizes: wp__chm_plan
 
+.. _change_mgmt_plan:
+
 Change Management / Change Management Plan
 ------------------------------------------