I’d like to know if there are particular GitHub workflows that are standard practice in particular, but also if anyone has tips about how to determine who works on what, how to think through the order things get worked on…anything really!

For distributing tasks i’d probably try to brainstorm with the group. Write it down, prioritize and then go for a kanban like approach using trello or wekan. I don’t have experience in that regard but thats what I would try.

I second the kanban-like approach (have an affinity for trello myself).

Another thing I’ve found really helps is if you can link to something to reverse engineer, even if it’s just an aspect of the overall app. That way everyone is looking and thinking about the same thing and it becomes much more accessible for people to contribute. Also using numbers for features helps make it more structured as well.

So at the end everyone has had an opportunity to contribute and you’ve got a features list which can then be translated into tasks on trello, and then team members can pair off and put their names on each task (if that’s how the team is structured).

TL;DR: Finding either another app (or at least something concrete everyone can imagine and work from) to reverse engineer and go from there really helps in group settings, especially for beginners. @codejunky showed me this style and it has worked pretty well in practice.

Decide early on if you want everyone to be a collaborator, or if you want to use the fork-and-pull workflow. (For a small group, I recommend collaborators.)

Branch early and branch often, and then delete your branches.

Open pull requests early and with minimal work to get the conversation started.

Figure out how you want to plan. Some really love boards like Trello, Projects, or ZenHub. I prefer keeping it simple with a ‘Tracking Issue’ for small projects. In my perfect world, a tracking issue has

an overview of the feature or project

a task list with smaller items that are being worked on

a separate issue linked from each smaller item

an assignee for each smaller item to own that part of the project.

Looping back around because I think it’s important - Make sure everyone has the same idea of your team’s GitHub Flow.

Big discussions in issues

Create a branch

Make a commit (or commits)

Open a pull request

Make more commits, give and get feedback

Merge (Decide who will do this. Is it going to be the person who opened the PR, after several approved reviews? Is there someone who will always merge? I prefer the former.)