Skip to content
Browse files
Initial release of Discourse
  • Loading branch information
eviltrout committed Feb 5, 2013
0 parents commit 21b562852885f883be43032e03c709241e8e6d4f
Showing 2,932 changed files with 143,949 additions and 0 deletions.
@@ -0,0 +1,5 @@
Autotest.add_hook :initialize do |autotest|
%w{.git .svn .hg .DS_Store db log tmp vendor ._*}.each do |exception|
@@ -0,0 +1 @@
* text=auto
@@ -0,0 +1,61 @@
# See for more about ignoring files.
# If you find yourself ignoring temporary files generated by your text editor
# or operating system, you probably want to add a global ignore instead:
# git config --global core.excludesfile ~/.gitignore_global




# Ignore bundler config

# Ignore the default SQLite database and db dumps

# Ignore all logfiles and tempfiles.

# Ignore Eclipse .project file

# Ignore Eclipse .buildpath file

# Ignore RubyMine settings

# Ignore gem that is copied in


# Vim temp files

# don't check in multisite config
# don't check in my renamed multisite config as well :)


# Scripts used for downloading/refshing db
1 .rspec
@@ -0,0 +1 @@
@@ -0,0 +1,19 @@
# The Discourse Team

* Jeff Atwood - Founder, Principal Overlord, Lead Systems Design

* Robin Ward - Co-Founder, Ruby developer

* Sam Saffron - Co-Founder, Ruby developer

* Neil Lalonde - Ruby Developer

* Ryan Mudryk - UI Implementation, supplemental

### Specials Thanks To

* Nick Sahler - UI Implementation, supplemental

* Don Petersen - Ruby developmer, installation scripts

*For a more detailed list of the many individuals that contributed to the design and development of Discourse outside of GitHub, please refer to the official Discourse website.*
@@ -0,0 +1,114 @@
# Contributing to Discourse

## Before You Start

