💬 Discussion | new website requirements. #977
Comments
|
Please change this:
To this:
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. |
|
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. |
|
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. |
|
It might be nice to require, and also post of the site, an explanation of the threat model the app/service is aimed at. |
|
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. |
|
I think the templates will be the closure of this issue. Some are already used: |
|
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. |
Just because an issue is "closed" does not mean it has to stay closed. There are two downsides to closing-and-then-reopening:
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. |
|
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? |
|
Some users are using However it supports not closing issues with specific labels, so creating and adding # Issues with these labels will never be considered stale
exemptLabels:
- pinned
- security |
|
Has anyone been thinking this or is going to bring this forwards? How? |
|
@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. 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. |
This comment has been minimized.
This comment has been minimized.
|
This is more of a social problem, but could we please add a requirement to report issues either by:
|
|
Hi I want to translat the website to Hebrew so the folk's on Israel will enjoy pito |
|
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). |
|
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. |
|
I wonder if https://github.com/privacytoolsIO/privacytools.io/issues/987 is very loosely related here? |
|
+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? |
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. |
|
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? |
|
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. |
|
@blacklight447-ptio The requirements should also cover sponsors, as to avoid issues in the future such as #2110 . |
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.
The text was updated successfully, but these errors were encountered: