search

bbfrederick / rapidtide

rapidtide - a suite of programs for doing time lag correlation analysis on fMRI data
Apache License 2.0
75 stars 14 forks source link

Usage-related questions and support section in docs #31

Closed tsalo closed 4 years ago

tsalo commented 4 years ago

Is your feature request related to a problem? Please describe. I am going to be using rapidtide for a couple of projects in the near future, but I will have some questions about how best to use it. I don't like cluttering up repos' issues with usage questions, so I thought I'd request a support section (not financial support, as is already in the docs, but more communication-related support) to clear things up.

Describe the solution you'd like One solution a lot of tools use is to point bug reports and feature requests to GitHub, and then to ask questions on NeuroStars. You can add a rapidtide tag and subscribe to that so that you get a notification any time anyone asks a rapidtide question.

Describe alternatives you've considered Usage questions could go to GitHub (which I assume is currently the case), but it would be nice to have that said explicitly in the documentation.

Additional context None.

bbfrederick commented 4 years ago

Sounds like a good idea. Is there standard language people put into the documentation to indicate this?

tsalo commented 4 years ago

In [tedana]() we have the following (with minor edits here):

All bugs, concerns and enhancement requests for this software can be submitted here: https://github.com/ME-ICA/tedana/issues.

If you would like to ask a question about usage or tedana’s outputs, please submit a question to NeuroStars with the tedana tag.

We will also attempt to archive certain common questions and associate answers in the Frequently Asked Questions (FAQ) page.

tsalo commented 4 years ago

I've opened a usage question here, so the tag has now been created and you can subscribe to it if you want.

I can open a PR to master (or would you prefer dev?) with an adapted version of the support information above if you'd like.

bbfrederick commented 4 years ago

Cool - thanks!

Probably a PR to master.

As an aside, what's the best way to do a massive merge? I guess I can to a PR to master from the dev branch, and accept it all as 2.0alpha1 or something (and label it prerelease). I left this too long for this to be easy, I'm afraid. I was just making so many changes to the internals I didn't want any danger of inconsistency leaking into the main branch.

tsalo commented 4 years ago

Okay, will do.

That sounds like a good plan for merging dev into master, although you might want to update dev from master first so that you can deal with merge conflicts and bugs before moving the changes into master.