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 | This is at least for a quick/dirty run. I think this might be similar to what Nimish Hathi mentioned. | ||
modularity | 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 | Interactive graphic user interface will help users to quickly examine visually. | ||
documentation | This is important, as we all can agree | ||