• Foreword
• Introduction to FOSS
• The Lay Of The Land
• On Being A Beginner
• Getting the Code: Source Code Management
• Building the Code: From Source to Executable
• Debugging the Code: Finding and Reporting Bugs
• Fixing the Code: Patches Welcome
• Explaining the Code: the Art of Documentation
• Expanding the Code: Adding New Features
• ReleaseEarlyReleaseOften
• Credits
• CaseStudySamba
• FOSSAndTheLaw
• FixingTheCodePatchesWelcome
• GettingStartedInAFOSSProject
• Glossary
• SourceCodeManagement
• Testing

Somebody Should Set The Title For This Chapter!

= Adding new features =

== Where do new features come from? ==

Sometimes, a developer just writes them, because they are users too, and they can write their own features.  Often, though, users request them; they may not know how to write them, but they do know what they want.  At least, sometimes they do.  Sometimes they don't.  It's the job of the developer to figure out what the user wants, and how to deliver it -- or whether it even makes sense to deliver it.

== What makes a good feature? ==

Good question.  Some basic stuff here.  Talk about the different approaches to features?  Huge complex specifications are for airplanes.  Concentrate on the agile approach to feature specification and development?  Do some research.  Talk about diagrams, use cases, UML, HCI.   And then FIXME.  How much do we overlap into SW engineering here?  This could be a whole text.

== Exercise: Good Feature, Bad Feature ==

Look through your project's repository of feature requests.  Find one feature that you think is bad, and find one feature request that you think is good.  Compare and contrast.

== Exercise: Proposing a feature idea ==

Submit feature requests to user-community to get feedback on their idea from a feasibility perspective.

== Exercise: Turning a feature request into a feature specification ==

Find a poorly or ambiguously worded feature request.  Research its history, what the user is trying to do, if other users are trying to do this, and then put together a feature specification that future developers could plausibly use to build an actual feature.

== Case study: How project $FOO manages new feature development ==

== Exercise: Writing a new feature, at last ==

Write the code.  You've been working up to this.  Give it a shot.  Be brave.  If it doesn't work, it gives the next person a place to start from.  If you've done the upfront work, if the spec is good, the use of the feature well-understood, and if you've got some pseudocode, it's time to get to work, and keep working until it's done and ready to be submitted as a patch.