Fixing bugs and making small improvements is a good way to get started contributing code to Loomio. There are 2 places where tracking of what needs fixing and what is currently planned takes place :

• Github Issues: for logging and tracking bugs.
  To find a small task to take on, check the issues list for 'Small Tasks'.

• Pivotal Tracker: shows our immediate priorities and what we're currently working on.

If you want to create a new feature for Loomio (instead of just a small improvement), the process is a little bit more involved:

1. Start a discussion about it in the Loomio Community -> Features subgroup (if the discussion doesn't exist already). Include any mock-ups or thoughts you have on how the feature should be implemented.
2. Facilitate the discussion until some sort of consensus has been reached about how the feature should function & what it should look like (e.g. a proposal including a spec of the feature)
3. Code away!

You can see the code for this example here.

Start by ensuring the feature is fully specified. This means being clear about the feature should do and what interacting with it should be like for a user. Mocking it up with a hand or digital sketch and running it by others in the community will help save time and confusion later in the process. This is really important regardless of how small a feature it is - you shouldn't have to guess at any of the functionality.

For this example, we're developing a feature to allow group admins to delete comments. Repository names are assumed to follow those established in first time repo setup.

Make sure the local repo is up-to-date:

git pull origin master

If there have been any changes to the database, or new gems added, at this point you will need to run:

bundle install; bundle exec rake db:migrate db:test:prepare

git checkout -b feature/admin-delete-comment

Integration tests (cucumber) We start by writing the cucumber test for this feature, using the existing test (features/delete_post.feature) as a reference. We duplicate this file, rename it (admin_delete_post.feature), and edit it to describe the behaviour we want to see.

Feature: Admin deletes post
  As an admin
  So that I can remove inappropriate content
  I want to be able to delete other user's comments

  Scenario: Admin deletes another users comment
    Given I am logged in
    And I am an admin of a group with a discussion
    And the discussion has comments
    And I am on the discussion page
    When I click the delete button on a post
    And I accept the popup to confirm
    Then I should no longer see the post in the discussion

We run the test and watch it fail (there's no 'delete' link for the admin to click).

To figure out the solution, we look at how the delete feature currently works views/comments/_comment_likes.html.haml, we can see the current state of the delete feature: users can delete their own comments.

  - if comment.user == current_user
    = link_to "Delete", "#" ...

We want to modify the permissions around this feature, to allow admins to delete them too.

Permissions (Cancan) We're using cancan to govern permissions, which defines who can do what. We start by editing the test (spec/models/ability_spec.rb) to describe the behaviour we want to see:

  context "admin of a group" do
  ...
    it { should be_able_to(:destroy, another_user_comment) }

We watch that test fail, then modify app/models/ability.rb and watch the test pass.

  can :destroy, Comment, :discussion => { group_id: user.adminable_group_ids }

Now we edit the view (views/comments/_comment_likes.html.haml), to introduce the new permission switch, (replacing if comment.user == current_user with if can? :destroy, comment). With that change, the feature is complete. To make sure, we run the cucumber test again, and watch it pass.

You want to make sure your feature hasn't broken anything else. To run the full suite of integration tests simply run cucumber. Once these have all passed, run the rspec tests rspec.

git add .
git commit -m "add delete functionality for admins"
```

***

### 4. Rebase from __origin__ + squash
Rebasing from origin means that when we go to merge your pull request, your feature will be up to date __and__ show up in the feature history in a chronologically sensible place.
'Squashing' means that if you've made a heap of commits only one will show up in origin's history, this makes managing the projects easier.

``` 
git fetch origin
git rebase origin/master -i
```
NB: note git uses `origin/master` here which is slightly different to the usual `origin master`

[Find a more detailed how-to here](https://github.com/loomio/loomio/wiki/how-to-rebase-squash)
***

### 5. Run the whole test suite

***

### 6. Push the changes

Finally we commit the changes and push them to github. 

``` 
git push myfork feature/admin-delete-comment
```
NB: if you've been pushing your commits to myfork, you may need to add a `-f` flag to force the push (the rebase in step 4. kind of re-wrote history)

***

### 7. Pull request

Finally we go to github and **[submit a pull request](https://help.github.com/articles/using-pull-requests)** - this will notify others that your code is waiting to be reviewed.

**Check back** on your pull request to see if there are any comments - different people from the team may have comments about the code, and you can talk about potential improvements/changes before it is accepted into the codebase

## Contributor License Agreement (CLA)

Also, before you submit a pull-request, please sign our CLA:

http://goo.gl/YfXNU

It ensures that the copyright will always stay on an OSI or FSF certified license. It was automatically generated using [harmony agreements](http://www.harmonyagreements.org/). If you're interested, [here's the discussion](http://www.loomio.org/discussions/248?proposal=476) where we decided on the license and CLA.


## Feel free to ask questions

If you want some help to get started contributed, feel free to post your questions in the [code subgroup](http://www.loomio.org/groups/42) or send an email to anyone on the team.