How do you manage the Discourse project?

This list of feature is amazing Discourse Version 1.6
I am always astonished when I see it. How do you manage your project? Do you use a specific project management tool? Just GitHub commits + Discourse? How do you track all this things status? I’m struggling a lot with it :frowning: can you share some tips?


I’ve been thinking it’d be fun to write a blog post about this, so maybe I will. :challengeaccepted: But in short, for communication and tracking, we use:

  • Discourse
    For community management, public & private support, feature discussion & curation & tracking, public & private knowledgebase and internal discussion.

  • Slack
    For live team communication. Stuff that requires immediate attention. Anything that should live in our “long term memory” gets posted to our internal Discourse instance instead.

  • GitHub
    For all things development, public and private.

  • Skype
    For weekly/monthly team meetings. Might get replaced by Slack Calls?

Other than that, individual team members are free to use tools like Trello for tracking their own work, but to each his own. I for instance do use Trello, but thanks to the nature of our business we’re a highly communicative company, so a task I’m working on will often appear in a topic or blog post draft or quick mention on Slack before I even need to “track” it on Trello, so I don’t.

As for the fast pace of development there are a lot of factors at play here, but part of it can definitely be attributed to the technology choices made. Read Why Ruby?

Ruby isn’t cool any more. Yeah, you heard me. It’s not cool to write Ruby code any more. All the cool people moved on to slinging Scala and Node.js years ago. Our project isn’t cool, it’s just a bunch of boring old Ruby code. Personally, I’m thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. That means the rest of us who just like to Get Shit Done can roll up our sleeves and focus on the mission of building stuff with our peers rather than frantically running around trying to suss out the next shiny thing.

Of course it’s no silver bullet. There are plenty of Ruby/RoR teams out there who aren’t productive (also, Discourse is just as much a JavaScript/Ember project). But the developers chose this technology stack not because they hoped it’d make them productive, but because they were experienced to know it’d make them productive, since they’ve been around the block a few times already.