I highly-disagree with this approach:
Shape Up explicitly addresses the problem in the chapter: “What about bugs?” I suggest you re-read it now:
https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs
It sounds like you’re giving issues and bugs a license to bypass the normal scheduled work cycle. This is anathema to the whole spirit of Shape Up. It threatens to preempt your planning, cause confusion about priorities, and stress your team.
“There is nothing special about bugs that makes them automatically more important than everything else.”
Work on bugs during the cool down, send them to the betting table, or perhaps dedicate an occasional bug smash cycle of appropriate length.
What I’d suggest is to run Shape Up as you normally would in Basecamp (we prefer doing Shape Up in Monday), then simply allow your team to use Github to get the work done. In this way, Shape Up is how you define and decide what to work on and to discuss any concerns that come up, and Github is used to managed how the work gets done–the implementation details in terms of branches, commits and pull requests. We continue any discussion of the task in Monday (Basecamp for most of you). Github is just used to organize how features (as branches) and for versioning (commits/pull-requests). Sometimes the engineers discuss technical implementation details in Github, but discussion about the scope of the feature or business-rules happens outside of Github.
here’s some tasks in a teams current cycle in Monday, along with some discussion of a rabbithole that came up in the sidebar