Design choice: Use documentation driven design

[seabbs]

As we think about making this a more user facing package I want to think about how we make design decisions. I really like using documentation driven design and I think that could work well here.

This can work in a few ways but what I am thinking about is something like a few vignettes with different levels of user flow (a simple estimate, estimation for multiple models, estimation for multiple observation models etc) that would be non-functional in the first instance but show the kinds of functions we would like and how the user interacts with them.

We can then discuss this and move towards implementation by mapping these onto current functions and specifying issues to implement the functionality.

[seabbs]

@parksw3 @kgostic @athowes I think this or something like it should be a priority so it can form the basis of future discussions

[athowes]

By "being a priority" do you mean 1. agreeing on whether this is the approach we are taking, 2. taking this approach and creating vignettes with "fake" functions (they're not fake, but they're not functions in the package).

[seabbs]

both

[parksw3]

I'm not familiar with the term "documentation driven design". Is it this? https://gist.github.com/zsup/9434452

[athowes]

I think this is more of a point of discussion than an issue to be resolved with a PR.

[seabbs]

Closing as this has now moved to an issue that specifies the work to do (#48)