Move Charter, process, contributing and other docs to this rep

[wesleytodd]

Both https://github.com/expressjs/express/pull/5509 and https://github.com/expressjs/express/pull/5510 are great examples of why I think we should move this out of the express repo. We shouldn't need to run CI for these .md file changes. Also, it would be nice to add some markdown linting type stuff and keeping that out of this repo would be great. And thirdly, it would mean we don't have as many changes going into the autogenerated change logs for the main package.

Thoughts?

[jonchurch]

There is a piece in #170 which suggests doing this. I am in favor.

Does OpenJSF have any guidance here? We could create a repo called governance to house that stuff. In fact, maybe this repo, discussions can be renamed to governance or meta as I can see this repo evolving in that direction.

The biggest downside I see is that governance changes will be a bit more opaque, as the PRs and diffs won't live in the express repo. I don't think that's a serious issue, as changing governance is not the same as changing licenses in terms of requiring visibility to consumers.

I suggest using/repurposing this repo simply to cut down on the overall number of repos to track

For reference, we currently have these markdown docs in the root dir of express repo:

• Charter.md
• Code-Of-Conduct.md
• Collaborator-Guide.md
• Contributing.md
• History.md
• Readme-Guide.md
• Readme.md
• Release-Process.md
• Security.md
• TC-Charter.md (this is in PR, not guaranteed to land https://github.com/expressjs/express/pull/5509)
• Triager-Guide.md

What wes has suggested would be to keep a subset of the above docs in Express (certainly History.md isn't going anywhere) and link out to the source available docs in another repo (Charter, Triager-Guide, Readme-Guide are all non-express specific IMO and are candidates to just being linked to).

[sheplu]

yes this would be great, but I would even suggest to create a dedicated repos for that (not sure about the name but discussion seems strange) This was part of this issue I opened https://github.com/expressjs/discussions/issues/170 (you can find Move all global document out of the express repository: but also part of the expectations)

[wesleytodd]

I think the thing is moving it out of repos we ship libraries out of, so I am not opposed to a new repo but also since we have this one I also don't see a reason not to use this one.

EDIT: so I guess that is to say, whoever has strong opinions on if it is here or a new repo go for it!

[sheplu]

I was thinking of a more "admin" repo, I just created it for some PR about official records and decision (which also could be used to keep track of all minutes for the express TC meeting - and maybe all working groups). But no strong opinion - mostly to separate more administrative stuff and more global discussion

[wesleytodd]

Ok, so lets call that decided then and we are going to move all the governence and policy docs there. We likely need to keep some files in place to link from all the repos, but by removing the content we can reduce churn in all the repos for these kinds of changes.

https://github.com/expressjs/Admin

[UlisesGascon]

Also, it would be nice to add some markdown linting type stuff and keeping that out of this repo would be great.

My 2 cents on the linting matter. I find quite solid the linting workflow for markdown in place in the TODO Group as also reviews expressions and non-inclusive language: https://github.com/todogroup/ospology/tree/main/.github/workflows

[jonchurch]

Ok, so lets call that decided then and we are going to move all the governence and policy docs there. We likely need to keep some files in place to link from all the repos, but by removing the content we can reduce churn in all the repos for these kinds of changes.

https://github.com/expressjs/Admin

Since wes said this we have realized we already have a .github repo and were discussing in https://github.com/expressjs/Admin/pull/2 if these docs should live there instead.

Im up for it. If we do we need to decide if we want to delete the actual files like CONTRIBUTING.md from the other repos so the "defaults" commited to the .github would automatically get displayed on github or just leave the actual source with links pointing to the source docs. There's only a small benefit to deleting existing ones which are eligible to fallback to the default, which is the doc always being up to date.

The specific files which are eligible to be used as defaults this way in github are listed in their docs

Im still in favor of having a single meta repo tbh, which would be merging discussions, .github, and admin all into one repo (which would have to be named .github if we want to leverage the default workflow/issue/CONTRIBUTING.md feature of github).

Does anyone have a compelling reason to have more than one non-source-code repo currently?

[wesleytodd]

Ah yeah I wasn't thinking about the shared thing with .github when discussing this. This is why I wish we had waited to create the new repo so we could gather this kind of feedback. The more I think about this the more I think the docs go in .github and the admin stuff goes in discussions. Idk, just important to keep things simple and have low duplication.

[wesleytodd]

I guess I didn't address the compelling reason to have more than one, I think the history in this discussions repo is the compelling reason. We don't want to make a new one because we don't want people to have to search multiple for convos. If we're going to do a different name that is all right, but we should move this repo not create a new one.

[jonchurch]

I introduced a third option about merging the .github, governance doc repo, and disucssions into a single repo to be used for all "meta" stuff. (it would be renaming discussions to .github so we dont lose history from discussions). Let's table that for now bc its distracting from the actual question...

Do we want to have separate repos for .github and governance docs?

I vote no. We should use .github repo for Governance docs. Because it allows us to leverage the Defaults behavior/convention that comes w/ that.