Contributions to developing the package are most welcome.
Great to have you here.
qmethod was created by Aiora Zabala, with contributions by Max Held and Frans Hermans. Some friendly suggestions for contributing:
Communication on developing this package happens right here on our GitHub issues and by email. If you have any suggestion, you can raise it here as a new issue, send us an email, or both – that way, we can keep everyone in the loop and have a public record. If you can, browse the existing issues first to avoid duplication.
To learn more about the current state of development:
qmethodworks (can also be found under
qmethodwebsite for some additional documentation.
qmethod is under development, and we’re keen to have more beta-test new features. Here](./Development) is how.
There’s so much more to do, and we’re excited for new additions. We’re roughly following the GitHub Flow development model:
backlogmilestone if it’s not happening anytime soon.
aiorazabala/qmethod/masterfrequently, so as to stay up to date and minimize merge conflicts (here’s how).
WIP(for work-in-progress) so that other people can provide early feedback and know what’s being worked on.
WIP-prefix once the work is done. At this stage, a feature should be fully documented and tested (passing
R CMD checkon all platforms). Notice that Travis CI included here on GitHub only tests on Linux machines; @maxheld83 can test on OS X and
win-builderon Windows, if you do not have these platforms yourself.
qmethodwill then review the changes and accept the pull request if possible. By accepting, the pull request is then merged into @aiorazabala’s
master, essentially just marking some point in the history of the package as
x.x.x, and sends it off to CRAN.
Testing is an important part of quality software development, especially for scientific software, where users rely on the accuracy and reproducibility of results.
Most essentially, any changes should pass the tests for submitting packages to CRAN. This involves running the following in your command line:
R CMD check --as-cran qmethod_1.4.0.tar.gz
and running the package through WinBuilder, or
R-devel CMD check --as-cran qmethod_1.4.0.tar.gz
…and getting no errors (or solving whatever may arise).
If in the CRAN package checks for qmethod, your changes induce any change in the ‘OK’ Status, the maintainer(s) will poke you to fix it.
It is advised that new functions and changes come with appropriate tests:
q.mrot.choose, the interactive rotation function, should always produce a rotation matrix of
rank == nfactors(pseudo-code; the number of factors should be the same as the rank of the rotation matrix).
>= 1.2.0) known to be validated by Aiora against
PQMethod(see Zabala 2014).
In addition to such tests for new functions, missing tests for old functions [would also be very welcome].
We give a lot of importance to the usability of the package. Whether you’ve developed a fantastic function won’t matter, if it is not easy to use. For this, we believe that good documentation is essential. Please make sure that all new functions are well documented in the help pages. Some general points to observe when writing the help:
If you’re unfamiliar with Git(Hub), it’s probably worth spending some time learning these tools and conventions first.
Here are some great places to start: