Shape Up Forum

Github vs Basecamp board: What goes where?

Hi Ryan!

I’ll try to go straight to the point with an example.

We use both Github and BC at my company. 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. (17 people including founders, devs, designers, operations and sales).

The issue
I have a proposal for the dev team and it’s very techincal. Where does it go?

Lets say I want the team to spend some time working on our background jobs system.
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.

I found myself writing a github issue to outline what I wanted to accomplish and how to go about getting there. Then I thought this seemed more like a proposal (or pitch?) than an issue… Nevertheless, all the language is very technical. So where should that live? I’m not sure every issue in a webapp is a proposal… but they aren’t all bugs either.

Thanks for an awesome book and taking time with these questions!


Hey @gafemoyano - we worked through a similar challenge on our team recently and landed on the following principles:

  • Issues, feature-requests, and bugs get posted to Gihthub. These tickets just outline problems or ask for solutions that don’t require shaping. There can’t be any uphill questions left unanswered and the appetite for execution is measured in hours or days, not weeks.
  • Just about anything else would be considered a pitch and goes to the betting table.

If that doesn’t answer your question, I’d be happy to provide more color.

1 Like

Hi @mattdonovan, thanks for your answer.

That seems clear enough to me. In your personal experience, how would you handle kicking off the “tasks” assigned via issues en github vs cycle work? So far, I’m aware of two approaches:

  • Have a dedicated person doing support work during the cycle
  • Tackle it on cooldown

Thanks again for your answers!


Great question - there is another thread on just that. Here’s my answer:

1 Like

Hi Felipe

We also ran into a similar situation and, when the technical improvements take days, a pitch is also created. The pitch helps set the scope and appetite.

In our case, we have to have the CTO in the meeting so that the importance of the issue can be raised.

Business benefits (internal o customer-faced) can be explained in the pitch and that can confirm the value of the proposal.

This way, we can also make sure that we are not creating a pitch for just a new and hyped tech, like a new JS library or something fancy like that. We make sure to see the real business value.

In you case, sounds like internal efficiency, which is totally valid.