Anyone wishing to contribute to the **[Discourse/Core](** project **MUST read & sign the [Discourse Forums Contribution License Agreement](**. The Discourse team is legally prevented from accepting any pull requests from users who have not signed the CLA first.

## Reporting Bugs

1. Update to the most recent master release; the bug may already be resolved.

2. Search for similar issues on the Discourse development forums; it may already be an identified bug.

3. On GitHub, provide the details of the issue, with any included workflows, screenshots, or links to examples on If possible, submit a Pull Request with a failing test. If you'd rather take matters into your own hands, fix the bug yourself (jump down to the "Contributing (Step-by-step)" section).

4. The Discourse team will work with you until your issue can be verified. Once verified, a team member will flag the issue appropriately, lock it, and create a new topic discussing the bug on the Discourse forums.

5. Continue to monitor the progress/discussion surrounding the bug by reading the topic assigned to your bug on the Discourse forums.

6. When the bug is fixed, the Discourse topic will be frozen, and the bug will be marked as fixed in the repo, with the appropriate commit assigned to the fix for tracking purposes.

## Requesting New Features

1. Do not submit a feature request on GitHub; all feature requests on GitHub will be closed. Instead, visit the Discourse development forums, and search for the "Feature Request" category, which will filter a list of outstanding requests. Review this list for similar feature requests. It's possible somebody has already asked for this feature or provided a pull request that we're still discussing.

2. Provide a clear and detailed explanation of the feature you want and why it's important to add. The feature must apply to a wide array of users of Discourse; for smaller, more targeted "one-off" features, you might consider writing a plugin for Discourse. You may also want to provide us with some advance documentation on the feature, which will help the community to better understand where it will fit.

3. If you're a Rock Star programmer, build the feature yourself (refer to the "Contributing (Step-by-step)" section below).

## Contributing (Step-by-step)

1. Clone the Repo:

git clone git://

2. Create a new Branch:

cd core
git checkout -b new_discourse_branch

3. Code

Make some magic happen! Remember to:
* Adhere to conventions.
* Update CHANGELOG with a description of your work.
* Include tests, and ensure they pass.
* Remember to check to see if your new functionality has an impact on our Documentation, and include updates as appropriate.

Completing these steps will increase the chances of your code making it into **[Discourse/Core](**.

4. Commit

git commit -a

**Do not leave the commit message blank!** Provide a detailed description of your commit!


Ensure that if you supply a multitude of commits, they are **squashed into a single commit**:

git remote add upstream
git fetch upstream
git checkout new_discourse_branch
git rebase upstream/master
git rebase -i
< Choose 'squash' for all of your commits except the first one. >
< Edit the commit message to make sense, and describe all your changes. >
git push origin new_discourse_branch -f

5. Update your branch

git checkout master
git pull --rebase

6. Fork

git remote add mine<your user name>/core.git

7. Push to your remote

git push mine new_discourse_branch

8. Issue a Pull Request

In order to make a pull request,
* Navigate to the Discourse repository you just pushed to (e.g.
* Click "Pull Request".
* Write your branch name in the branch field (this is filled with "master" by default)
* Click "Update Commit Range".
* Ensure the changesets you introduced are included in the "Commits" tab.
* Ensure that the "Files Changed" incorporate all of your changes.
* Fill in some details about your potential patch including a meaningful title.
* Click "Send pull request".

Once these steps are done, you will soon receive feedback from The Discourse team!

9. Responding to Feedback

The Discourse team may recommend adjustments to your code, and this is perfectly normal. Part of interacting with a healthy open-source community requires you to be open to learning new techniques and strategies; *don't get discouraged!* Remember: if the Discourse team suggest changes to your code, **they care enough about your work that they want to include it**, and hope that you can assist by implementing those revisions on your own.
@@ -0,0 +1,33 @@
All Discourse code is Copyright 2013 by Civilized Discourse Construction Kit, Inc.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with this program as the file LICENSE.txt; if not, please see

Discourse is a registered trademark of FIRSTNAME LASTNAME.

Discourse includes works under other copyright notices and distributed
according to the terms of the GNU General Public License or a compatible
license (where indicated), including:


Ember.js - Copyright (c) 2012-2013 Yehuda Katz, Tom Dale, Charles Jolley and Ember.js contributors

jQuery - Copyright (c) 2010-2013 John Resig


Rails - Copyright (c) 2005-2013 David Heinemeier Hansson, Rails Core Team contributors (MIT)

Thin - Copyright (c) 2012-2013 Marc-Andre Cournoyer
@@ -0,0 +1,77 @@
# Discourse Developer Install Guide

If you'd like to set up a development environment for Discourse, the easiest way is by using a virtual machine.

### Getting Started

1. Install the Xcode tools:
2. Install VirtualBox:
3. Install Ruby 1.9.3. We recommend RVM:
4. Open a terminal
5. Clone the project: ``
6. Enter the project directory: `cd core`
7. Install vagrant: `gem install vagrant`

### Using Vagrant

When you're ready to start working, boot the VM:
vagrant up

It should prompt you for your admin password. This is so it can mount your local files inside the VM for an easy workflow.

(The first time you do this, it will take a while as it downloads the VM image and installs it. Go grab a coffee.)

Once the machine has booted up, you can shell into it by typing:

vagrant ssh

### Keeping your VM up to date

Now you're in a virtual machine is almost ready to start developing. It's a good idea to perform the following instructions
*every time* you pull from master to ensure your environment is still up to date.

bundle install
bundle exec rake db:migrate
bundle exec rake db:seed_fu

### Starting Rails

Once your VM is up to date, you can start a rails instance using the following command:

bundle exec rails server

In a few seconds, rails will start server pages. To access them, open a web browser to http://localhost:4000 - if it all worked you should see discourse! Congratulations, you are ready to start working!

You can now edit files on your local file system, using your favorite text editor or IDE. When you reload your web browser, it should have the latest changed.

### Guard + Rspec

If you're actively working on Discourse, we recommend that you run Guard. It'll automatically run our unit tests over and over, and includes support
for live CSS reloading.

To use it, follow all the above steps. Once rails is running, open a new terminal window or tab, and then do this:

vagrant ssh
bundle exec guard -p

Wait a minute while it runs all our unit tests. Once it has completed, live reloading should start working. Simply save a file locally, wait a couple of seconds and you'll see it change in your browser. No reloading of pages should be necessary for the most part, although if something doesn't update you should refresh to confirm.

### Shutting down the VM

When you're done working on Discourse, you can shut down Vagrant like so:

vagrant halt

4 comments on commit 21b5628


This comment has been minimized.

Copy link

@xiongchiamiov xiongchiamiov replied Mar 22, 2013

Just out of curiosity, why is there a big "check all this shit in" commit from when you're initially releasing Discourse, instead of just going with the commits you had while working on it?


This comment has been minimized.

Copy link
Member Author

@eviltrout eviltrout replied Mar 22, 2013

At various points we had sensitive information in there like passwords and such. It seemed safer to start with a clean slate.


This comment has been minimized.

Copy link

@xiongchiamiov xiongchiamiov replied Mar 25, 2013

Ah, makes sense. Thanks for the info!


This comment has been minimized.

Copy link

@danar123 danar123 replied Jul 22, 2013

At various points we had sensitive

Please sign in to comment.