# Github vs Basecamp board: What goes where?

**URL:** <https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163>\
**Category:** Uncategorized\
**Created:** [January 20, 2020, 5:02pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163 "2020-01-20T17:02:11Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![gafemoyano](https://avatars.discourse-cdn.com/v4/letter/g/0ea827/32.png) [@gafemoyano](https://discourse.learnshapeup.com/u/gafemoyano)\
**Post date:** [January 20, 2020, 5:02pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/1 "2020-01-20T17:02:11Z")

</div>

Hi Ryan!

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

**Context**  
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!  
Felipe.

---

<div class="post-metadata">

**Author:** ![mattdonovan](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mattdonovan/32/380_2.png) [@mattdonovan](https://discourse.learnshapeup.com/u/mattdonovan)\
**Post date:** [January 20, 2020, 6:53pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/2 "2020-01-20T18:53:05Z")

</div>

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](https://basecamp.com/shapeup/3.4-chapter-12#work-is-like-a-hill) 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.

---

<div class="post-metadata">

**Author:** ![gafemoyano](https://avatars.discourse-cdn.com/v4/letter/g/0ea827/32.png) [@gafemoyano](https://discourse.learnshapeup.com/u/gafemoyano)\
**Post date:** [January 20, 2020, 9:35pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/3 "2020-01-20T21:35:01Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![mattdonovan](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mattdonovan/32/380_2.png) [@mattdonovan](https://discourse.learnshapeup.com/u/mattdonovan)\
**Post date:** [January 20, 2020, 10:33pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/4 "2020-01-20T22:33:30Z")

</div>

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

> [@How to deal with very small projects/tasks?](https://discourse.learnshapeup.com/t/how-to-deal-with-very-small-projects-tasks/86/4):
>
> We have had some success baking this kind of work into our Small Batch team’s duties. Since most of that kind of work is engineering, our small batch engineers rotate on and off what we call “Bugster” duty every week or two over a 6 week cycle. The Bugster triages tickets and knocks out small issues and priority bugs. We’ve found that a 1-2 week rotation is short enough to make it feel like a breather for the developer, but long enough to let them actually accomplish something meaningful. As s…

---

<div class="post-metadata">

**Author:** ![arturo](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/arturo/32/60_2.png) [@arturo](https://discourse.learnshapeup.com/u/arturo)\
**Post date:** [January 27, 2020, 6:43pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/5 "2020-01-27T18:43:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![maxhodges](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/maxhodges/32/114_2.png) [@maxhodges](https://discourse.learnshapeup.com/u/maxhodges)\
**Post date:** [March 20, 2020, 1:13pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/6 "2020-03-20T13:13:06Z")

</div>

I highly-disagree with this approach:

> [@mattdonovan](#):
>
> - Issues, feature-requests, and bugs get posted to Gihthub.
> - Just about anything else would be considered a pitch and goes to the betting table.

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](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](https://voice.whiterabbitexpress.com/forget-basecamp-how-to-implement-shape-up-in-monday-com-539be2193542)), 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

 ![image](https://canada1.discourse-cdn.com/flex030/uploads/shapeup/original/1X/384e51dd7f3151b48343306f60066c37bbbf0c82.png)

---

<div class="post-metadata">

**Author:** ![maxhodges](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/maxhodges/32/114_2.png) [@maxhodges](https://discourse.learnshapeup.com/u/maxhodges)\
**Post date:** [March 20, 2020, 1:27pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/7 "2020-03-20T13:27:34Z")

</div>

These tasks get split up into multiple branches in Github–which business stakeholders don’t care so much about–and the conversion there is likewise technical (implementation details).

 ![image](https://canada1.discourse-cdn.com/flex030/uploads/shapeup/original/1X/8a6d27021fbb6900a44e6503f4c1fc83a0e26283.png)

---

<div class="post-metadata">

**Author:** ![mattdonovan](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mattdonovan/32/380_2.png) [@mattdonovan](https://discourse.learnshapeup.com/u/mattdonovan)\
**Post date:** [March 23, 2020, 10:30pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/8 "2020-03-23T22:30:07Z")

</div>

@maxhodges RE:

> 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.

I suppose I could have called out explicitly that, while our team generally agrees with the spirit of Shape Up’s approach to bugs, we don’t feel great about any of the tactics. From my perspective, our team thinks bugs _are_ different from other kinds of work in a few ways that make them worth triaging and prioritizing independently.

1. **A bug isn’t pitched, it’s reported.** That means someone experienced it and it was bad enough for them to realize it. Bugs are embarrassing and, at least for now, our team is sensitive to that.
2. **Bugs often have few uphill questions.** User-story-wise, we know what done looks like. We also have institutional knowledge about the development of that feature. Unlike shaping, the intended product is almost 100% prescriptive, which also makes them easier to size-up.
3. **Some bugs are leaches on previous bets.** In Shape Up terms, if I make a bet on a pitch and the team produces something great that works, I’m making an assumption that it’s going to keep working. In that sense, I actually really like having ongoing bug fixes.

I should note that when any of our developers are working on bugs, they have had a hand in triaging them and deciding if what they’re looking at is worth working on right now or not.

I know there is some baked-in “stay busy” bias there, but our thought is as long as the engineer feels his or her time is well spent and they improve our product, what’s the harm?

---

<div class="post-metadata">

**Author:** ![maxhodges](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/maxhodges/32/114_2.png) [@maxhodges](https://discourse.learnshapeup.com/u/maxhodges)\
**Post date:** [March 24, 2020, 7:07am UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/9 "2020-03-24T07:07:25Z")

</div>

Our team here is very much in agreement with the Shape Up stance on the matter of bugs.

> There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But _crises are rare_ . The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.

Ultimately software engineering is about adding-value. Sometimes fixing a bug is the most valuable thing you could be doing. Often times it’s not at all. The resources dedicated to a bug fix should be weighed against all the other value-adding activities you could be doing.

You’ve already _shortlisted_ your best value-adding _raw ideas_, you’ve _shaped them up_, brought them to the _betting table_, and the team voted to bring them to the next _cycle_. Now you’re going to pre-empt all that evaluating, prioritizing, and planning because someone noticed your software isn’t perfect?

Frequently it makes little sense to interrupt the team’s momentum toward their current tasks just because someone found a bug. Surely whatever the team is working on must be something deemed to add a lot of value otherwise it wouldn’t have gotten past the _betting table_. A new feature might add value to a great number of customers while the bug might only affect a handful of users and in only a small number of circumstances. These things really need to be considered in the context of their impact and all the other value-added things you could be working on. Otherwise, you might win the Battle of the Bugs but lose the war for profits and market share and cede your competition an opportunity to win the hearts and minds of your customers. Your “bug-free” software can’t keep up with the velocity in which my team is able to add game-changing features.

The **embarrassment** you speak of is something we explicitly embrace. I’d rather apologize to a minority of inconvenienced customers than lose valuable momentum on a high-impact feature that’s going to wow masses of users, significantly improve operational efficiency, accelerate our growth, and have a big positive impact on our bottom-line.

That being said, we do care about bugs and we have processes to deal with them, we just feel their priority should be determined by a rational evaluation that puts them in context with other value-adding activities.

Think in terms of grading bugs along a “Bug Bell-Curve.” A small percentage of bugs demand immediate attention, a small percentage can be ignored for years, and most fall somewhere in-between.

Cheers! 🐜 🕷 🦟

---

<div class="post-metadata">

**Author:** ![mhl66](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mhl66/32/432_2.png) [@mhl66](https://discourse.learnshapeup.com/u/mhl66)\
**Post date:** [February 18, 2021, 4:51pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/10 "2021-02-18T16:51:37Z")

</div>

Few questions on bypassing, e.g., Jira, and connecting Basecamp directly to GitHub:

1. How can we track dependencies between tasks in each scope?

2. How can we reference tasks to GitHub repo and do bi-directional linking?

3. How can we track tickets in testing environments?

4. How can we create release notes?

---

<div class="post-metadata">

**Author:** ![justin](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/justin/32/429_2.png) [@justin](https://discourse.learnshapeup.com/u/justin)\
**Post date:** [February 19, 2021, 3:17pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/11 "2021-02-19T15:17:46Z")

</div>

Our stance is that the only things that belong in GitHub are the code, pull requests, and code reviews, with minor exceptions such as getting started guides and quick tips in a README.

---

<div class="post-metadata">

**Author:** ![mhl66](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mhl66/32/432_2.png) [@mhl66](https://discourse.learnshapeup.com/u/mhl66)\
**Post date:** [February 19, 2021, 4:28pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/12 "2021-02-19T16:28:25Z")

</div>

Any value in connecting to Basecamp though, for tracking and compliance reasons?

---

<div class="post-metadata">

**Author:** ![justin](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/justin/32/429_2.png) [@justin](https://discourse.learnshapeup.com/u/justin)\
**Post date:** [February 20, 2021, 1:13pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/13 "2021-02-20T13:13:17Z")

</div>

I don’t personally think so, trying to map to-dos from Basecamp into GitHub will just create confusion about what should be recorded as a to-do, the source of truth of a to-do, etc.

Also we explicitly close out Basecamp projects every cycle along with all of their to-dos completed or not because we don’t want lists lingering around distracting the core team from their priorities.

---

<div class="post-metadata">

**Author:** ![mhl66](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mhl66/32/432_2.png) [@mhl66](https://discourse.learnshapeup.com/u/mhl66)\
**Post date:** [February 20, 2021, 3:04pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/14 "2021-02-20T15:04:33Z")

</div>

My team is thinking about using Basecamp to track at the feature level (scopes) and keep tasks in Jira (which is linked to GitHub). Thoughts?

---

<div class="post-metadata">

**Author:** ![justin](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/justin/32/429_2.png) [@justin](https://discourse.learnshapeup.com/u/justin)\
**Post date:** [February 20, 2021, 3:20pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/15 "2021-02-20T15:20:14Z")

</div>

What’s the problem you’re trying to solve? What justifies having to-dos spread over three websites?

---

<div class="post-metadata">

**Author:** ![mhl66](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mhl66/32/432_2.png) [@mhl66](https://discourse.learnshapeup.com/u/mhl66)\
**Post date:** [February 27, 2021, 3:43am UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/16 "2021-02-27T03:43:45Z")

</div>

1. How can we reference tasks to GitHub repo and do bi-directional linking?
2. How can we track tickets in testing environments?

---

<div class="post-metadata">

**Author:** ![JoshAntBrown](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/joshantbrown/32/599_2.png) [@JoshAntBrown](https://discourse.learnshapeup.com/u/JoshAntBrown)\
**Post date:** [March 2, 2021, 4:18pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/17 "2021-03-02T16:18:30Z")

</div>

I think if your team are already using Basecamp then just keep everything in there - let teams organise their tasks in there within each project. Then just use the GitHub for hosting code and pull requests.

I believe that is how the Basecamp team themselves use GitHub from what I’ve seen posted from Ryan, David and Jason.

* * *

Our team aren’t using Basecamp at all so we do everything within GitHub. For each project we’ll create one GitHub issue and then link off to smaller issues using a checklist within the body of the main issue.

The linking between pull requests and the issues are “nice” - but I’m not sure anyone would miss it. We don’t find any compliance or tracking benefits from it. We generally make sure to write up the details in the pull request message anyway.

---

<div class="post-metadata">

**Author:** ![justin](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/justin/32/429_2.png) [@justin](https://discourse.learnshapeup.com/u/justin)\
**Post date:** [March 2, 2021, 5:20pm UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/18 "2021-03-02T17:20:18Z")

</div>

Agree - an important aspect of Shape Up is autonomy. Basecamp offers the Hill Chart to show progress on a project over time, and Shape Up leaves tasks and task management up to individual team members.

@mhl66 you’ll want to find the right separation so that task organization and management is a benefit to each team member and habit forming, not an obligation.

---

<div class="post-metadata">

**Author:** ![mhl66](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/mhl66/32/432_2.png) [@mhl66](https://discourse.learnshapeup.com/u/mhl66)\
**Post date:** [March 4, 2021, 1:05am UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/19 "2021-03-04T01:05:53Z")

</div>

Thanks, @JoshAntBrown and @justin

---

<div class="post-metadata">

**Author:** ![JoshAntBrown](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.learnshapeup.com/joshantbrown/32/599_2.png) [@JoshAntBrown](https://discourse.learnshapeup.com/u/JoshAntBrown)\
**Post date:** [April 26, 2021, 9:30am UTC](https://discourse.learnshapeup.com/t/github-vs-basecamp-board-what-goes-where/163/20 "2021-04-26T09:30:27Z")

</div>

DHH posted a tweet with a link to a livestream him and Jason did about how they use GitHub and Basecamp - thought worth linking here since it reminded me of this conversation.

> <https://twitter.com/dhh/status/1386605576042565632?s=20>

[![](https://canada1.discourse-cdn.com/flex030/uploads/shapeup/original/1X/65cd186e07a0c4e61739623421d885a9eabbe322.jpeg "Going Remote: Basecamp Walkthrough Livestream with Jason Fried and David Heinemeier Hansson") ](https://www.youtube.com/watch?v=CFzvA1dEvd8)