Thank you for considering to help out!

QDECR started as a side project to make QDEC and mri_glmfit more accessible to members of our department. The desire for additional features kept growing, and so we decided to reprogram everything in R. Over time we have developed QDECR to fit our specific needs, but those may differ from what you - the user - may need. We therefore decided to make QDECR accessible early on, so that it can become a community-driven project.

1 Before Contributing

1.1 Code Of Conduct

Working on open source projects is extremely fulfilling, but it does require everyone to work together. As such we work with a code of conduct (found here) for the QDECR project.

1.2 Communication

I created a Gitter community for QDECR that can be found here:

  • questions: For questions about the package
  • dev: For communication related to contributions (AKA this page!)
  • QDECR: A general room for anything

2 Ways To Contribute

2.1 Finding And Reporting Bugs

You may notice issues with QDECR that seem unintentional. These can be reported on the issues page on Github.

2.2 Modifying Or Adding Code

Users are also free to modify and add code through pull requests.

2.3 Suggesting Ideas

QDECR is a framework that can be extended into many directions. A lot of users have already reported ideas, which we are often happy to implement. However, due to the limited time the main developers we cannot implement all suggestions. We aim to implement features that:

  • Help QDECR to become more canonical
  • Address problems many users have
  • Open QDECR to new fields of study

Users can suggest ideas in the Gitter community. A lot of priority projects can be found below, under List Of Features To Implement.

2.4 Developing Educational Resources

We originally developed QDECR to help out members of our department who were not familiar with Bash, design matrices, etc. Making QDECR accessible is therefore one of our main goals. We therefore also welcome all resources that will help explain the package to others. Several possibilities:

3 How To Contribute

QDECR generally works with three branches:

  • master: The stable version of the package that normal users work with
  • dev: The development version for modification and pull requests
  • gh-pages: The code for the website

The general workflow for contributing:

  • Consider where you want to contribute:
    • QDECR package: Please branch off the dev branch. This helps us control the release of minor and major changes.
    • website: Please branch off the gh-pages branch.
  • Look through the issues and see if any match what you want to do. If so, leave a comment there with what you want to do.
  • If your issue is unique, then open a new issue.
  • Make sure that any pull request is small and self-contained. To smooth out the process, try breaking up big changes into smaller ones. This helps with keeping an overview of what is ready to be merged and what is not.
  • Feedback on the pull request can take some time and the request may need some iterations of modification. Still, we aim to incorporate all modifications that improve the QDECR project.

4 List Of Features To Implement

At OHBM 2019 we had both a poster and a software demo for QDECR. During those sessions, many of you had great suggestions on how to improve the project. Below we have outlined some of those suggestions that have a high priority for us.

4.1 Lower Resource Usage

QDECR has always been a typical programming project: first get it working, then get it working smoothly. We have had several iterations of the vertex-wise code and of storing all the data, and we believe several more iterations are needed to optimize speed and reduce RAM burden. We have some solutions that we will try to implement soon, but any suggestions here are welcome.

4.2 Permutation Testing

QDECR currently only allows for one type of multiple testing correction. Ideally, we would implement full permutation testing, but this is not feasible. Luckily, several solutions exist to approximate full permutation testing. We aim to implement at least one of these approximations to improve statistical inference.

4.3 Mixed Models

There is a large demand for mixed modeling, for example for longitudinal studies.

4.4 Input Agnosticism

The package is currently written to work with Freesurfer output. However, we have gotten multiple requests to allow for input from other software (CIVET, ANTs) and even other modalities (fMRI). We will likely implement a flexible module that calls functions for reading in the input. Ideally, users should be able to write their own i/o functions that can be used without our interference.