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. 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. Work on bugs during the cool down, send them to the betting table, or perhaps dedicate an occasional bug smash cycle of appropriate length. “There is nothing special about bugs that makes them automatically more important than everything else.” It threatens to preempt your planning, cause confusion about priorities, and stress your team. This is anathema to the whole spirit of Shape Up.
BOARD FOR GITHUB LICENSE
It sounds like you’re giving issues and bugs a license to bypass the normal scheduled work cycle. Shape Up explicitly addresses the problem in the chapter: “What about bugs?” I suggest you re-read it now:
Then I thought this seemed more like a proposal (or pitch?) than an issue… Nevertheless, all the language is very technical.
BOARD FOR GITHUB HOW TO
I found myself writing a github issue to outline what I wanted to accomplish and how to go about getting there. The idea is: I want to prioritize certain jobs related to payments to prevent important jobs from getting stuck in a queue for a long time. Lets say I want the team to spend some time working on our background jobs system. I have a proposal for the dev team and it’s very techincal. (17 people including founders, devs, designers, operations and sales). We’ve adopted the pitch strategy where we work out an idea in private and when it’s ready we share it with the company. I’ll try to go straight to the point with an example.