Create policy of what things will be listed on awesome-ipfs

[victorb]

So far, we have a technical checklist and also some in-head (me and my opinion) policy on what to merge and what to reject.

What we should do is to have a POLICY.md which clearly outlines what will be accepted and what will be rejected, so anyone can start managing and merging PRs here.

As a first step, we definitely want entries to follow our "Code of Conduct", but we might want to make it even stricter in terms of what goes into this list.

[flyingzumwalt]

The Code of Conduct is a good starting point. I want to go a bit further than that. This site's curatorial guidelines should be more restrictive than the code of conduct. Accepting something into the listings on this site is actively acknowledging it as part of our ecosystem, which will be seen as endorsement.

I'm not sure how to word this in a policy, but we specifically will reject or remove anything that is promoting or actively encouraging hate speech (including doxxing, revenge porn, etc), facism, child pornography, copyright infringement. We will also block anything that is malware, or whose purpose is to distribute malware.

The copyright infringement is covered by the Copyright Violations portion of the Code of Conduct. The others are arguably covered by the Friendly Harassment-Free Space section, but if we're establishing guidelines for people who are moderating this repo I want to be explicit about it.

[autonome]

I'm not sure how to word this in a policy

What you wrote sounds like a great place to start. Far better than just pointing at the CoC.

We specifically will reject or remove anything that is promoting or actively encouraging hate speech (including doxxing, revenge porn, etc), facism, child pornography, copyright infringement. We will also block anything that is malware, or whose purpose is to distribute malware.

If we have a POLICY.md with a link to CoC and the text above, would be a viable first step?

[hacdias]

What's the state of this?

[leshokunin]

I've looked into this, this week. I actually think the main issue with awesome-ipfs is that it's a silly amount of work to update. It's literally just a list of links, but it requires pulling the repo, updating, making a build, making a pull request. Without wanting to sound too negative, no amount of exclamation marks, smileys and tutorials is going to make this feel usable.

I've been thinking it'd be significantly simpler to just have the raw list on the repo, with some instructions how to add links and what's ok to add. One issue with this approach will be the lack of yaml tags that are used for awesome.ipfs.io. Wdyt?

[hacdias]

Hey @leshokunin! Previously, when we didn't have the website, it was just needed to add to the README. Although we need the other information to generate the website. Do you have any idea on how to keep generating a website using a simpler way? If so, we're open to listening! 😃

[autonome]

The process for adding entries is definitely harder than it needs to be. However, that is not the goal of this particular issue. Please file a new issue for improvements in that flow.

In the GUI & In Web Browsers meeting today we discussed the conversation so far in this issue, and drafted an initial policy to have something simple in place that meets the minimal need. Having a basic policy in place will allow us to close this issue, and move forward with additional refinement in the future.

We explored the options by:

• reviewing the comments here so far
• talking about what we would reject and why
• exploring the pros and cons of detailed curation

This is the draft policy:

• Entries must respect the Code of Conduct
• Entries must use IPFS (libp2p, ipld, multiformats is not enough)
• Entries must be immediately usable (eg. nothing that is paywall only, even a free trial would be ok)
• Entries must have a clear license and/or privacy policy where applicable

This means a couple of things:

• We are not restricting on quantity (eg lots of IPFS introductory videos is fine)
• We are not restricting on quality (eg if there are Windows GUI apps and one is better, they both stay)
• We are not restricting on age (eg if a project is unmaintained - still has value)

There are some downsides to allowing all IPFS-related things here, but we can mitigate all those downsides in other ways: sorting, starring, grouping, etc. Better to encourage contribution generally, and build tools on top of the dataset for better curation after the fact.

Please comment if you have questions, concerns, suggestions!

[lidel]

Let's time box this, if there are no further suggestions till next wednesday, we will open a PR with POLICY.md

[2color]

The following PR makes further updates to the content policy: https://github.com/ipfs/awesome-ipfs/pull/478