# Why are there criteria changes being made without a discussion thread and approval first? **URL:** https://discuss.privacyguides.net/t/why-are-there-criteria-changes-being-made-without-a-discussion-thread-and-approval-first/36168 **Category:** Meta **Tags:** other **Created:** 2026-03-10T23:53:50Z **Posts:** 11 ## Post 1 by @anonymous549 — 2026-03-10T23:53:50Z Going off of @xe3 post [https://discuss.privacyguides.net/t/remove-protonvpn/33980/340](https://discuss.privacyguides.net/t/remove-protonvpn/33980/340) Why are these changes being made without a specific discussion about the proposed changes first? Every time I have seen talk of a criteria change, people have always been directed to make a thread focused on the criteria itself. Then to have a seperate discussion and have that change be approved first. It doesn’t seem like that is happening here. To me it seems the precedent is clear that whatever criteria discussion went on in the [remove proton](https://discuss.privacyguides.net/t/remove-protonvpn) thread should not have replaced the next step of discussing and debating criteria changes seperatly. examples > [@Criterias for Cloud storage, Photo Management, Calendar sync and Notebook](https://discuss.privacyguides.net/t/criterias-for-cloud-storage-photo-management-calendar-sync-and-notebook/22081): > > Don’t you think that we should put one criteria about privacy in these 4 sections ? Mainly to not use privacy-invasive analytics ? We could use the email client criteria : Must not collect telemetry, or have an easy way to disable all telemetry. We could inspire from the email providers criterias : Privacy policy that meets the requirements defined by the GDPR. Don’t require personally identifiable information (PII) besides a username and a password. (I don’t think any service would meet thi… > [@Should Privacy Guides require open-source, source-first or source-available as a criteria for all tools?](https://discuss.privacyguides.net/t/should-privacy-guides-require-open-source-source-first-or-source-available-as-a-criteria-for-all-tools/22684): > > Continuing from [What does Privacy Guides see as OpenSource?](https://discuss.privacyguides.net/t/what-does-privacy-guides-see-as-opensource/20230). I am wondering whether we should require some transparency of the code for all software we recommend. > [@Add a future-proofing condition to the inclusion criteria](https://discuss.privacyguides.net/t/add-a-future-proofing-condition-to-the-inclusion-criteria/26766): > > The topic has already been briefly touched upon [here](https://discuss.privacyguides.net/t/remove-strongbox/19613/39), and I would like to put forth an actual proposal for it. It has happened many times already that projects formerly recommended by Privacy Guides have had to be delisted from the website; the reasons for delisting a project have typically been one of the following, I think: the project had become unmaintained or was discontinued the project had shifted focus towards a different direction, deviating from its original privacy/security stance t… --- ## Post 2 by @jonah — 2026-03-11T00:21:41Z What changes? No changes have been made without a dedicated discussion thread and consensus. If we are looking at today, then the changes at [update!: Change VPN kill switch criteria by jonaharagon · Pull Request #3204 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/pull/3204) were discussed extensively at [Remove IVPN](https://discuss.privacyguides.net/t/remove-ivpn/34224). For evidence of clear community consensus, see: - [Remove IVPN - #2 by flowrpowr](https://discuss.privacyguides.net/t/remove-ivpn/34224/2) - [Remove IVPN - #4 by anon69871701](https://discuss.privacyguides.net/t/remove-ivpn/34224/4) - [Remove IVPN - #5 by anon1333233](https://discuss.privacyguides.net/t/remove-ivpn/34224/5) - [Remove IVPN - #9 by ignoramous](https://discuss.privacyguides.net/t/remove-ivpn/34224/9) - [Remove IVPN - #16 by Libre\_Software\_Enjoyer](https://discuss.privacyguides.net/t/remove-ivpn/34224/16) - oh, and you’re in there too asking us to make this change :+1: The _proposed_ changes at [update: Warning about Proton kill switch on macOS by jonaharagon · Pull Request #3205 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/pull/3205) and [update!: Remove ProtonVPN by jonaharagon · Pull Request #3203 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/pull/3203) are both specific responses to discussions within the [Remove ProtonVPN](https://discuss.privacyguides.net/t/remove-protonvpn/33980) thread. --- ## Post 3 by @anonymous549 — 2026-03-11T00:46:29Z I’m marking as the solution because you are the final say but I think you are misunderstanding my concern…or am I just mistaken. > [@jonah](#): > > For evidence of clear community consensus, see: > > - [Remove IVPN - #2 by flowrpowr](https://discuss.privacyguides.net/t/remove-ivpn/34224/2) > - [Remove IVPN - #4 by anon69871701](https://discuss.privacyguides.net/t/remove-ivpn/34224/4) > - [Remove IVPN - #5 by anon1333233](https://discuss.privacyguides.net/t/remove-ivpn/34224/5) > - [Remove IVPN - #9 by ignoramous](https://discuss.privacyguides.net/t/remove-ivpn/34224/9) > - [Remove IVPN - #16 by Libre\_Software\_Enjoyer](https://discuss.privacyguides.net/t/remove-ivpn/34224/16) > - oh, and you’re in there too asking us to make this change :+1: @jonah I was under the impression that criteria change had to be its _own_ thread and that “community consensus” on the criteria could not be reached in a seperate tool discussion. As its basically two suggestions (a tool change, and a criteria change) in one thread. Which would usually be invalid. --- ## Post 4 by @jonah — 2026-03-11T00:52:43Z Ah, I see what you mean. In [this](https://discuss.privacyguides.net/t/remove-ivpn/34224) IVPN case I didn’t think there was much room for discussion, because not requiring a kill switch on iOS was the _only_ possible outcome, otherwise we could never recommend a VPN? The other proposed changes coming from the Remove ProtonVPN thread aren’t criteria change PRs, and I’m not sure if we are proposing another criteria change in that thread anyways yet. I think if we are going to change criteria based on a ProtonVPN discussion then yes indeed we will need to start a new discussion about it, but we aren’t at this point. Instead I think the possibility of removing Proton VPN or adding a warning to it are both still on the table, which would make that removal thread still valid. --- ## Post 5 by @anonymous549 — 2026-03-11T00:55:43Z Thanks for the clarification. --- ## Post 6 by @Encounter5729 — 2026-03-11T15:20:23Z @jonah You effectively changed the VPN client criteria such that a VPN can have no killswitch what so ever on macOS, iOS and Windows and still qualify with the minimum criteria. (See [What should we require of VPN providers on macOS? - #60 by Overall-Bet3743](https://discuss.privacyguides.net/t/what-should-we-require-of-vpn-providers-on-macos/36175/60)) This decision has been rushed, and does not represent the opinion of most of the community. This is NOT a clarification, in fact even @ph00lt0 rightfully pointed an issue, saying it was vague, and you just passed trough. (Yes, it was ultimately approved by two teams members, but both stated objections) --- ## Post 7 by @jonah — 2026-03-11T15:28:36Z That was the only option expressed in the IVPN thread that would be consistent with our other criteria. We’ve never carved out exceptions for specific operating systems, we’ve only ever elevated our own recommendations. To limit the exception to iOS simply because some people don’t like Proton would be intentionally biasing our criteria _against_ Proton in particular, and would also be akin to marking iOS as an anti-recommendation, when we have consistently decided we don’t list anti-recommendations on our site. Limiting our minimum criteria to our own recommendations is the _least_ possible biased way to go about this. If you have an alternative suggestion for the criteria that addresses these points, and that isn’t already addressed in one of the 3 Proton-related threads currently open, feel free to make that suggestion. I suspect it will be the same as some currently being argued in those threads though. @ph00lt0’s issue was **entirely** different from what you are saying, because it was only about the very first sentence, and it was a misunderstanding of the change anyways because he didn’t notice what was now “vague” had just become specifically addressed in the following line. You’re misrepresenting what the consensus was here. --- ## Post 8 by @Encounter5729 — 2026-03-11T15:34:54Z > [@jonah](#): > > simply because some people don’t like Proton Is this what the state of the discourse? Falsely thinking you know an ulterior motive ? You also just completely ignored the concern of a rushed change. It’s very clear that by making, and closing a PR in under 16 hours, most people haven’t had the change to comment on it. --- ## Post 9 by @jonah — 2026-03-11T15:37:55Z The discussion was open since December with no negative feedback, so it is not contentious at all. The fact that you think there was a contentious discussion about this does indeed indicate to me you think the change was related to the Proton discussion, which is clearly not true because the Proton discussion _remains open and ongoing_ regardless of this change. It is in fact perfectly normal for changes to go from complete discussions here to closed PRs very quickly, because we do not have additional discussions on GitHub. We do not use GitHub as a place to gather even more feedback. --- ## Post 10 by @Encounter5729 — 2026-03-11T15:47:52Z First, you closed that thread, then reopened it with the PR a week later. This is clearly not a transparent way of doing things, just open a new one clearly stating the change. Second, no one in that thread argued that killswitches should only work, or even exist, only on platforms recommended by PG. So the change you made wasn’t based on any kind of feedback. A change stating a client can only provide a killswitch insofar as the platform allows, would have been more scope. This is what I proposed this morning. It is related to the Proton discussion. Under this new criteria, Proton doesn’t faul afoul of any criteria. And no, it isn’t normal that PRs are closed very fast. Github clearly is the place for _technical_ discussions about wording and scope. Also, you should allow time for people to comment on the forum, etc. * * * Edit: I really was ready to talk. But I guess closing down threads to shut down debates is standard now. --- ## Post 11 by @jonah — 2026-03-11T15:54:57Z > [@Encounter5729](#): > > about wording Yes > [@Encounter5729](#): > > and scope No. That is here. I linked to all the sources above where everyone agreed we should make an exception for iOS, and I’ve explained here to you why such an exception would have to be worded like this. Your proposal is an _additional_ thing we are still discussing at [What should we require of VPN providers on macOS?](https://discuss.privacyguides.net/t/what-should-we-require-of-vpn-providers-on-macos/36175) so this thread would not be the place to discuss that change. If you don’t agree with the decision that we made then the only solution is to propose a better solution, not argue against past discussions. I think you already have proposed what you think is a better solution in that thread I just linked to, so that’s where we’re at now. At this point neither of us have anything else to explain about our positions, so we can leave this here for other people to decide for themselves, and we can focus on making additional changes in the #Site Development threads. That’s all we can do to keep things moving forward :+1: --- ## Post 12 by @jonah — 2026-03-11T15:55:00Z