Move warden and team registration to another repo and include as git submodule

[adamavenir]

Problem/opportunity:

• As we expand write access to the site to include more community support and process around onboarding new wardens, permissions get messier.
• Having a 100% public warden application review process is different from how we handle other applications and may lead to awkward scenarios
• Notifications of warden application activity adds a lot of noise to the website repo and website dev activity adds a lot of noise to the application review process

Desired outcome

• Warden application reviewers have robust access to be able to review and merge applications without also having full write access to the website and other C4 data
• Warden application reviewers are able to use GitHub to openly review and discuss applications that they are on the fence about.

Proposed solution:

• separate private repo for warden applications and data (ie github.com/code-423n4/wardens)
• import as submodule into site repo
• use github actions to trigger website deploys when there is a new merge in wardens repo
• create warden application review GitHub team to manage permissions
• use private GitHub PR discussions to review warden applications

[Simon-Busch]

Here is a task list I gathered to help the dev process when we can start.

Can you let me know what you think about it ? @sockdrawermoney as you are familiar with it ? @joshuashort ?

repo:

• Create private repo « wardens »
• In parent (C4), instantiate submodule
• Move all data from _data/handles to newly created repo
• Link submodule to c4.com in _data/handles

function:

• Adapt register warden function for the new repo
• Adapt register team function
• Create GitHub action from C4.com to specifically update submodule ( || merge once every 12H ? )

Deploy:

• Check Netlify function ?

C4 Org:

• Add new roles and spefic authorization to wardens || helpers with rights only on this newly created repo

[adamavenir]

Use git filter-branch --subdirectory-filter for the purposes of preserving commit history.

Docs here

Google for this command and "submodule" and you'll find a few guides.

[adamavenir]

Just bumping this issue as one that someone might consider during cooldown. I don't think it's a major task and it would be nice to split the streams of incoming PRs.