fold mochajs.github.io into this repo

[boneskull]

GH Pages now supports docs/ since whenever.

I propose we fold that repo into this one, because:

1. Discoverability is an issue if the docs live in a separate repo.
2. The alternative is a gh-pages branch, but it's plainly silly to maintain a branch with a completely separate VCS root.

Potential drawbacks:

1. Tooling on that repo is kind of iffy.
2. May need to manually move some issues over.

What does @mochajs/core think?

[dasilvacontin]

LGTM. I like that PRs can update the docs at the same time.

[ScottFreeCode]

The pros definitely outweigh the potential cons here.

Only one minor thing to consider, re. concern # 1: If the site currently requires additional tooling of some sort instead of just updating Markdown and/or HTML files, we may want to figure out how to cut that out first in the existing repo and then copy the page source files over into this one, so we don't have to add anything here but the page source files.

But I think ultimately, as long as we aren't adding anything to the package.json of the main project (e.g. if any needed tooling can go inside docs), it's not a dealbreaker either way.

[boneskull]

it wouldn't add any production deps anyhow. would prefer to keep the dev deps all together so a contributor doesn't need to npm install from docs/. agree?

[dasilvacontin]

Agree. It doesn't hurt afaik. The simpler for the contributor/maintainer the better.

…

On 5 Sep 2017, at 18:03, Christopher Hiller ***@***.***> wrote: it wouldn't add any production deps anyhow. would prefer to keep the dev deps all together so a contributor doesn't need to npm install from docs/. agree? ― You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ScottFreeCode]

Hmm. I was thinking of avoiding adding to our already lengthy dev install times e.g. in CI, but simplicity for contributors is a compelling argument. Well, in that case, I'm fine bringing it over here as-is to start with and we can look at any potential for trimming dependencies later.