This is a page to record decisions on what is in or out for a Minimum Viable Project.
The purpose of a Minimum Viable Product should get a practical, extensible, maintainable, well-documented product into the hands of users as fast as possible. There is a delicate balance between what is too minimal to be particularly useful and what is too ambitious to be viable. As a worksheet we can begin to construct a table of features/capabilities and categorize them in terms of importance to the user and viability for an early release based largely on existing code and/or calibrations and/or reference files.
MVP worksheet
| Feature/capability | Importance for MVP (must, should, nice) | Difficulty to deliver in MVP (high, medium,low) | Comments |
|---|---|---|---|
| user-friendly APIs | should | This is at least for a quick/dirty run. I think this might be similar to what Nimish Hathi mentioned. | |
| modularity | must | This would be useful especially when we think of extendability either adding new grism definition from different facilities, or user customized objects from base classes. | |
| Interactive GUI | nice | Interactive graphic user interface will help users to quickly examine visually. | |
| documentation | must | This is important, as we all can agree  | |
| minimal code comment standard | should | We should discuss about what would be the minimal requirement for code commenting. Have these requirements noted down, and make sure that all codes complied to the minimal standard before accepting any push to the main code body. We might assign someone specifically to go through all codes and check for the compliance. | |
| Tutorial / cookbook | must | This should explain itself how it import it is. | |
