Assigning tasks "feature list"

[Christine Gerpheide]

During our ruby on rails intro we discussed briefly how to avoid duplicating work from the feature list. ie, how to avoid two people working on the same features.

So, we thought it would be a good idea to add you name next to a feature when you start to work on it, along with any comments you may have (ex: "Very willing to pair program with someone who isn't as familiar with Rails" or "Would appreciate any code review from others" etc). When something would finish, I guess we would cross it out (which seems to already be happenenig). What do you think?

The other option we had discussed previously, was to use a bug tracking system (github's or other). If we use github, we should add all the features from the feature list as open tickets as soon as we can, so that ppl can see them there and just assign them to themselves. If we don't do that, then we'd use bug tracking only for more difficult or specific tasks that need a more complicated workflow.

Thoughts? After I hear some feedback, I'll post some brief instructions or something on the top of the feature list on the wiki.

Christine

[Sam Tape]

Sounds good to me. I would definitely appreciate code reviews because I'm very new to the "rails" way of doing things.

Also, I'm completely new to git and github. Are there guidelines for branching and pushing code? Is github considered production code? Should only features that are complete and unit tested be pushed to github? Can we assume that any code we pull from github is functional and tested? Sorry if these are redundant questions, but this is a very different workflow than what I'm used to.

Thanks,
Sam

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To post to this group, send email to grinnellplan...@googlegroups.com.
To unsubscribe from this group, send email to grinnellplans-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/grinnellplans-development?hl=en.

[Ian Young]

Having thought about it a little more since the last meeting, my vote is to use the Github tracking system. That will let us separate out technical/non-technical tasks a little better, and using it for the rewrite project will be a good trial run to help us decide if we want to use it for all issue tracking in the future.

I'll get started on making tickets right now. I propose that we make tags with our usernames and claim a ticket by applying our tag to it. If you don't have a tag yet, just create it with the name "@username" and use the same color as the other @ tags.

Ian

--

[Ian Young]

Good questions, Sam. There are two answers because the way we're currently running the rewrite project is a bit different from the way we will probably run the final stable project.

Right now, we're giving everyone commit access to the Github project, so it will be a bit of a free-for-all. I'd still very much prefer that commits come with tests. The Rails community prefers TDD/BDD development practices, which involve writing the test before you write the code, so for anyone adhering to this system committing the tests will be a given :) That said, things that go into Github may not be fully complete. If you get partway through a feature but run out of steam, I'd say go ahead and commit so that others can pick up where you left off, *as long as your code is reasonably clean*. Extra bonus points if you commit pending tests to spec out what is left to be done.

The system I expect us to settle on once the project has matured is the one most Github projects use. In this model, the main project repo is production code. To make a change, you use Github to fork your own repository of the project. You do the work in your repo, and when it's ready, you open a "pull request" on the main repo. At that point, people review the code, request changes if necessary, and once the maintainers are satisfied, your changes are pulled into the main repo.

For now, if you would like to get help or have your code reviewed *before* pushing it to the main repo, feel free to fork the repo[1] and work on your own branch. You can commit as much as you like there until you're feeling ready. Just make sure to regularly pull changes from the main repo so you don't end up with conflicts.

Ian

[1]: To fork, go to https://github.com/annaswims/GrinnellPlans, and look for the button in the top right that says "Fork". You'll then have a project called "yourname/GrinnellPlans", and Github will give you instructions for checking out a copy of it.

[Ian Young]

Ok, most of the features are up on github's issue tracking[1]. They're also referenced from the feature list[2]. To claim a ticket, create a tag for yourself in the form @username and color it blueish, then tag your ticket. When you commit, a commit message like "Allow unicorn gifs, fixes #98" will automatically close the ticket. If you need a ticket that doesn't exist, please go ahead and create it.

Ian

[1]: https://github.com/annaswims/GrinnellPlans/issues
[2]: https://github.com/annaswims/GrinnellPlans/wiki/Feature-List

[Ian Young]

One quick update to this: Github rolled out a new and improved issue tracker, and tickets can now be assigned to members of the project. So just do that instead of the @username label stuff.

Ian