On How to Run the Repository

[Philip-Clark]

Let's get a few ideas on how to run this repo.

Does everyone get maintainer status?
If not, then who does?
What type of rules should be put in place?
Should we set up something different?
Do you have ideas on how to make it better?

Make sure to introduce yourself with your discord tag in the Introductions discussion, it's the pinned announcement

[Ananth-Adhikarla]

everyone does not get the maintainer or full access, only those authorized will do.
who gets that maybe through voting or you decide it.
clean code with good commit messages and comments , dont sent 100s of commits make sure it works first then make a PR
make sure everyone works on their own branch and merge to master only when its good
rest depends on the project I suppose about what needs to be considered

[Philip-Clark]

Awesome input, thanks!

Ps: please make sure to introduce yourself with your discord tag in the Introductions discussion.

[Philip-Clark]

Addressing the maintainers issue. I feel like voting would work fine for now.
I think I will put up a poll to get feedback on whether this should be the way they are chosen though.

[Ananth-Adhikarla]

sure but its kind of early to start voting or selecting maintainers. Need to do that when the project gets decided on and how many people are available at that moment in time.

[Philip-Clark]

sure but its kind of early to start voting or selecting maintainers. Need to do that when the project gets decided on and how many people are available at that moment in time.

Ah yes. I meant the method. Voting on maintainers should definitely take place at the very least after the entry form has closed.

[ManorSailor]

clean code with good commit messages and comments

Apparently, it will be a good idea to follow some guidelines like Conventional Commits or any other guides for readable commits.

[JoshDevHub]

I probably recommend restricting full access but that might depend on how many people are going to be contributing. I do think that main should only get merged to via reviewed PRs (same as the way TOP does it), and that even contributors with privileged access shouldn't bypass that.

I also recommend using Projects board to track Issues and delegate work. How exactly this will look is going to depend a lot on what project gets chosen.

And speaking of that, definitely recommend throwing up a discussion on what project to choose after you're able to sort through the suggestions from that google form.

[taladan]

I agree with all of this. I would probably suggest that maybe a couple or three experienced people be responsible for reviewing PRs and merging.

[Philip-Clark]

Thanks for the input. I agree.
I think a poll might work nicely for voting on what project to do, but we will be discussing it one way or another.

Ps: please make sure to introduce yourself with your discord tag in the Introductions discussion.

[Philip-Clark]

@Ananth-Adhikarla brought up a good question. Should this repo be private or public?

I reasoned that it would be nice to be able to point to PR's and specific areas that one worked on, as this will hopefully be a project we are all proud of and want to talk about. But I could also see the benefits of making this private.

Thoughts?

[JoshDevHub]

I think it's definitely important that it's eventually public because yeah, it would be nice to point work done on this project.

Maybe it can be moved to private until there's some sort of minimal viable product, if we didn't want outsiders wondering in or something while that's being developed. I personally don't think that's something to be very concerned with though. So consider me pro-public repo.

[Aureatus]

Also pro-public repo here, I don't think it would hamper us in any way.

[taladan]

Pro-public here...when the project gets big enough to be noticed, it will likely have some useful functionality to it at that point.

[01zulfi]

Opensource all the way 🚀

Additionally, it would be fun if the project remains open to outside contributions throughout its development.

All of the above is just my opinion of course.

[MarchandMD]

+1 open source/public repo

[Philip-Clark]

Should @Club-40/maintainers get Maintainer privileges or Admin privileges?

Should there be an Admin Team? Or just a few people with said privilege

Should @Club-40/front-end-developers and @Club-40/back-end-developers get Write access or just Triage access?

Terms described here : ( https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization#repository-roles-for-organizations )

[Philip-Clark]

@Ananth-Adhikarla suggested the following via discord

people who maintain the project, maintain the kanban board ( add new tasks, close finished tasks etc.) , reviewing code, merging pull requests
should get owner role. rest member role with write access to allow creating branches and making pull requests etc.
( https://discord.com/channels/505093832157691914/1091794976045813770/1093238264682524822 )

I have implemented these suggestions, but feel free to critique this choice.

[JustWaveThings]

I am good with write access as FE contributor. I don't know how much extra work having people with triage access would create above them.

[fcasibu]

I agree with everyone here.

Maybe we can change a little bit the rules for PRs:

• Let's change how we work with pull requests. Maintainers can be reviewers but the developers should also be the ones that are reviewing the PR since they're closer to it or have worked with the code (wrote this because contributing guide of TOP only has maintainers as reviewers)
• Let's try not to pollute the PR, when trying to address a comment/suggestion, use emojis like 👍 but if it's more technical and needs a detailed comment then it's fine to comment on it
• Reviewers should be the ones to resolve their own comments/suggestions because they're the ones that need to check if changes are correct
• Delegate merging/closing of PR to the creator of the PR. Just less work from maintainers I guess? Since we don't really merge PRs unless it's approved by maybe x amount of reviewers (maintainers/devs who have this permission to approve) this should work right?
• PR author is responsible for resolving merge conflicts

[crespire]

One thing that can help to make sure that changes are moving in the right direction, or if they can be merged with confidence is to provide either testing to accompany your changes (which I don't think may make sense when the project is still getting started), but also for changes to user facing elements, providing screenshots or videos (I use short Loom videos at work) of the changes. Providing that visual context for frontend changes can help the reviewer focus in on important code areas to focus on. For backend changes, I also think a template for PRs similar to what Odin provides would be good. At the end of the day, a review is a back and fourth process.

I agree that merge conflicts should be resolved by the PR author, but sometimes they can happen after code review, so make sure to flag any changes before merging if that's the case.

These two companion blogs form the foundation of my approach to thinking about code reviews:

• https://mtlynch.io/human-code-reviews-1/
• https://mtlynch.io/human-code-reviews-2/

[Lofty-Brambles]

Great call on those Micheal Lynch articles, Simmon!