This page describes the development workflow for the All for Good platform project. It assumes that you have already successfully worked though the Getting started page.

In order to add anything into the All for Good project source repository, one of two conditions must be met:

You have executed a [[url:http://06303728614547881200-a-g.googlegroups.com/web/afg_cla.txt|CLA]] and posted the CLA to the [[url:http://groups.google.com/group/afg_dev?hl=en_US&lnk=|afg_dev]] Google Group. Once you submit a CLA and demonstrate reasonable knowledge of the codebase (this can be demonstrated either on the mailing list or via patches), we will grant you commit rights to the [[url:http://github.com/allforgood/allforgood|GitHub source repository]].
You submit a patch via email to the Google Group. The patch should be created using [[url:http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html|git format-patch]] command and the email to the Google group should contain the following text: This patch is my own original work. I am licensing it under an Apache 2.0 license.

The All for Good platform project is an agile, open, transparent project with 2 week iterations. What this means is:

All features, chores, etc. are prioritized on the [[url:http://www.pivotaltracker.com/projects/88752|backlog]] If it's not on the backlog at the beginning of an iteration, it will not be done during the iteration.
Before the beginning of an iteration, all participants in the iteration choose their backlog items.
Once an iteration starts, there will be no change to the stories for any developer except in dire circumstances (e.g., huge bug is discovered) and dire circumstances happen at most once a quarter (if they happen any more frequently, there's a bigger issue).
All discussion about development, questions, etc. are done on the afgdev Google Group. This includes product development, product planning, HTML design, User experience, etc. If there is a phone call or Skype meeting or somesuch that not everybody participates in, a summary of that meeting should be posted to afgdev.
All prioritization should be done via discussions on afg_dev. It's critical that the process is transparent as possible in order to demonstrate to partners and development volunteers and other members of the All for Good platform community that their voices can be heard.
At the end of an iteration, each participant in the iteration is invited to brag a little about what they did. Perhaps the bragging is done via a screencast about the new feature or publishing benchmarks of before and after. Any way that a participant chooses to share the results of their hard work with the team will be welcome.
If a participant signs up for an item and discovers that they will not be able to complete the item, it is the participant's responsibility to alert the rest of the team at the earliest possible time about the slip and a compelling reason for the slip (e.g., my son had to go to the emergency room and that took the better part of a day.) It is each participant's responsibility to only sign up for those items that the participant is sure to complete during the iteration.

Technology and expected skills:

Git. Git is our source control system. Anyone who is going to make any changes to any files in the source code should have [[url:http://progit.org/book/|some familiarity with Git]].
Simple Build Tool: sbt. All for Good is built with sbt. There are reasonable [[url:http://code.google.com/p/simple-build-tool/|resources and documentation]] for sbt and it's got an excellent [[url:http://groups.google.com/group/simple-build-tool|community]]
Lift. Lift is the web framework that the All for Good platform is built on. Designers should have familiarity with [[url:http://demo.liftweb.net/templating/|how Lift manages templates]]. Developers should have a reasonable working knowledge of Lift including having completed the [[url:http://liftweb.net/docs/getting_started/mod_master.html|Getting started guide]]. Technical questions about Lift should be directed to the [[url:http://groups.google.com/group/liftweb|Lift community]].
Scala. Most of the All for Good platform code is written in [[url:http://scala-lang.org|Scala]]. Developers should have a working knowledge of Scala and should have a firm grasp of all the concepts in chapters 1-5 of [url:http://apress.com/book/view/9781430219897|Beginning Scala]. The most important things to understand about Scala are collections and how to manipulate them with map/flatMap/filter, how for comprehensions work and how they are syntactic sugar on top of map/flatMap/filter, and Option/Box classes and how they are a specialization of collections.

Ticket and branch mechanics:

We are using Git as our source control system. Please be familiar with the [[url:http://progit.org/book/|basics of Git]].
When you start on an item in the backlog, click the start button.
If the item in the backlog will result in code being changed in the source code repository
[[url:https://www.assembla.com/spaces/allforgood/tickets|create a ticket]]
create a branch (git checkout -b yourinitials_ticket_ticketnumber... e.g., git checkout -b dpp_ticket_5).
Do work only on your branch, but frequently rebase to keep your branch up to date with the master branch (git fetch origin ; git rebase origin/master)
When you are done for the day, commit your changes and push your work to GitHub (e.g., git commit -a -m "Work in progress on ticket 5. Added some stuff" ; git push origin dpp_ticket_5:dpp_ticket_5) This way, everyone can see your work in progress and if you have a hard disk crash, you won't lost your work.
When you are all done with your ticket and you think things are correct (and you've written tests and the tests pass), do a final commit that includes Closes #xx (e.g., commit -m "Closes #5. Got the feature done."). Push your code to GitHub and you might want to ask the afg_dev team to review the code if your changes are non-trivial.
Then rebase to the most recent master (e.g., git fetch origin ; git rebase origin/master ; sbt clean ; sbt test) If the tests pass, then checkout master (git checkout master ; git rebase origin/master) merge in your branch (git merge dpp_ticket_5) and push your code live (git push origin master)
The master branch should always be stable code. Introducing instabilities into master is seriously suboptimal and may require that you [[url:http://yfrog.com/3gqxovj|Wear the cone of shame]]
Once your code has hit master, the Assembla ticket will automatically close (thus the Closes #xxx string in the comment).
In Pivotal Tracker, mark the story as delivered.

Well... that's the basic dev workflow. It seems more heavyweight than I'll just keep committing to master but it also means that everyone on the team knows what everyone else is up to and that leads to a more efficient overall process... plus keeping master stable means that folks always get to see the impact of their changes to the system.