[wp-trac] [WordPress Trac] #48486: Add compliance tab to plugin repository pages on WordPress.org

[WordPress Trac]

#48486: Add compliance tab to plugin repository pages on WordPress.org
-------------------------+-------------------------------------------------
 Reporter:  katwhite     |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  5.3
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  accessibility, docs, privacy,
                         |  coding-standards
-------------------------+-------------------------------------------------

Comment (by carike):

 Hallo everyone :)

 Created an example readme.txt here: https://github.com/carike-codes
 /disclosures-and-permissions-tabs/blob/master/README.txt
 It is the one @Ipstenu based her comments on.

 It appears that the readme.txt may not be the ideal way to deal with
 disclosures.

 I have an idea how to automate a significant portion of the disclosures,
 but need feedback.

 You're welcome to comment on this ticket.  I will copy over comments
 (linking to the original here) to issues in the GitHub repository here:
 https://github.com/carike-codes/disclosures-and-permissions-tabs/
 The GitHub repository was set up in response to requests in #core-privacy.
 I can't reasonably ask developers who would like to help to go read
 through the threads in all of the related tickets to find any constraint
 that could apply to their Pull Request, so summarizing design
 considerations under (regularly updated) issues.
 I'll cross-update this ticket periodically with progress too.

 Permission levels are currently a fixed list proposed by @rogierlankhorst
 in #core-privacy: Functional; Anonymous Statistics; Statistics and
 Marketing.
 The question becomes what is the best way for plugin authors to indicate
 which particular permission level each of their (relevant) functions need.
 Discussions documented here: https://github.com/carike-codes/disclosures-
 and-permissions-tabs/issues/3

 I propose that this only applies to "high risk / high impact" core
 functions / APIs for now.
 We need to define what those would be.  Thus far proposing the HTTP API
 and wp_mail().
 Would also like to include set_cookie(), although that may be more
 complicated since it is a PHP function and not a WordPress one.  Record of
 discussions here: https://github.com/carike-codes/disclosures-and-
 permissions-tabs/issues/4.
 I do have an (abstract) idea of how external network calls with JavaScript
 / CSS can be dealt with, but need to outline it first, so not addressing
 it here yet.

 One (design) option would be to add an additional argument for $purpose
 (fixed list for permission level as per the above) to "high risk / high
 impact" functions.  I need feedback from core contributors as to how
 difficult this would be.
 The value of the variable just needs to be available for use by plugin
 (Feature as a Plugin), to populate the Disclosure / Permissions Tabs.

 I can also explain how existing plugins would be affected by Disclosures
 and Permissions Tabs.
 I'll update here as soon as I have written it all down.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48486#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform