💬 Discussion | new website requirements. #977

New Issue

jonah · 2019-06-07T10:11:22Z

blacklight447 commented

2019-06-07 10:11:22 +00:00

(Migrated from github.com)

After some internal thoughts of mine, and a following discussion on our matrix chat. I would like to propose the following policies for inclusion on our website:

1. introduce a requirement where a user suggesting new software or providers should have done his own research and cite his source. This could include things like privacy policies, links to software source, an explanation of how the software basically works and why it should be added. Any issue that does not provide sufficient sources should be closed until the anyone has made proper chances according to the policy. If the chance has not been made within 24 hours. the issue will be closed until it is fixed.

2. Introduce a limit on how many software or services should be listed. How many recommendations and how many worth mentioning s could differ from category to category.

Reason for policy 1:
Since privacytoolsIO is a volunteer project, it requires us to research new projects in our own free time. While I like to say that our team is capable of properly reviewing and researching a given project, we don't have the time to research every project or service mentioned to us. Right now, users can upon up an issue and recommend a service, and leave it up to us to research it come up with reason why a project should NOT be added.

I would like to flip it over, and make it up to the user to provide proper sources, explanation, and argumentation, of why a project should be listed. This would reduce our workload, and make sure uses think twice and properly review their own recommendations before opening up an issue.

Reason for policy 2:
With every project that gets added to privacytoolsIO, we gain a burden. The burden is that if a listed project turns out to be malicious or abandoned, it hurts our credibility. Locking the amount of recommendations and worth mentioning's would prevent us from become a global catalog of everything that claims to be privacy friendly, and making the site cluttered.

When this is combined with policy 1, a user should provide argumentation on why their project is better then one project that is already listed (if all slots are already full). This would cause that listed projects come back on the chopping block once in a while, and see if they still hold up as the best solution, or if they should be replaced. This will end up in us having more up to date recommendations, and make sure that the things we recommend are still what they were when they were added, and are one of the best options right now.

More thoughts:
How many worth mentioning s and actual recommendations should be allowed for any category should be decided in this discussion, as there may be reasons for one category to provide more options then compared to others (messengers with widely varying threat models come to mind).

Conclusion:
I think that if we were to introduce these two policies (add a limit to number of category listings and require a user to do research with source and proper argumentation), it would heavily reduce the workload put on the team, while improving the content/recommendations that end up on the website. These were just my thoughts, I would really like to know what the community thinks of this plan, and if it would be a good idea to make these requirements.

After some internal thoughts of mine, and a following discussion on our matrix chat. I would like to propose the following policies for inclusion on our website: **1.** introduce a requirement where a user suggesting new software or providers should have done his own research and cite his source. This could include things like privacy policies, links to software source, an explanation of how the software basically works and why it should be added. Any issue that does not provide sufficient sources should be closed until the anyone has made proper chances according to the policy. If the chance has not been made within 24 hours. the issue will be closed until it is fixed. **2.** Introduce a limit on how many software or services should be listed. How many recommendations and how many worth mentioning s could differ from category to category. **Reason for policy 1:** Since privacytoolsIO is a volunteer project, it requires us to research new projects in our own free time. While I like to say that our team is capable of properly reviewing and researching a given project, we don't have the time to research every project or service mentioned to us. Right now, users can upon up an issue and recommend a service, and leave it up to us to research it come up with reason why a project should NOT be added. I would like to flip it over, and make it up to the user to provide proper sources, explanation, and argumentation, of why a project should be listed. This would reduce our workload, and make sure uses think twice and properly review their own recommendations before opening up an issue. **Reason for policy 2:** With every project that gets added to privacytoolsIO, we gain a burden. The burden is that if a listed project turns out to be malicious or abandoned, it hurts our credibility. Locking the amount of recommendations and worth mentioning's would prevent us from become a global catalog of everything that claims to be privacy friendly, and making the site cluttered. When this is combined with policy 1, a user should provide argumentation on why their project is better then one project that is already listed (if all slots are already full). This would cause that listed projects come back on the chopping block once in a while, and see if they still hold up as the best solution, or if they should be replaced. This will end up in us having more up to date recommendations, and make sure that the things we recommend are still what they were when they were added, and are one of the best options right now. **More thoughts:** How many worth mentioning s and actual recommendations should be allowed for any category should be decided in this discussion, as there may be reasons for one category to provide more options then compared to others (messengers with widely varying threat models come to mind). **Conclusion:** I think that if we were to introduce these two policies (add a limit to number of category listings and require a user to do research with source and proper argumentation), it would heavily reduce the workload put on the team, while improving the content/recommendations that end up on the website. These were just my thoughts, I would really like to know what the community thinks of this plan, and if it would be a good idea to make these requirements.

👍 9 ❤️ 3

five-c-d commented

2019-06-07 14:28:10 +00:00

(Migrated from github.com)

Please change this:

...Any issue that does not provide this should be closed until the user has made proper chances according to the policy.

To this:

...Any issue that does not provide sufficient sources, should be closed until ~~the~~ any user has made proper changes, according to the policy.

That allows a person to submit a tool without doing the research-legwork themselves, but if nobody steps up and does the research (the OP or any commenter), the issue can be closed tentatively. If at some later point, ANY person (the OP or any commenter) does do enough legwork (SUFFICIENT as opposed to EXHAUSTIVE... we explicitly want the definition of what counts as "sufficient" research-legwork to be up to the core team), the issue can be re-opened.

Please change this: 1. ...Any issue that does not provide this should be closed until the user has made proper chances according to the policy. To this: 1. ...Any issue that does not provide <ins>sufficient</ins> sources, should be closed until <s>the</s> <ins>any</ins> user has made proper changes, according to the policy. That allows a person to submit a tool without doing the research-legwork themselves, but if nobody steps up and does the research (the OP or any commenter), the issue can be closed tentatively. If at some later point, ANY person (the OP or any commenter) does do enough legwork (SUFFICIENT as opposed to EXHAUSTIVE... we explicitly want the definition of what counts as "sufficient" research-legwork to be up to the core team), the issue can be re-opened.

👍 2

blacklight447 commented

2019-06-07 14:59:00 +00:00

(Migrated from github.com)

Well the problem i have is that the burden of research is often placed on us, then the initiator is no where to be found, ill change it, but i would add a requirement that another users should add sufficient sources within 24 hours.

👍 1

vecna13 commented

2019-06-07 14:59:57 +00:00

(Migrated from github.com)

These new policies seem reasonable to me.

I think "worth mentioning"s are very useful, particularly because they give users who have some issue with the given recommendations a lead on other things that might work for them. I don't know how many I think should be included/allowed, though.

These new policies seem reasonable to me. I think "worth mentioning"s are very useful, particularly because they give users who have some issue with the given recommendations a lead on other things that might work for them. I don't know how many I think should be included/allowed, though.

ghost commented

2019-06-07 18:31:31 +00:00

(Migrated from github.com)

It might be nice to require, and also post of the site, an explanation of the threat model the app/service is aimed at.

👍 1

danarel commented

2019-06-07 23:02:46 +00:00

(Migrated from github.com)

How about creating a template, like you would for a pull request that people need to fill out when recommending apps? All of the requested info is there. If someone submits something and doesn't do the work, you can just close it and move on.

👍 1

Mikaela commented

2019-06-08 11:10:13 +00:00

(Migrated from github.com)

I think the templates will be the closure of this issue. Some are already used:

I think the templates will be the closure of this issue. Some are already used: * https://github.com/privacytoolsIO/privacytools.io/blob/master/.github/PULL_REQUEST_TEMPLATE.md * https://github.com/privacytoolsIO/privacytools.io/tree/master/.github/ISSUE_TEMPLATE

1xPdd commented

2019-06-11 12:56:28 +00:00

(Migrated from github.com)

This makes sense, though I might allow for more than 24 hours for the poster to revise their post with sufficient research

That aside, there should still be a place where someone can say, 'I've just discovered X or Y, what do people think?' That sort of thing will still be permitted somewhere on the forums, I hope.

This makes sense, though I might allow for more than 24 hours for the poster to revise their post with sufficient research That aside, there should still be a place where someone can say, 'I've just discovered X or Y, what do people think?' That sort of thing will still be permitted somewhere on the forums, I hope.

👍 1

five-c-d commented

2019-06-12 21:16:43 +00:00

(Migrated from github.com)

allow for more than 24 hours

Just because an issue is "closed" does not mean it has to stay closed. There are two downsides to closing-and-then-reopening:

everybody who commented on issue 99999 gets around four emails each time that happens: close-comment, close-confirmation, comment with sources, re-open comment.
while the issue IS closed it no longer shows up by default when a person views the github-issues (which only show the open stuff unless you manually change search-params)

So there is probably a correct number of hours NN which is (my guess) between 36 and 80 hours, from the time a new issue is opened until it should be "closed pending the somebody posting some additional source-links". If the number is too low, there will be a lot of pointless closed-at-9pm-then-reopened-the-next-morning-at-9am kind of traffic AND there will be a lower chance of things "incorrectly" closed staying closed due to out-of-sight-out-of-mind.

If the number is too high, on the other hand, all that happens is a bit of clutter in the default github-list ... with the advanced search-params and the github-templates / github-labels, it is possible to have customized and tune search results that show only stuff that is "worth paying attention unto".

If I had to pick a definitive number of hours to mandate, I would say 42 is the answer

Long enough that most regulars will have had a chance to see the open issue, but short enough it won't clutter things up as it sits stagnant.

My recommendation though, is to just set a lower-bound and an upper-bound, and let the privacyToolsIO folks use their discretion: if they believe a suggested tool is NOT likely to attract source-links, close the issue quickly... but leave it open for a minimum of X hours, to avoid discouraging the OP contributor, and when closing it, leave a gentle "feel free to post source-links and thanks for suggesting this but to prioritize our issue-count we triage listings without sufficient source-links by early-tentative-close... this can always be re-opened if more source-links are added in the OP or in the comment-section."

Other ones will be left open longer, but no more than a maximum of Y hours. Again, this is at the discretion of the privacyToolsIO core team folks... sometimes an issue will be left open because they want to remember to loop back to it and comment personally, other times it will be left open because they have a hunch sources ARE out there and hope a regular contributor will step up and do the legwork. But sooner or later, have a firm deadline of Y hours after which all issues do get closed, even if they are "real soon now" gonna have sources. Better not to have issues that are open months or years -- just close them, attach a github-label (like "definitely need to reopen this" or just "todo" or whatever), and leave the same nice friendly note about triage-and-prioritization.

My suggestions would be either 24 or 36 hours for X, preferably 36 to allow people that visit at a set time (lunch break or whatnot) to not miss seeing something by a few minutes thanks to daylight-savings-time in their country different from the OP's country, or whatever. And for Y, that could be as short as 42 hours and as long as 168 hours, but I think 99 hours is best ... it allows issues that are important to stay open, even if they are posted friday afternoon of a three-day-weekend or something, long enough to be seen by almost everybody. But the open issues never stagnate: they are either handled within the first 99 hours, or they are given the appropriated github-labels and then 'closed pending more source-materials'

p.s. Note that lower-bound 36 and upper-bound 99 hours is suitable for software-suggestion threads. For software-removal threads the numbers need to be MUCH longer, otherwise it will hinder the stability of the listings. And for discussion-threads, such as the one we are in now, I would argue for VERY high lower-and-upper bounds: 2 months and 6 months, maybe?

p.p.s. Speaking of listing-stability: if something is not listed at all, it should only be possible to add it to the listings in the worth-mentioning area. If something is already in worth-mentioning, a thread about moving it into the top3 should be treated like "software removal" because necessarily the promotion of tool XYZ into the top3, will result in the removal of an existing tool ABC that is currently in that top3 listing. Such decisions are not easy to make in 36 to 99 hours of commenting! But I think a decision about moving a tool from "not mentioned at all" into the portion of the listings where it is "worth mentioning" should be fairly easy to manage in under 100 hours... and if not, close the issue until sufficient source-links ARE put on the table, and a decision CAN be made to greenlight the tool, or not to do so.

> allow for more than 24 hours Just because an issue is "closed" does not mean it has to stay closed. There are two downsides to closing-and-then-reopening: 1. everybody who commented on issue 99999 gets around four emails each time that happens: close-comment, close-confirmation, comment with sources, re-open comment. 2. while the issue IS closed it no longer shows up by default when a person views the github-issues (which only show the open stuff unless you manually change search-params) So there is probably a correct number of hours NN which is (my guess) between 36 and 80 hours, from the time a new issue is opened until it should be "closed pending the somebody posting some additional source-links". If the number is too low, there will be a lot of pointless closed-at-9pm-then-reopened-the-next-morning-at-9am kind of traffic AND there will be a lower chance of things "incorrectly" closed staying closed due to out-of-sight-out-of-mind. If the number is too high, on the other hand, all that happens is a bit of clutter in the default github-list ... with the advanced search-params and the github-templates / github-labels, it is possible to have customized and tune search results that show only stuff that is "worth paying attention unto". If I had to pick a definitive number of hours to mandate, I would say 42 is the answer Long enough that most regulars will have had a chance to see the open issue, but short enough it won't clutter things up as it sits stagnant. My recommendation though, is to just set a lower-bound and an upper-bound, and let the privacyToolsIO folks use their discretion: if they believe a suggested tool is NOT likely to attract source-links, close the issue quickly... but leave it open for a minimum of X hours, to avoid discouraging the OP contributor, and when closing it, leave a gentle "feel free to post source-links and thanks for suggesting this but to prioritize our issue-count we triage listings without sufficient source-links by early-tentative-close... this can always be re-opened if more source-links are added in the OP or in the comment-section." Other ones will be left open longer, but no more than a maximum of Y hours. Again, this is at the discretion of the privacyToolsIO core team folks... sometimes an issue will be left open because they want to remember to loop back to it and comment personally, other times it will be left open because they have a hunch sources ARE out there and hope a regular contributor will step up and do the legwork. But sooner or later, have a firm deadline of Y hours after which all issues *do* get closed, even if they are "real soon now" gonna have sources. Better not to have issues that are open months or years -- just close them, attach a github-label (like "definitely need to reopen this" or just "todo" or whatever), and leave the same nice friendly note about triage-and-prioritization. My suggestions would be either 24 or 36 hours for X, preferably 36 to allow people that visit at a set time (lunch break or whatnot) to not miss seeing something by a few minutes thanks to daylight-savings-time in their country different from the OP's country, or whatever. And for Y, that could be as short as 42 hours and as long as 168 hours, but I think 99 hours is best ... it allows issues that are important to stay open, even if they are posted friday afternoon of a three-day-weekend or something, long enough to be seen by almost everybody. But the open issues never stagnate: they are either handled within the first 99 hours, or they are given the appropriated github-labels and then 'closed pending more source-materials' p.s. Note that lower-bound 36 and upper-bound 99 hours is suitable for software-suggestion threads. For software-*removal* threads the numbers need to be MUCH longer, otherwise it will hinder the stability of the listings. And for discussion-threads, such as the one we are in now, I would argue for VERY high lower-and-upper bounds: 2 months and 6 months, maybe? p.p.s. Speaking of listing-stability: if something is not listed at all, it should only be possible to add it to the listings in the worth-mentioning area. If something is already in worth-mentioning, a thread about moving it into the top3 should be treated like "software removal" because necessarily the promotion of tool XYZ into the top3, will result in the removal of an existing tool ABC that is *currently* in that top3 listing. Such decisions are not easy to make in 36 to 99 hours of commenting! But I think a decision about moving a tool from "not mentioned at all" into the portion of the listings where it is "worth mentioning" should be fairly easy to manage in under 100 hours... and if not, close the issue until sufficient source-links ARE put on the table, and a decision CAN be made to greenlight the tool, or not to do so.

ghost commented

2019-06-13 18:50:26 +00:00

(Migrated from github.com)

How about instead of closing it right away making it one week so there's sure to be at least one weekend to find time to do the requested extra research and then add a label for issues waiting for more research to be added. Then close it if it still doesn't live up to the requirements after a week from when then request was made for more info?

Mikaela commented

2019-06-16 08:56:04 +00:00

(Migrated from github.com)

Some users are using ~~GitHub's~~ Protobot's stale bot integration that can automate issue closing, but I find it unfriendly from reporter point of view even if it would save time on this side.

However it supports not closing issues with specific labels, so creating and adding nostale label would be trivial

# Issues with these labels will never be considered stale
exemptLabels:
  - pinned
  - security

Some users are using [~~GitHub's~~ Protobot's stale bot integration](https://github.com/apps/stale) that can automate issue closing, but I find it unfriendly from reporter point of view even if it would save time on this side. However it supports not closing issues with specific labels, so creating and adding `nostale` label would be trivial ```yml # Issues with these labels will never be considered stale exemptLabels: - pinned - security ```

Mikaela commented

2019-07-02 10:23:40 +00:00

(Migrated from github.com)

Has anyone been thinking this or is going to bring this forwards? How?

Has anyone been thinking this or is going to bring this forwards? How? * Templates? https://github.com/privacytoolsIO/privacytools.io/issues/977#issuecomment-500116021 * https://github.com/apps/stale ? https://github.com/privacytoolsIO/privacytools.io/issues/977#issuecomment-502433728

👍 2

jkhgvfgvsth commented

2019-07-04 18:27:50 +00:00

(Migrated from github.com)

@blacklight447-ptio I think the template for issues should include the link to source code.

Plus, any form of reason to believe it is free software.
As it must be prioritized according to the contributing guidelines.

If it is proprietary, then the issue must disclose this.

If it doesn't clarify this then it should be closed until we can give it a full in depth review.

@blacklight447-ptio I think the template for issues should include the link to source code. Plus, any form of reason to believe it is free software. As it must be prioritized according to the contributing guidelines. If it is proprietary, then the issue must disclose this. If it doesn't clarify this then it should be closed until we can give it a full in depth review.

Mikaela commented

2019-07-19 17:46:06 +00:00

(Migrated from github.com)

While a bit offtopic, could we finally update issue template to request discussions to be opened to https://forum.privacytools.io/ instead or accept when to close discussions?

There currently seem to be 14 open Discussions of 196 issues, so it may not be a big issue, but I think it could be a small help in longer term and the label predates the forum.

While a bit offtopic, could we finally update issue template to request discussions to be opened to https://forum.privacytools.io/ instead or accept when to close discussions? There currently seem to be 14 open Discussions of 196 issues, so it may not be a big issue, but I think it could be a small help in longer term and the label predates the forum.

👍 1

Mikaela commented

2019-08-30 09:12:25 +00:00

(Migrated from github.com)

This is more of a social problem, but could we please add a requirement to report issues either by:

opening an issue or commenting here or
if you absolutely refuse to use GitHub or GitHub bans you (https://github.com/privacytoolsIO/privacytools.io/issues/1062), you do it somewhere that causes a notification to team members (pinging/mentioning them), so it's not easy to miss due to not following Reddit or feeling like ignoring clicktrapping title etc.?

This is more of a social problem, but could we please add a requirement to report issues either by: * opening an issue or commenting here *or* * if you absolutely refuse to use GitHub or GitHub bans you (https://github.com/privacytoolsIO/privacytools.io/issues/1062), you do it somewhere that causes a notification to team members (pinging/mentioning them), so it's not easy to miss due to not following Reddit or feeling like ignoring clicktrapping title etc.?

👍 1

jollyr1 commented

2019-09-05 13:22:33 +00:00

(Migrated from github.com)

Hi I want to translat the website to Hebrew so the folk's on Israel will enjoy pito

❤️ 1

Mikaela commented

2019-09-05 15:57:08 +00:00

(Migrated from github.com)

Hi, thank you for your interest, but I would currently advice against translating the website as while the translation processc an be done by forking, it will be painful to keep it up-to-date.

https://github.com/privacytoolsIO/privacytools.io/issues/1106 / https://github.com/privacytoolsIO/privacytools.io/pull/1105 should make the website a lot more easy to translate and maintain. I hope you can wait for it. I cannot give any promises on the time though (and I haven't been involved with the process).

Hi, thank you for your interest, but I would currently advice against translating the website as while the translation processc an be done by forking, it will be painful to keep it up-to-date. https://github.com/privacytoolsIO/privacytools.io/issues/1106 / https://github.com/privacytoolsIO/privacytools.io/pull/1105 should make the website a lot more easy to translate and maintain. I hope you can wait for it. I cannot give any promises on the time though (and I haven't been involved with the process).

👍 1

Mikaela commented

2020-02-10 17:15:27 +00:00

(Migrated from github.com)

In #1642 it was asked what is the missing research and I am confused as this issue is still open and not much discussion has been happening (while there are good reasons to focus on the COI policy).

I think in ideal world the team members would audit the software and see if it's doing anything malicious, but I am not able to read or write code without even thinking about auditing and I think it would be a hard work or there wouldn't be auditing businesses.

Lacking that I am more or less going by whether I think something is reputable or I trust it, but still I am possibly overly careful about making PRs or suggestions or approving them as I don't know if they are secure as I can do little more than read their marketing claims and maybe use a search engine on them.

In #1642 it was asked what is the missing research and I am confused as this issue is still open and not much discussion has been happening (while there are good reasons to focus on the COI policy). I think in ideal world the team members would audit the software and see if it's doing anything malicious, but I am not able to read or write code without even thinking about auditing and I think it would be a hard work or there wouldn't be auditing businesses. Lacking that I am more or less going by whether I think something is reputable or I trust it, but still I am possibly overly careful about making PRs or suggestions or approving them as I don't know if they are secure as I can do little more than read their marketing claims and maybe use a search engine on them.

Mikaela commented

2020-02-11 21:27:08 +00:00

(Migrated from github.com)

I wonder if https://github.com/privacytoolsIO/privacytools.io/issues/987 is very loosely related here?

strypey commented

2020-02-20 06:59:52 +00:00

(Migrated from github.com)

+1 for limiting the number of recommendations each page, and for setting a unique limit as appropriate to each category. For fediverse.party, we have the attitude that we are curating a guide for beginners, not an exhaustive list of All That Exists. Wikis (and Awesome Lists) are better for that. In fact we have a wiki where team members and drive-bys can add our research to more verbose lists, which then contribute to the decision-making about what goes on the site.

As for the recommendation process for apps or services to be added to PTIO, I suggest encouraging folks to open a forum thread as step 1. Then, when sufficient information has surfaced in that thread, it can be escalated to a GH issue. Perhaps opening GH issues could even be limited to core team members?

+1 for limiting the number of recommendations each page, and for setting a unique limit as appropriate to each category. For fediverse.party, we have the attitude that we are curating a guide for beginners, not an exhaustive list of All That Exists. Wikis (and Awesome Lists) are better for that. In fact we have a [wiki where team members and drive-bys can add our research](https://git.feneas.org/feneas/fediverse/-/wikis/watchlist-for-activitypub-apps) to more verbose lists, which then contribute to the decision-making about what goes on the site. As for the recommendation process for apps or services to be added to PTIO, I suggest encouraging folks to open a forum thread as step 1. Then, when sufficient information has surfaced in that thread, it can be escalated to a GH issue. Perhaps opening GH issues could even be limited to core team members?

jonah commented

2020-02-21 23:32:21 +00:00

Wikis (and Awesome Lists) are better for that. In fact we have a wiki where team members and drive-bys can add our research to more verbose lists, which then contribute to the decision-making about what goes on the site.

This is potentially what I would like to happen long-term with wiki.privacytools.io but we are still in the early stages of getting that site up and deciding what our goals for that site will be.

> Wikis (and Awesome Lists) are better for that. In fact we have a wiki where team members and drive-bys can add our research to more verbose lists, which then contribute to the decision-making about what goes on the site. This is potentially what *I* would like to happen long-term with wiki.privacytools.io but we are still in the early stages of getting that site up and deciding what our goals for that site will be.

👍 2

blacklight447 commented

2020-03-02 12:25:08 +00:00

(Migrated from github.com)

AS of now, we are in the progress to make a criteria list for each section, starting with the providers section. after this is completed, and we delisted the software no longer up to our standards, we should be able to set a good limit on the software and providers.

GintokiHub commented

2020-11-09 07:25:46 +00:00

(Migrated from github.com)

AS of now, we are in the progress to make a criteria list for each section, starting with the providers section. after this is completed, and we delisted the software no longer up to our standards, we should be able to set a good limit on the software and providers.

would love to have a look are they somewhere public?

> AS of now, we are in the progress to make a criteria list for each section, starting with the providers section. after this is completed, and we delisted the software no longer up to our standards, we should be able to set a good limit on the software and providers. would love to have a look are they somewhere public?

Victor239 commented

2020-11-23 02:02:42 +00:00

(Migrated from github.com)

Moving the software which doesn't reach the cut to the wiki, and linking back to the GitHub issues where they've been previously discussed is a good way to organise the info on each topic in case advanced users want to learn more about the alternatives.

ghost commented

2020-11-23 03:39:08 +00:00

(Migrated from github.com)

@blacklight447-ptio The requirements should also cover sponsors, as to avoid issues in the future such as #2110 .

freddy-m commented

2020-11-27 14:17:53 +00:00

(Migrated from github.com)

Before I was a team member here, I helped create the criteria for degoogle (#131). We could use this as a bare bones template to adapt for other sections...

Before I was a team member here, I helped create the criteria for [degoogle](https://github.com/tycrek/degoogle) ([#131](https://github.com/tycrek/degoogle/issues/131)). We could use this as a bare bones template to adapt for other sections...

This repo is archived. You cannot comment on issues.