How do we want to handle pull requests?

[TaylorAnderson]

I think I know the answer to this but I just want to put it out there publicly -- @iznaut I know you've said that you don't want to be the bottleneck for merging stuff, should whoever's making the PR just go ahead and merge the PR themselves if the checks are passed? Or do you want there to be some sort of oversight?

[iznaut]

thanks for bringing this up! i wish i had hammered out all these details before "going live" lmao

i think @lazerwalker is looking into the netlify issue (#8) - ideally, new contributors should do a PR and get a URL to a playable build, then someone who is already a "proper" contributor on the project can click that link and confirm it's working without any major issues.

if it looks fine upon testing, you can merge the PR and add the new contributor as a "proper" contributor to the project (so in the future, they can merge their own PRs and not have to wait for anyone else)

this is how i think it should work.....open to any other thoughts/feelings on how to make this sustainable and not rely on any one of us approving things all the time

[TaylorAnderson]

This makes a lot of sense to me! I'll wait until that netlify stuff is resolved and then take a look at the two PRs up right now

[iznaut]

if you don't mind doing a little extra legwork you can also just pull down the code from the PRs and test it locally - i wouldn't count on the netlify stuff being hammered out anytime soon lol

you can also just look over the code and make sure it looks alright - if the changes are minor it's probably not a major concern that something might break.

(i'd do all this myself but i have other life stuff to attend to - i appreciate you taking initiative here!!!)

[TaylorAnderson]

sure, will do!

[iznaut]

i wonder if it's worth setting some criteria around this process.....like you have to make a certain number of PRs or something before added as a "proper" contributor (are there proper terms for these things lol). it's an arbitrary requirement but it at least raises the barrier of entry just enough that you can't like, submit some minor change just to get unfettered access and then start wreaking havoc

i'm not THAT worried about bad actors, but i would rather have some ground rules set early and never need to worry about it then have something go wrong down the road and not be prepared. i think some small barrier is better than nothing (and folks who have their PRs approved but aren't on the project proper are still included in the overall count, right?)

it seems reasonable enough to be to only allow folks to be 100% autonomous once they've contributed a few times and established they have some investment in the work they're doing?

curious if @lazerwalker has any thoughts or opinions on this

[lazerwalker]

So, if a bad actor wants to fuck with this, it's going to be relatively easy no matter what, what we're really talking around here is how much of a wall we should put up that they need to jump over.

I'd be inclined to recommend one of two flows:

1. The "core contributor with merge ability" role is relatively small, so there's a decently-high level of trust for the people who are actually merging in PRs. This group still needs to be large enough to avoid bottlenecking, so there's a balance to strike there.

2. Anyone can be a "proper" contributor with a relatively low bar (probably more than 1 PR, but not much more than that), but we also have a policy of not merging in your own code (I don't know if we can programmatically enforce this, or just socially). I think raising the bar for a bad actor to make two accounts that do enough "real work" to get contributor access is a valuable one, and I also think it's useful to get a second set of eyes in the case of e.g. someone who isn't malicious just having poor judgement about what might be offensive or in bad taste.

I suspect (2) is more the vibe you want to foster!

[lazerwalker]

One other thing to think about: if someone wants to merge in offensive content, what's the governance process? You being the benevolent dictator is extremely reasonable, and having a small trusted circle to act as mods might also help lift that load off of you. Having a code of conduct to point people towards might also help resolve conflicts of "what isn't acceptable here?"

https://www.contributor-covenant.org/ is solid prior art here.

[paulloz]

Whatever end up being decided regarding when to give people ✌️full access✌️, it's probably a good idea (if it's not already the case) to protect the main branch in order to ensure people go through PRs and not directly merge code in.

we also have a policy of not merging in your own code (I don't know if we can programmatically enforce this, or just socially)

I am pretty sure this can be done through GitHub PR settings.