From 3fbb1483ab2226e037c89f8c4e149d723c1e5832 Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Mon, 26 Feb 2018 17:37:55 +0100 Subject: [PATCH 01/11] [WIP] Authorisation Service - Initial commit --- proposed/authorisation-service-meta.md | 89 ++++++++++++++++++++++++++ proposed/authorisation-service.md | 77 ++++++++++++++++++++++ 2 files changed, 166 insertions(+) create mode 100644 proposed/authorisation-service-meta.md create mode 100644 proposed/authorisation-service.md diff --git a/proposed/authorisation-service-meta.md b/proposed/authorisation-service-meta.md new file mode 100644 index 0000000..df1f379 --- /dev/null +++ b/proposed/authorisation-service-meta.md @@ -0,0 +1,89 @@ +# Authorisation Service Meta Document + +## 1. Summary + +Authorization is the function of specifying access rights/privileges to resources related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define an access policy. [Wikipedia](https://en.wikipedia.org/wiki/Authorization) + +This specification aims to define a minimal interface for a service allowing to use Role Based Access Control in components, if they need to. + +## 2. Why Bother? + +While standard permissions can be implemented in way that components do not need to address it themselves, some components might need a more fine grained access to the permissions. A standardised interface enables 3PD to develop authorisation services which can be consumed by those components without having to deal with implementation details. + +## 3. Scope + +### 3.1 Goals + +This specification aims to provide robust interfaces for querying permissions and related information from Authorisation Services that are independent from the particular implementation. + +### 3.2 Non-Goals + +This specification does not seek to standardise or favor any particular implementation. +The setup and creation of roles and permissions is up to the implementation and not part of this specification. + +## 4. Approaches + +### 4.1 Access Control in the User Object + +#### Examples + +##### Zizaco/[Entrust][]: + +```php +$allowed = $user->hasRole('admin'); +$allowed = $user->can('edit-user'); +``` + +##### Joomla 3.7: + +```php +$allowed = JFactory::getUser()->authorise('core.delete', 'com_content.article.' . (int) $record->id) +``` + +#### 4.1.1 Projects Using Access Control in the User Object + + * Joomla 3 + * Zizaco/[Entrust][] (Laravel 5 Package) + +[Entrust]: https://github.com/Zizaco/entrust + +### 4.2 Separated Access Control + +#### 4.2.1 Projects Using Separated Access Control + +### 4.3 Comparison of Approaches + +While having Access Control in the User Object seems very convenient, it requires the user object to support access control explicitly, which violates the Separation of Concern Principle. + +### 4.4 Chosen Approach + +This specification follows the Separated Access Control approach. + +## 5. Design Decisions + +## 6. People + +### 6.1 Editor(s) + +* Niels Braczek, + +### 6.2 Sponsors + +* N/A + +### 6.3 Contributors + +* N/A + +## 7. Votes + +* **Entrance Vote:** _(not yet taken)_ +* **Acceptance Vote:** _(not yet taken)_ + +## 8. Relevant Links + +_**Note:** Order descending chronologically._ + +## 9. Errata + +... diff --git a/proposed/authorisation-service.md b/proposed/authorisation-service.md new file mode 100644 index 0000000..c1c7113 --- /dev/null +++ b/proposed/authorisation-service.md @@ -0,0 +1,77 @@ +# Authorisation Service + +This document describes ... + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119][]. + +[RFC 2119]: http://tools.ietf.org/html/rfc2119 + +### References + +- [RFC 2119][]: Key words for use in RFCs to Indicate Requirement Levels + +## 1. Specification + +### 1.1 Spec A + +### 1.2 Spec B + +## 2. Interfaces + +### 2.1 AuthorisationInterface + +The following interface MUST be implemented by compatible Authorisation Services. + +```php +namespace Joomla\Service\Authorisation + +/** + * AuthorisationInterface + */ +interface AuthorisationInterface +{ + /** + * Check if a particular user is allowed to take a particular action on a particular class or object. + * + * @param UserInterface $user The user that will take action + * @param string $action The action to be taken + * @param string|object $classOrObject The class or object to act on. + * + * @return bool + */ + public function isAllowed($user, $action, $classOrObject): bool; + + /** + * Get a list of users that are allowed to take an action on a particular class or object. + * + * @param string $action The action to be taken + * @param string|object $classOrObject The class or object to act on. + * + * @return UserInterface[] + */ + public function getUsers($action, $classOrObject): array; + + /** + * Get a list of actions that a particular user is allowed to take on a particular class or object. + * + * @param UserInterface $user The user that will take action + * @param string|object $classOrObject The class or object to act on. + * + * @return string[] + */ + public function getActions($user, $classOrObject): array; + + /** + * Get a list of objects that a particular user is allowed to take a particular action on. + * + * @param UserInterface $user The role or user that will take action + * @param string $action The action to be taken + * @param string $class Optionally restrict to a particular class. + * + * @return object[] + */ + public function getObjects($roleOrUser, $action, $class = null): array; +} +``` From 72650fc090dab609582c8f8c5b4d77999cc1091c Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Mon, 26 Feb 2018 17:55:44 +0100 Subject: [PATCH 02/11] Added ServiceProviderInterface dependency --- proposed/authorisation-service.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proposed/authorisation-service.md b/proposed/authorisation-service.md index c1c7113..69efb3c 100644 --- a/proposed/authorisation-service.md +++ b/proposed/authorisation-service.md @@ -27,10 +27,12 @@ The following interface MUST be implemented by compatible Authorisation Services ```php namespace Joomla\Service\Authorisation +use Joomla\DI\ServiceProviderInterface; + /** - * AuthorisationInterface + * AuthorisationServiceInterface */ -interface AuthorisationInterface +interface AuthorisationServiceInterface extends ServiceProviderInterface { /** * Check if a particular user is allowed to take a particular action on a particular class or object. From e8d1ec605f12952ed3ec83919b6eb10c699e2cb4 Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Mon, 26 Feb 2018 17:59:31 +0100 Subject: [PATCH 03/11] Fixed typo --- proposed/authorisation-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposed/authorisation-service.md b/proposed/authorisation-service.md index 69efb3c..022060d 100644 --- a/proposed/authorisation-service.md +++ b/proposed/authorisation-service.md @@ -20,7 +20,7 @@ interpreted as described in [RFC 2119][]. ## 2. Interfaces -### 2.1 AuthorisationInterface +### 2.1 AuthorisationServiceInterface The following interface MUST be implemented by compatible Authorisation Services. From 1661d317978577597fa6458ff67544bf7d4395be Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Tue, 27 Feb 2018 19:31:50 +0100 Subject: [PATCH 04/11] Separated Basic and Extended Authorisation Service Interfaces --- proposed/authorisation-service-meta.md | 20 ++++++++++++++-- proposed/authorisation-service.md | 33 +++++++++++++++++++------- 2 files changed, 43 insertions(+), 10 deletions(-) diff --git a/proposed/authorisation-service-meta.md b/proposed/authorisation-service-meta.md index df1f379..21f5369 100644 --- a/proposed/authorisation-service-meta.md +++ b/proposed/authorisation-service-meta.md @@ -23,6 +23,12 @@ The setup and creation of roles and permissions is up to the implementation and ## 4. Approaches +Privileges are three-dimensional: + + * **Actor** - a user or a role + * **Action** - a verb, sometimes with an intrinsic object + * **Entity** - an entity or a class of entities + ### 4.1 Access Control in the User Object #### Examples @@ -53,7 +59,7 @@ $allowed = JFactory::getUser()->authorise('core.delete', 'com_content.article.' ### 4.3 Comparison of Approaches -While having Access Control in the User Object seems very convenient, it requires the user object to support access control explicitly, which violates the Separation of Concern Principle. +While having access control in the user object seems very convenient, it requires the user object to support access control explicitly, which violates the [Single Responsibility Principle][]. ### 4.4 Chosen Approach @@ -61,6 +67,14 @@ This specification follows the Separated Access Control approach. ## 5. Design Decisions +* Some actions, like for example 'access-dashboard', do not need an entity to be applied to. + They operate on an 'intrinsic' thing, in this case the dashboard. + The interfaces make the corresponding parameter optional to address such cases. + It is up to then implementation to check if the supplied information is sufficient. +* The service API is separated into two interfaces. + * The *Basic Authorisation Service* interface covers the most widely spread use case for an authentication service and should be easy to implement upon any authorisation solution. + * The *Extended Authorisation Service* allows the access to a whole dimension (users, actions or entities), when the two other values are known. They are very useful in some special cases, but not needed in average components. + ## 6. People ### 6.1 Editor(s) @@ -82,7 +96,9 @@ This specification follows the Separated Access Control approach. ## 8. Relevant Links -_**Note:** Order descending chronologically._ +* Wikipedia article on [Single Responsibility Principle][] + +[Single Responsibility Principle]: https://en.wikipedia.org/wiki/Single_responsibility_principle ## 9. Errata diff --git a/proposed/authorisation-service.md b/proposed/authorisation-service.md index 022060d..472ed0a 100644 --- a/proposed/authorisation-service.md +++ b/proposed/authorisation-service.md @@ -14,15 +14,15 @@ interpreted as described in [RFC 2119][]. ## 1. Specification -### 1.1 Spec A +### 1.1 Basic Authorisation Service -### 1.2 Spec B +### 1.2 Extended Authorisation Service ## 2. Interfaces ### 2.1 AuthorisationServiceInterface -The following interface MUST be implemented by compatible Authorisation Services. +The following interface MUST be implemented by compatible Basic Authorisation Services. ```php namespace Joomla\Service\Authorisation @@ -30,7 +30,7 @@ namespace Joomla\Service\Authorisation use Joomla\DI\ServiceProviderInterface; /** - * AuthorisationServiceInterface + * Basic Authorisation Service Interface */ interface AuthorisationServiceInterface extends ServiceProviderInterface { @@ -40,30 +40,47 @@ interface AuthorisationServiceInterface extends ServiceProviderInterface * @param UserInterface $user The user that will take action * @param string $action The action to be taken * @param string|object $classOrObject The class or object to act on. + * May be omitted, if `$action` does not require an object. * * @return bool */ - public function isAllowed($user, $action, $classOrObject): bool; - + public function isAllowed($user, $action, $classOrObject = null): bool; +} +``` + +### 2.2 ExtendedAuthorisationServiceInterface + +The following interface MUST be implemented by compatible Extended Authorisation Services. + +```php +namespace Joomla\Service\Authorisation + +/** + * Extended Authorisation Service Interface + */ +interface ExtendedAuthorisationServiceInterface extends AuthorisationServiceInterface +{ /** * Get a list of users that are allowed to take an action on a particular class or object. * * @param string $action The action to be taken * @param string|object $classOrObject The class or object to act on. + * May be omitted, if `$action` does not require an object. * * @return UserInterface[] */ - public function getUsers($action, $classOrObject): array; + public function getUsers($action, $classOrObject = null): array; /** * Get a list of actions that a particular user is allowed to take on a particular class or object. * * @param UserInterface $user The user that will take action * @param string|object $classOrObject The class or object to act on. + * May be omitted, if `$action` does not require an object. * * @return string[] */ - public function getActions($user, $classOrObject): array; + public function getActions($user, $classOrObject = null): array; /** * Get a list of objects that a particular user is allowed to take a particular action on. From 4b3997bd25d02526b160a33af2329257f61fc603 Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Wed, 7 Mar 2018 15:30:28 +0100 Subject: [PATCH 05/11] Added links to Bouncer and Entrust --- proposed/authorisation-service-meta.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposed/authorisation-service-meta.md b/proposed/authorisation-service-meta.md index 21f5369..85f70f2 100644 --- a/proposed/authorisation-service-meta.md +++ b/proposed/authorisation-service-meta.md @@ -51,8 +51,6 @@ $allowed = JFactory::getUser()->authorise('core.delete', 'com_content.article.' * Joomla 3 * Zizaco/[Entrust][] (Laravel 5 Package) -[Entrust]: https://github.com/Zizaco/entrust - ### 4.2 Separated Access Control #### 4.2.1 Projects Using Separated Access Control @@ -97,8 +95,11 @@ This specification follows the Separated Access Control approach. ## 8. Relevant Links * Wikipedia article on [Single Responsibility Principle][] +* [Bouncer](https://github.com/JosephSilber/bouncer) is an elegant, framework-agnostic approach to managing roles and abilities for any app using Eloquent models. +* [Entrust][] is a succinct and flexible way to add Role-based Permissions to Laravel 5. [Single Responsibility Principle]: https://en.wikipedia.org/wiki/Single_responsibility_principle +[Entrust]: https://github.com/Zizaco/entrust ## 9. Errata From cae2aded1d99bbab83176048b7cecb231fd55dd8 Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Wed, 14 Mar 2018 15:10:14 +0100 Subject: [PATCH 06/11] Consistent naming of methods and parameters --- proposed/authorisation-service-meta.md | 8 +++--- proposed/authorisation-service.md | 40 +++++++++++++------------- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/proposed/authorisation-service-meta.md b/proposed/authorisation-service-meta.md index 85f70f2..17b3430 100644 --- a/proposed/authorisation-service-meta.md +++ b/proposed/authorisation-service-meta.md @@ -27,7 +27,7 @@ Privileges are three-dimensional: * **Actor** - a user or a role * **Action** - a verb, sometimes with an intrinsic object - * **Entity** - an entity or a class of entities + * **Target** - an entity or a class of entities ### 4.1 Access Control in the User Object @@ -66,12 +66,12 @@ This specification follows the Separated Access Control approach. ## 5. Design Decisions * Some actions, like for example 'access-dashboard', do not need an entity to be applied to. - They operate on an 'intrinsic' thing, in this case the dashboard. + They operate on an 'intrinsic' target, in this case the dashboard. The interfaces make the corresponding parameter optional to address such cases. It is up to then implementation to check if the supplied information is sufficient. * The service API is separated into two interfaces. * The *Basic Authorisation Service* interface covers the most widely spread use case for an authentication service and should be easy to implement upon any authorisation solution. - * The *Extended Authorisation Service* allows the access to a whole dimension (users, actions or entities), when the two other values are known. They are very useful in some special cases, but not needed in average components. + * The *Extended Authorisation Service* allows the access to a whole dimension (actors, actions or targets), when the two other values are known. They are very useful in some special cases, but not needed in average components. ## 6. People @@ -85,7 +85,7 @@ This specification follows the Separated Access Control approach. ### 6.3 Contributors -* N/A +* Klas Berlič Fras, ## 7. Votes diff --git a/proposed/authorisation-service.md b/proposed/authorisation-service.md index 472ed0a..e89252d 100644 --- a/proposed/authorisation-service.md +++ b/proposed/authorisation-service.md @@ -37,14 +37,14 @@ interface AuthorisationServiceInterface extends ServiceProviderInterface /** * Check if a particular user is allowed to take a particular action on a particular class or object. * - * @param UserInterface $user The user that will take action - * @param string $action The action to be taken - * @param string|object $classOrObject The class or object to act on. - * May be omitted, if `$action` does not require an object. + * @param UserInterface $actor The user that will take action + * @param string $action The action to be taken + * @param string|object $target The class or object to act on. + * May be omitted, if `$action` does not require an object. * * @return bool */ - public function isAllowed($user, $action, $classOrObject = null): bool; + public function isAllowed($actor, $action, $target = null): bool; } ``` @@ -61,36 +61,36 @@ namespace Joomla\Service\Authorisation interface ExtendedAuthorisationServiceInterface extends AuthorisationServiceInterface { /** - * Get a list of users that are allowed to take an action on a particular class or object. + * Get a list of actors (users) that are allowed to take an action on a particular target (class or object). * - * @param string $action The action to be taken - * @param string|object $classOrObject The class or object to act on. - * May be omitted, if `$action` does not require an object. + * @param string $action The action to be taken + * @param string|object $target The class or object to act on. + * May be omitted, if `$action` does not require an object. * * @return UserInterface[] */ - public function getUsers($action, $classOrObject = null): array; + public function getActors($action, $target = null): array; /** - * Get a list of actions that a particular user is allowed to take on a particular class or object. + * Get a list of actions that a particular actor (user) is allowed to take on a particular target (class or object). * - * @param UserInterface $user The user that will take action - * @param string|object $classOrObject The class or object to act on. - * May be omitted, if `$action` does not require an object. + * @param UserInterface $actor The user that will take action + * @param string|object $target The class or object to act on. + * May be omitted, if `$action` does not require an object. * * @return string[] */ - public function getActions($user, $classOrObject = null): array; + public function getActions($actor, $target = null): array; /** - * Get a list of objects that a particular user is allowed to take a particular action on. + * Get a list of targets (objects) that a particular actor (user) is allowed to take a particular action on. * - * @param UserInterface $user The role or user that will take action - * @param string $action The action to be taken - * @param string $class Optionally restrict to a particular class. + * @param UserInterface $actor The role or user that will take action + * @param string $action The action to be taken + * @param string $targetClass Optionally restrict to a particular entity class. * * @return object[] */ - public function getObjects($roleOrUser, $action, $class = null): array; + public function getObjects($actor, $action, $targetClass = null): array; } ``` From 4fcfe9c98bcae174c7549f0755c6bdab3ad6ed2e Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Wed, 22 Jan 2020 11:45:31 +0100 Subject: [PATCH 07/11] Interface Segregation: Removed dependencies --- proposed/authorisation-service.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/proposed/authorisation-service.md b/proposed/authorisation-service.md index e89252d..30f1cc6 100644 --- a/proposed/authorisation-service.md +++ b/proposed/authorisation-service.md @@ -27,12 +27,10 @@ The following interface MUST be implemented by compatible Basic Authorisation Se ```php namespace Joomla\Service\Authorisation -use Joomla\DI\ServiceProviderInterface; - /** * Basic Authorisation Service Interface */ -interface AuthorisationServiceInterface extends ServiceProviderInterface +interface AuthorisationServiceInterface { /** * Check if a particular user is allowed to take a particular action on a particular class or object. @@ -58,7 +56,7 @@ namespace Joomla\Service\Authorisation /** * Extended Authorisation Service Interface */ -interface ExtendedAuthorisationServiceInterface extends AuthorisationServiceInterface +interface ExtendedAuthorisationServiceInterface { /** * Get a list of actors (users) that are allowed to take an action on a particular target (class or object). From c47779c3eae3ed0fb6999b94f5ff371c9664fa9a Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Sat, 13 Aug 2022 12:22:23 +0200 Subject: [PATCH 08/11] Change RfC => RFC --- README.md | 18 +++++++++--------- bylaws/workflow.md | 12 ++++++------ index.md | 10 +++++----- 3 files changed, 20 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index 22cfa47..1da7c94 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,17 @@ -# Joomla! Feature / Specification RfCs +# Joomla! Feature / Specification RFCs -The idea behind this repository is to provide a central place for RfCs for new +The idea behind this repository is to provide a central place for RFCs for new features for the Joomla! projects and Specifications (interfaces) for further development. -The index of existing RfCs, whether they are in Pre-Draft state or accepted, is found in [index.md](index.md). +The index of existing RFCs, whether they are in Pre-Draft state or accepted, is found in [index.md](index.md). ## Proposing a Joomla! Feature or a Joomla! Specification To propose a Feature / Specification: - fork this repo, create a branch, checkout that branch, add the Feature / - Specification RfC in `proposed/`, push the branch to Github, and send a pull + Specification RFC in `proposed/`, push the branch to Github, and send a pull request; or, - create a ticket to start a discussion on Github; or, - start a conversation on the [CMS mailing list][joomla-dev-cms] for the CMS, the @@ -24,8 +24,8 @@ To propose a Feature / Specification: ## GitHub usage -All discussion regarding a Joomla! Feature and Specification RfC happens on the -mailing lists. Issues are used for bug tracking, and any RfC might not get appropriate +All discussion regarding a Joomla! Feature and Specification RFC happens on the +mailing lists. Issues are used for bug tracking, and any RFC might not get appropriate attention on the Issue Tracker. Please do not simply file an issue or PR and walk-away. The most likely outcome @@ -33,9 +33,9 @@ is that it will not get seen or addressed in foreseeable time. ## Language and Translations -All Joomla! Feature / Specification RfCs are written in English. +All Joomla! Feature / Specification RFCs are written in English. Joomla! does not offer official translations into other languages -but other external entities are free to translate the RfCs in accordance +but other external entities are free to translate the RFCs in accordance with the license. ## Voting @@ -50,7 +50,7 @@ Department Coordinator. The current list of Team Leaders is available on the [Vo The wording and structure for the documents in this repository are heavily inspired by the [PHP FIG][]. In fact, the README, workflow bylaw, voting protocol, and the -RfC document structure were created from copies of the FIG original. +RFC document structure were created from copies of the FIG original. [PHP FIG]: http://www.php-fig.org/ diff --git a/bylaws/workflow.md b/bylaws/workflow.md index c3a405c..52dfb38 100644 --- a/bylaws/workflow.md +++ b/bylaws/workflow.md @@ -1,4 +1,4 @@ -# Joomla! Feature / Specification RfC Workflow +# Joomla! Feature / Specification RFC Workflow ## Pre-Draft @@ -30,8 +30,8 @@ interested in publishing a Joomla! Feature or publishing a Joomla! Specification for the proposed subject, even if they disagree with the details of the proposal. If the vote passes, the proposal officially enters Draft stage. The proposal -receives a RfC number incremented from the highest numbered RfC -which has passed the Entrance Vote, regardless of the status of that RfC. +receives a RFC number incremented from the highest numbered RFC +which has passed the Entrance Vote, regardless of the status of that RFC. The Working Group may continue to work on the proposal during the complete voting period. @@ -92,9 +92,9 @@ Unless a proposal is moved to Draft stage again, it must remain in Review stage a minimum of four weeks and until - the User Interface is defined and the manual (help) page is written for the - functionality proposed in **Feature RfCs**. + functionality proposed in **Feature RFCs**. - two independent viable trial implementations can be demonstrated for - **Specification RfCs**, ideally as examples in the proposal repository. The + **Specification RFCs**, ideally as examples in the proposal repository. The responsibility for finding such trial implementations and presenting them to the Production Department Team Leaders lies with the Working Group, and especially the Editor and Sponsor. As not all specifications are PHP interfaces where the @@ -115,7 +115,7 @@ dissolved, however the Editor's input (or a nominated individual communicated t the Production Department Coordinator) may be called upon in the future should typos, changes or Errata on the specification be raised. -In case of Feature RfCs, a Development Team is created within the Production +In case of Feature RFCs, a Development Team is created within the Production Department. ## Deprecated diff --git a/index.md b/index.md index cd9e7ca..d6aca4e 100644 --- a/index.md +++ b/index.md @@ -1,14 +1,14 @@ -# Joomla Feature / Specification RfCs +# Joomla Feature / Specification RFCs -According to the [Joomla RfC Workflow Bylaw][workflow] each Joomla RfC has a +According to the [Joomla RFC Workflow Bylaw][workflow] each Joomla RFC has a status as it is being worked on. Once a proposal has passed the Entrance Vote it -will be listed here as "Draft". Unless a Joomla Feature / Specification RfC is marked +will be listed here as "Draft". Unless a Joomla Feature / Specification RFC is marked as "Accepted" it is subject to change. Draft can change drastically, but Review will only have minor changes. -As also described in the [Joomla RfC Workflow Bylaw][workflow], the editor(s) of a +As also described in the [Joomla RFC Workflow Bylaw][workflow], the editor(s) of a proposal are essentially the lead contributors and writers of the Joomla Feature / -Specification RfCs and they are supported by two voting members. Those voting +Specification RFCs and they are supported by two voting members. Those voting members are (1) the Coordinator who is responsible for managing the review stage and votes, and (2) a second sponsor. From 86e60061326dc4480554051e2c010073936b3d56 Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Sat, 13 Aug 2022 12:27:43 +0200 Subject: [PATCH 09/11] Add link to DZone article about RFCs --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index 1da7c94..94abc44 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,10 @@ The idea behind this repository is to provide a central place for RFCs for new features for the Joomla! projects and Specifications (interfaces) for further development. +To learn more about the importance of an RFC process, refer to the article [How to Write RFCs for Open Source Projects](https://dzone.com/articles/how-to-write-rfcs-for-open-source-projects) on DZone. +This RFC process follows the example of the PHP Framework Interoperation Group (PHP-FIG), which has worked successfully +for many years and still is. + The index of existing RFCs, whether they are in Pre-Draft state or accepted, is found in [index.md](index.md). ## Proposing a Joomla! Feature or a Joomla! Specification From ede128dc0273823212ea361639302d4e0dd65e4f Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Sat, 13 Aug 2022 12:28:26 +0200 Subject: [PATCH 10/11] Change Github => GitHub --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 94abc44..860826a 100644 --- a/README.md +++ b/README.md @@ -15,9 +15,9 @@ The index of existing RFCs, whether they are in Pre-Draft state or accepted, is To propose a Feature / Specification: - fork this repo, create a branch, checkout that branch, add the Feature / - Specification RFC in `proposed/`, push the branch to Github, and send a pull + Specification RFC in `proposed/`, push the branch to GitHub, and send a pull request; or, -- create a ticket to start a discussion on Github; or, +- create a ticket to start a discussion on GitHub; or, - start a conversation on the [CMS mailing list][joomla-dev-cms] for the CMS, the [Framework mailing list][joomla-dev-framework] for the Framework, or the [general mailing list][joomla-dev-general] for all other Joomla! projects. From 4f68508de9857228abfcdd37ef3dfc00365f6b66 Mon Sep 17 00:00:00 2001 From: Niels Braczek Date: Sat, 13 Aug 2022 12:38:57 +0200 Subject: [PATCH 11/11] Add SA&S as contact --- README.md | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 860826a..5a5fee0 100644 --- a/README.md +++ b/README.md @@ -1,21 +1,23 @@ # Joomla! Feature / Specification RFCs The idea behind this repository is to provide a central place for RFCs for new -features for the Joomla! projects and Specifications (interfaces) for further +features for the Joomla! projects and Specifications (interfaces) for further development. -To learn more about the importance of an RFC process, refer to the article [How to Write RFCs for Open Source Projects](https://dzone.com/articles/how-to-write-rfcs-for-open-source-projects) on DZone. +To learn more about the importance of an RFC process, refer to the +article [How to Write RFCs for Open Source Projects](https://dzone.com/articles/how-to-write-rfcs-for-open-source-projects) +on DZone. This RFC process follows the example of the PHP Framework Interoperation Group (PHP-FIG), which has worked successfully for many years and still is. -The index of existing RFCs, whether they are in Pre-Draft state or accepted, is found in [index.md](index.md). +The index of existing RFCs, whether they are in Pre-Draft state or accepted, is found in [index.md](index.md). ## Proposing a Joomla! Feature or a Joomla! Specification To propose a Feature / Specification: -- fork this repo, create a branch, checkout that branch, add the Feature / - Specification RFC in `proposed/`, push the branch to GitHub, and send a pull +- fork this repo, create a branch, checkout that branch, add the Feature / + Specification RFC in `proposed/`, push the branch to GitHub, and send a pull request; or, - create a ticket to start a discussion on GitHub; or, - start a conversation on the [CMS mailing list][joomla-dev-cms] for the CMS, the @@ -23,17 +25,22 @@ To propose a Feature / Specification: [general mailing list][joomla-dev-general] for all other Joomla! projects. [joomla-dev-cms]: https://groups.google.com/group/joomla-dev-cms + [joomla-dev-framework]: https://groups.google.com/group/joomla-dev-framework + [joomla-dev-general]: https://groups.google.com/group/joomla-dev-general ## GitHub usage -All discussion regarding a Joomla! Feature and Specification RFC happens on the +All discussion regarding a Joomla! Feature and Specification RFC happens on the mailing lists. Issues are used for bug tracking, and any RFC might not get appropriate attention on the Issue Tracker. -Please do not simply file an issue or PR and walk-away. The most likely outcome -is that it will not get seen or addressed in foreseeable time. +**Please do not simply file an issue or PR and walk-away. The most likely outcome +is that it will not get seen or addressed in foreseeable time.** +If you feel that no one cares about your proposal, please contact +the [Software Architecture & Strategy Team](https://volunteers.joomla.org/teams/software-architecture-strategy-working-group). +We want every idea to be taken seriously. ## Language and Translations @@ -44,24 +51,27 @@ with the license. ## Voting -Voting is restricted to the Production Department Team Leaders and the Production -Department Coordinator. The current list of Team Leaders is available on the [Volunteers Portal][]. Voting is conducted following the [Voting Protocol][]. +Voting is restricted to the Production Department Team Leaders and the Production +Department Coordinator. The current list of Team Leaders is available on the [Volunteers Portal][]. Voting is conducted +following the [Voting Protocol][]. [Volunteers Portal]: https://volunteers.joomla.org/departments/production + [Voting Protocol]: bylaws/voting.md ## Attribution The wording and structure for the documents in this repository are heavily inspired -by the [PHP FIG][]. In fact, the README, workflow bylaw, voting protocol, and the +by the [PHP FIG][]. In fact, the README, workflow bylaw, voting protocol, and the RFC document structure were created from copies of the FIG original. [PHP FIG]: http://www.php-fig.org/ ## License -Unless stated otherwise, all content is licensed under the [Creative Commons +Unless stated otherwise, all content is licensed under the [Creative Commons Attribution License][CC] and code licensed under the [MIT License][MIT]. [CC]: LICENSE-CC.md + [MIT]: LICENSE-MIT.md