Feature Request: Add examples to documentation.

[bear-jordan]

Hi, I would like to add coded examples for each method in the documentation to provide clear examples of implementation for new users. Would y'all have any interest in this project?

Right now, the documentation for an individual method looks like this...

HypothesisTests.EqualVarianceTTest
EqualVarianceTTest(nx::Int, ny::Int, mx::Real, my::Real, vx::Real, vy::Real, μ0::Real=0)

Perform a two-sample t-test of the null hypothesis that samples x and y described by the number
of elements nx and ny, the mean mx and my, and variance vx and vy come from distributions
with equals means and variances. The alternative hypothesis is that the distributions have different
means but equal variances.
Implements: pvalue, confint

At the end of the project, the documentation would include the coded section as seen below.

HypothesisTests.EqualVarianceTTest
EqualVarianceTTest(nx::Int, ny::Int, mx::Real, my::Real, vx::Real, vy::Real, μ0::Real=0)

Perform a two-sample t-test of the null hypothesis that samples x and y described by the number
of elements nx and ny, the mean mx and my, and variance vx and vy come from distributions
with equals means and variances. The alternative hypothesis is that the distributions have different
means but equal variances.
Implements: pvalue, confint

a1 = [30.02, 29.99, 30.11, 29.97, 30.01, 29.99]
a2 = [29.89, 29.93, 29.72, 29.98, 30.02, 29.98]
result = EqualVarianceTTest(a1, a2)

To complete the project, I plan to adapt the examples from the unit tests. I think it should be pretty straight forward!

Also, I looked for contribution guidelines but haven't seen any–have these been developed? Sorry if I missed them.

Best,
Bear Jordan

[ararslan]

Hi there, apologies for not responding sooner. If you're still willing to work on this, that sounds like a wonderful contribution!

We don't have any documented contribution guidelines (at least that I know of). The things I generally recommend in any context are:

• When adding functionality, ensure corresponding tests and documentation are added as well
• Try to match surrounding code style/patterns to make the codebase consistent
• When adding documentation, look for examples of really good documentation and try to emulate that. Those examples don't necessarily need to be from the same repository.
• Limit the scope of changes made in a single PR. It's okay to have multiple PRs open if they're unrelated, e.g. adding a function f and documenting a function g should be separate PRs but documenting f and documenting g could be together since review comments may be applicable to both.
• If you haven't heard back from a reviewer for a while, feel free to ping them. If they're anything like me (or if they are me), they get a lot of notifications and may miss stuff so a reminder doesn't hurt.

[ShrutiRDalvi]

hello, is someone working on this already? if not I'd love to work on it. I'm new to opensource so any guidelines on how to go about it would help, thanks a lot!

[bear-jordan]

Hi, I am not working on it. Not sure if anyone else has picked it up though. Hope it goes well!

[mschauer]

Go for it!