search

carike-codes / disclosures-and-permissions-tabs

Intended as a "Feature as a Plugin" to improve privacy-related disclosures in WordPress.org core. Still in its infancy. Hope it grows up quickly :)
GNU General Public License v2.0
2 stars 0 forks source link

Call for comments on disclosing privacy matters in a plugin's readme.txt #1

Closed carike-codes closed 4 years ago

carike-codes commented 4 years ago

@timothybjacobs (Slack handle) suggested that we make use of a privacy.json file for privacy-related disclosures: https://core.trac.wordpress.org/ticket/49272#comment:2 [updated 29 January 2020).

The readme.txt for this Disclosure and Permissions Tabs plugin could ideally be used as an example for plugin contributors and included in official WordPress.org documentation. The current readme.txt example found here https://wordpress.org/plugins/readme.txt and included in https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/, does not address privacy.

Version 0.0.0. (for discussion purposes only) of the proposed updated readme.txt example can be found here: https://github.com/carike-codes/disclosures-and-permissions-tabs/blob/master/README.txt

All comments that we become aware of, will be added to this issue and listed below:

Comment by @ipstenu Slack handle: https://core.trac.wordpress.org/ticket/48486#comment:17

I just now got caught up on this. Some thoughts, and it begins with this: If we can AUTOMATE this, it's better. Whenever you ask the developers to self-claim this stuff, then they're either going to paint themselves in the best light OR not at all. The fewer people who use this, the less useful anything is. Also remember the more you ask volunteers to monitor and manage, the more likely you are to get things missed. So think about what you can do automagically without the developer needed to do a thing. That'll get the best and most trusted results. Also it's unclear what specific issue you're trying to solve with each subsection. With that in mind. Having seen @Carike's example, there are some parts that just aren't going to work. The tab name (Privacy Related Considerations) is problematic. I would recommend just ‘Privacy’ - one word. That makes it harder for people to typo (remember we have a large number of ESL devs, let’s make things easier for them). It's broad, I know. All those subsections should be clearly optional. And we need to be clear that if someone wants to link to their webpage where everything is leagaleezed. Speaking of that, I see no mention of 'Terms of Use' or a link to Privacy docs. Both of those are things we regularly ask for. Contractual Terms as a sub-section is odd and, much like ‘installation instructions’ would be pointless for most plugins. They don't apply to the majority of plugins, and I can't think of where they'd apply outside of serviceware. Cron Jobs and Credits don’t seem to belong there at all. They really have nothing to do with privacy. The only reason I can think to put either in is that the cron-job is used to connect to an external service (which should be disclosed in this as a subsection for 'External Services Used') and 'credits' is meant to be "The license for the font library I use is..." which should probably be in a 'Licenses' subsection. The consent api subsection is unneeded. Either you're compliant or you're not. And if you're not, why on earth would you say it? If you really feel this is needed, then make it a new header like 'PHP Compatibility.' In fact, ANYTHING that is a Yes/No answer should be there. Less work :) Accessibility shouldn’t be a section. In a perfect world, it’s a yes/no flag assigned to a plugin after it’s reviewed by a member of the a11y team (or a robot we can teach to do that…) and confirmed (much like we auto flag plugins for being translatable). Put it on the sidebar “Accessibility Verified {YES!}” (I am well aware we don't have a tool that can do this, nor do we have a team with the infrastructure to manage -- I still strongly feel that asking a developer to self-declare accessibility will have net negative results. They're going to be wrong, either intentionally or due to not understanding, and that would be worse for users who need this.) Security as a tab is sadly pointless. Needed, yes, but it’s not going to be used properly and that makes it useless. This would be a place where TIDE comes into play. Tide scan on security etc linked on the sidebar would suffice and be more useful than trusting Joe Random. Certifications/Compliance - We have a guideline that says a plugin cannot state or claim or imply that it is 100% compliant with anything because that’s just impossible. This would not be as helpful as one might think.

carike-codes commented 4 years ago

TimothyBJacobs (Slack handle) suggested that we make use of a privacy.json file for privacy-related disclosures: https://core.trac.wordpress.org/ticket/49272#comment:2 [updated 29 January 2020).