Add contributing guide with overview of package architecture

[jdblischak]

I added a CONTRIBUTING.md that provides an overview of how we store the various clinical trial design characteristics in our R objects.

xref: #457, #584

I didn't add a diagram of the class hierarchy because it is so flat. Each of our S3 methods only dispatches to two possible classes, and there is no inheritance between classes. Of course I'm open to ideas on how to create an informative diagram.

gsDesign2/NAMESPACE

Lines 3 to 13 in 9098bde

	S3method(as_gt,fixed_design_summary)
	S3method(as_gt,gs_design_summary)
	S3method(as_gt,simtrial_gs_wlr)
	S3method(as_rtf,fixed_design_summary)
	S3method(as_rtf,gs_design_summary)
	S3method(print,fixed_design)
	S3method(print,gs_design)
	S3method(summary,fixed_design)
	S3method(summary,gs_design)
	S3method(to_integer,fixed_design)
	S3method(to_integer,gs_design)

[yihui]

Looks great to me! Thanks!

[yihui]

I wonder why we named this element design originally instead of method or test. Maybe this is more of a question for @LittleBeannie.

[jdblischak]

I had the same thought. It made it difficult to write this documentation when in one sentence "design" refers to "fixed versus group sequential" and the next sentence it refers to the test method

[nanxstats]

The content looks great! Simple to comprehend.

Since this is a "design doc" document, should we put it as a vignette or article? I mean, CONTRIBUTING.md is often used to document logistical aspects of how to make contributions, not the technical design of the package itself.

[jdblischak]

The content looks great! Simple to comprehend.

Thanks!

Since this is a "design doc" document, should we put it as a vignette or article? I mean, CONTRIBUTING.md is often used to document logistical aspects of how to make contributions, not the technical design of the package itself.

I'm fine with whatever we decide on. My thinking is that this information is mainly of interest to developers and less so to end users. The technical overview of the package architecture serves as the introduction/context to the explanation of the logistical aspects of making a contribution (e.g. when to use inherits() or attr()).

[jdblischak]

As discussed in group meeting, I moved the content to an article to be displayed on the pkgdown website