Repo setup/permissions?

Question

Repo setup/permissions?

ckolderup opened this issue 10 months ago · comments

We're starting to bump up against some limitations of this being a repo that is owned by me and has no other contributors with access granted.

I'm reluctant to just throw a bunch of access at people just because they've been nice enough to contribute patches and suggestions so far, but it does seem like at least a few people are committed to helping out with this platform in at least the short term, so I'm starting to wonder what the best way to set things up is that will help us keep moving forward.

I'd love to hear what the other folks who have been contributing think about this-- am I jumping the gun? or would some of you like to be more involved? I think no matter what we should probably also set up a deadline for deciding on some kind of governance if we're going to start doing that, and resetting things as of that deadline under whatever rules we put in place. I'm just kind of leery of putting the cart before the horse and over-structuring things or asking anyone else to put in more volunteer labor than they're actually interested in.

(Also: maybe I should be opening the "Discussions" section for topics like this? 🤷)

Andy Piper · Answer 1 · Fri Sep 22 2023 17:20:47 GMT+0800 (China Standard Time)

I would be happy to be more involved. Entirely up to you how to choose to open that up.

Patrick O'Connor · Answer 2 · Sun Sep 24 2023 11:58:11 GMT+0800 (China Standard Time)

I'm content with with just sending over a PR every once in a while. Do you feel like the "limitations" are that PRs sit for too long before merging?

Casey Kolderup · Answer 3 · Sun Sep 24 2023 13:24:16 GMT+0800 (China Standard Time)

Sort of, yes-- my concerns are mostly threefold right now:

I don't like that PRs pile up for logistical reasons: lots of our changes are wide-reaching enough right now, which increases the likelihood of a merge conflict, which makes contributing harder/more tedious
I don't like that PRs pile up for emotional reasons: I want people to stay motivated and understand the gratefulness with which I take their contributions
I feel bad when I ask for very basic revisions to PRs because they exist as branches on forks that I can't edit to just resolve my own complaints about some small detail.

The cause of the limitations are mostly a scarcity of my own time and attention right now as the only one with repo access.

With people having collaborator access to the repo, we can add commits to each other's branches (and decide what level of trust we have together in doing that, obviously-- it'd be weird to just push a whole bunch of changes to someone else's PR that fundamentally change the approach or contradict a decision they made without consulting them first, but you can also signal good faith by volunteering to do something for someone on a branch when you have a suggestion that they then consent to)

I'm still working a day job and am in a busy period leading up to two back-to-back trips out of town (literally flying from a 5-day family wedding thing directly to a 2-day work offsite) which will mean I'm even less responsive to people's questions and PRs until at least Thursday, Oct 5. I'm going to try to stay in touch as best I can in that time, but I won't be in front of a computer very much.

I'm thinking it over and I think this is what I'm leaning towards:

(this step is done) I've added basic branch protections to the main branch to require things like linting checks passing and at least one code review on merges to it.
(going to do this right after I submit this comment) I make @johnholdun and @andypiper collaborators on this repo.
I am also happy to make @pburke and @steve-bate collaborators if they'd appreciate the ability to create branches & review code. If they'd rather stay how things are, that's also totally cool.
@PatOConnor43, I'll let you keep submitting upstream PRs from your fork as you've indicated for now. If you change your mind under this current setup, let me know.

As mentioned before, all of this is temporary pending a future revision of governance that we may want to consider if we (and anyone else who joins in!) find ourselves continuing to collaborate, up to and including moving this repo to a dedicated Github organization, etc.

Patrick B and Steve, give some indication when you have a chance if you're interested in access as mentioned above.

Thanks everyone!

Casey Kolderup · Answer 4 · Sun Sep 24 2023 13:59:32 GMT+0800 (China Standard Time)

I'll also go ahead and ping @benbrown to publicly gauge his interest level in increased access-- apologies for not including you initially Ben, a total mental hiccup 😖

Steve Bate · Answer 5 · Sun Sep 24 2023 21:12:22 GMT+0800 (China Standard Time)

Hello. Thanks for the offer! For now, I want to continue with the regular contributor status.

Patrick O'Connor · Answer 6 · Sun Sep 24 2023 22:51:03 GMT+0800 (China Standard Time)

This sounds to me. Thanks Casey!

Patrick Burke · Answer 7 · Mon Sep 25 2023 22:34:30 GMT+0800 (China Standard Time)

Thanks, Casey. I don't mind becoming a collaborator. I think I'll be more comfortable reviewing PRs once we know where you'd like to take the project. Maybe we can use Github Projects for planning?

Ben Brown · Answer 8 · Tue Sep 26 2023 23:22:03 GMT+0800 (China Standard Time)

I'll also go ahead and ping @benbrown to publicly gauge his interest level in increased access-- apologies for not including you initially Ben, a total mental hiccup 😖

bring it on

Casey Kolderup · Answer 9 · Wed Sep 27 2023 00:31:50 GMT+0800 (China Standard Time)

Thanks, Casey. I don't mind becoming a collaborator. I think I'll be more comfortable reviewing PRs once we know where you'd like to take the project. Maybe we can use Github Projects for planning?

@pburke I don't have a lot of experience with GH Projects but have obviously worked with plenty of similar platforms so I'll try to get acquainted with it soon!

Just to understand what you're looking for, would the main goal with using that be to communicate prioritization & ensure that people aren't doubling up effort on something, or is there some other feature of Projects that you have in mind that I should make sure to understand?

Patrick Burke · Answer 10 · Wed Sep 27 2023 23:24:23 GMT+0800 (China Standard Time)

Just to understand what you're looking for, would the main goal with using that be to communicate prioritization & ensure that people aren't doubling up effort on something, or is there some other feature of Projects that you have in mind that I should make sure to understand?

@ckolderup I think just to have a simple backlog and see what is higher priority, what is in progress, what is awaiting review, etc. Maybe it's too early for that level of detail? But it seems like there are enough open issues right now that even a minimal amount of organization and prioritization could be useful.

GH Projects can work as a kanban board where you can track issues & associated PRs through that lifecycle. I would say it's simpler than Trello, but more convenient since it's closely connected to the repo. IMO, it can make it easier to think about all the moving pieces of a project. The Project board only shows the things you add to it (which can be automated by label, milestone, etc) so feature requests or bug reports that haven't been triaged yet don't clutter it up.