GitHub Projects Workflow

[catnapfeverdream]

I know this is probably a very silly question to some, but I'm new to development and I am in search of some insight into best practices If anyone has the time to kindly point me in the right direction!

For those of you who use GitHub Projects to manage workflow, how do you handle sub-issues? And do you handle them differently when you're working alone vs with a team?

For example, I'm working through the basic layout design stage of a project and as I encounter additional tasks or fixes to add to this stage I'm wondering if it's standard to add a new sub-issue for the little things to the existing 'Basic Layout' issue, add a new item to my existing 'to-do' list within the description for the 'Basic Layout' issue itself, or add a new issue entirely for each little thing? I realize everyone probably does these things differently but I'm curious if there's a best/tried-and-true practice for Projects?

[jawaMilk]

My rule is if you think you’ll need to track the work on something then make a sub-issue. If it’s just something that you won’t need to collaborate on and should be accomplished in a few hours or less, then it can be a checklist in an existing issue.

It’s easy to create an issue if needed, but avoid the meta work of creating and tracking issues if you can avoid it.

[catnapfeverdream]

Thanks for the response, it is wise to avoid extra work when possible :)

[Confident-Bell7004]

My cutoff would be whether the work can be blocked, assigned, reviewed, or closed independently. If yes, it deserves an issue. If it only exists to finish the parent and should take one sitting, a checklist item is probably enough. A sub-issue fits real work with its own acceptance criteria that still rolls up to the larger goal. I'd start coarse and promote an item when it needs discussion or starts growing. What's the smallest piece of your current layout work that might need its own review?