Added contributing guide, cleaned up todo, made license prettier

CONTRIBUTING.md

@@ -0,0 +1,52 @@
+# How to contribute
+
+Third-party patches are essential for creating fantastic software. Github is a
+great tool for making contributing a little - or a lot - easy and fun. There are
+some guidelines that contributors should follow that makes it easier for
+everyone to help out.
+
+## Getting Started
+
+* You must have a [GitHub account](https://github.com/signup/free)
+* Fork the repository on GitHub
+* Try running the tests or generating an extension
+
+## Bugs, Feature Requests, and Tasks (oh my)
+
+If you find an error with the way the generator works, that is a bug. If you
+want to add a new feature to the generator or change the way something works,
+that is a feature request.
+
+If you think you've found a bug, or have a feature request for G\Generator the
+first step is to search to see if someone else has already logged the item in
+the [issue tracker](https://github.com/gtkforphp/generator/issues).
+
+If you do find a similar bug or feature request, and have additional information
+to add, please leave a comment. Don't comment just to say "me too".
+
+If you don't find your bug or feature request, feel free to create a new issue,
+please label it appropriately. Feature requests marked as bugs are pretty likely
+to simply be marked as invalid and ignored.
+
+## Making Changes
+
+If you want to work on a feature request or bug yourself:
+
+* Create a feature/bug branch from where you want to base your work.  It works well to have the issue id in the branch name somewhere.
+  * You usually want to base off of the master branch.
+  * Please avoid working directly on the `master` branch.
+  * Check for unnecessary whitespace with `git diff --check` before committing.
+  * Make sure your commit messages are in the proper format and include the issue id # in the commit message
+* Make sure you have added the necessary tests for your changes.
+* Run _all_ the tests to assure nothing else was accidentally broken.
+
+## Submitting Changes
+
+* Push your changes to your bug/feature branch in your fork of the repository.
+* Submit a pull request to the repository in the gtkforphp organization.
+
+# Additional Resources
+
+* [General GitHub documentation](http://help.github.com/)
+* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
+* #gktforphp IRC channel on freenode.org

LICENSE → LICENSE.md

@@ -1,6 +1,6 @@
-The MIT License
+# The MIT License
 
-Copyright (c) 2012 Elizabeth Marie Smith
+## Copyright (c) 2012-2013 Elizabeth Marie Smith
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

TODO.md

@@ -1,37 +1,25 @@
-TODO
-===
+# TODO
 
- 1. main app - add list available config parsers
- 1. main app - add list available spec parsers
- 1. main app - make logging work
- 1. main app - make lint, update, new commands work
- 1. all config parsers: write php array spec, write php linter for spec
- 1. config ini parser:
-    1. handle errors in parse_ini_file with interim error handler
-    1. check required/set default config items to match array spec
-    1. write method to write out changed configuration
+## Currently underway
 
-Far Future
-===
- 1. another app or flag for config generation
- 1. spec parser for other formats
- 1. another app or flag for scanner for other formats? gintrospection based scanner?
+* Create a set of interfaces for how data should be returned
+* Create 3 config parsers (ini, php, xml)
+* Create 3 spec parsers (codegen_pecl/pecl_gen xml, gir xml, g\gen PHP format)
 
-// 5. changes in behavior
-//    3. actual output location for generation
-//    4. logging behavior/location
-// 6. do generation
+## Feature list
 
-set up writing
-//       2. templates format and location
-//       3. what to generate
+* make command line flags work
+* logging
+* linting
+* metadata (config parsers installed, spec parsers installed)
+* generate working
+* update working
 
+## Far Future
 
-//   3.a. new - writing
-//     1. using spec data, write C files
-//     2. using spec data, write test files
-//     3. using spec data, write doc files
-//   3.b. update - reading/writing
-//     1. read in data, compare to spec data, write C files
-//     2. read in data, compare to spec data, write test files
-//     3. read in data, compare to spec data, write doc files
+* config generation
+* additional spec formats
+* additional config formats
+* scanner app
+* docs in formats
+* tests in formats