Stakeholder Authorizations of Rulesheet Repositories' Authors

A stakeholder, whether or not it is a Primary Custodian, must authorize rulesheet authors (or have none - with the implication that there are no managed rulesheets to be found). In doing so, you can get two things for the price of one. That is... from the collection of authorized authors, the Rulesheet Repositories in which the authors manage rulesheets may be "extracted" as the list from which a Gatepoint may request rulesheets when assembling a deck. As such, it can be helpful to prioritize the list (and therefore the authors' authorizations) so that the requesting Gatepoint may attempt to honor the stakeholder's preference of priority, such as for fail-over purposes.

To add an authorization for an author, the author must first establish an account at one or more Rulesheet Repositories in which the author is willing to work to manage any stakeholders' rulesheets. Likely, a stakeholder will only grant authorization for specific Rulesheet Repositories, so the author and the stakeholder must coordinate with each other on selection of an appropriate Rulesheet Repository. After establishing account(s), the author provides the "author URI" for each repository to the stakeholder (or to the Stakeholder Directory). The stakeholder, once in possession of this author URI information, is at liberty to grant or deny authorization. Granting authorization is accomplished by adding the author URI to the list of authorizations. It is suggested that the administrators of the Stakeholder Directories may do this task on behalf of the stakeholders, or the Stakeholder Directories may expose a software feature to the stakeholders whereby they may perform this task themselves.

A stakeholder prioritizes repositories - not authors, as rulesheets may be managed by more than one author. When adding an author URI to the list of authorizations, the author URI assumes the identical priority/preference value as all other author URIs at the same Rulesheet Repository (creating a "group" of author URIs). If no other author URIs at that same repository exist, then the author URI must be accompanied by a priority/preference value. Any existing group of author URIs with the same priority/preference value should be bubbled to a lower priority (lower priorities are greater in numeric value, such that 2 is a lower priority than 1), which in turn should cause other conflicts to be resolved in the same fashion. These "reprioritizations" necessarily should be performed in groups, so that all members of former priority 2 (as an example) are made priority 3, and all conflicting members of priority 3 are made priority 4, etc. In light of this, it may be considered by a Stakeholder Directory to offer features or guidance to stakeholders for "staggering" priority levels when adding new authorizations. For example, a stakeholder might add two author URIs as priority 10, another four author URIs are priority 20, and yet another author URI as priority 30; this would leave priority values 1-9, 11-19, 21-29, and >30 unassigned and "reserved" for later use.

If a stakeholder desires any changes to existing author URI priorities, then the implementation should also leverage the same "performed in groups" recommendation as has the "reprioritizations" aspect described above.

As an alternative to the bubble approach to reprioritizations, any priority/preference value accompanying a new author URI (or when accommodating a change in priority request) could be "fudged" to a different value that does not conflict with existing author URI priorities as long as the intent of the stakeholder is preserved. The literal values of the priorities often should not matter to stakeholders.

This discussion does not address in detail the due diligence that both the stakeholder and the Stakeholder Directory administrator must share in vetting an author URI prior to adding it to the authorized list of authors. It is out of scope for CDCL because the vetting process will likely differ among communities.