Org level documents

[Daeraxa]

Whilst making some PRs to update the website I realised there is probably a lot of crossover between some of the org level documents that were created when the org page was the homepage of the org.

Examples of files we might want to have on the website as well as on repos would be things like:

• FAQ
• CONTRIBUTING
• CODE_OF_CONDUCT - particularly as this would extend to all Repos, Discord, Reddit etc.
• SUPPORT

Further complicating matters is that there are copies of these in the Pulsar repo that are similar but different.

I see a couple of ways forward:

1. We maintain these in the org repo and add @includes to the website like we do with the assets.
2. We move these entirely into the website repo structure and just provide links to the website from the Org Readme.
3. We have some kind of GH action to read various org and repo .md files and incorporate them into the website repo structure.

My personal preference would be no. 2 as I'm all for trying to simplify where to find information as much as humanly possible without needing to rely on any scripts or other stuff that may inadvertently break through mistakes - e.g. if we were to do the @includes we would also need to make it clear that the website relies on this so any PRs need to be checked by the website/documentation team.

[GuilleW]

Agree, Repo is for maintaining the project. Most of dev will go directly to website to download and use it.
Communication about usage and feature on website with link 'Help us/Contribute' to github, and everything about maintain here.

[confused-Techie]

I'd vote for the direction we have been going, and that is to reference the files on our ORG Repo.

For example CONTRIBUTING.md we have already been changing the contents of that file to look like [See how you can contribute](https://github.com/pulsar-edit/.github/blob/main/CONTRIBUTING.md).

And I would vote we do the same to these other files. Then if we'd like duplicate, or use @includes on the site.

The reason I suggest going this route, is I feel like it gives us the most flexibility in how people can view them. Since if the site ever goes down, well it's still on the repo, and it's in an expected place to find. Anyone familiar with GitHub will look in .github for Org level information, anyone familiar with just OS will look in the repo, and find a helpful link, then anyone new to the scene will probably look at the website. Plus this way using @includes on the site (since the .github repo is already imported for images) we only have to maintain a single copy of these files, and there's no extra workflow to manage them.