Created COMMITTERS.md file

#8 earlier pull request, addressed all comments from there. 
After we move this line to be merged with 1.2, I think we need to favor the "could" instead of the "will" language.

As this is now an open source project, this project's issues should be managed in the complete open. I can see a few cases were an internal issue would be logged, but I can also see cases where an internal issue does not have to be logged. (especially if someone wants to contribute a pull request with code already done :) ). 

Some cases I can see that would warrant an internal issue include:
1. An open security risk that we don't want to advertise until after it's fixed. 
2. Prioritization of working on issues for this project along with all of the other priorities of a team. (this will likely drive most of the internal issues)
3. A desire of a newer engineer to use the internal code review tool first to get their feet wet. (Ideally we'd get newer engineers more comfortable working in the complete open, but not everyone is there right off the bat). 

But again not all issues here will need to have corresponding internal JIRAs, and if we do choose to log an internal JIRA, all design discussions and decisions should go on the issues in this repository. 

But all discussion and consensus must be done in the open, and the final code review must be done in an open as a pull request. 


By our development practices, [Github is an approved tool](https://wiki.ucern.com/display/public/ipfactory/OTS+Tool+-+GitHub) for source control, issue tracking, and documentation.