diff --git a/.github/SUPPORT.md b/.github/SUPPORT.md new file mode 100644 index 0000000..736d131 --- /dev/null +++ b/.github/SUPPORT.md @@ -0,0 +1,35 @@ +# Getting help with ManyEcoEvo + +Thanks for using ManyEcoEvo! +Before filing an issue, there are a few places to explore and pieces to put together to make the process as smooth as possible. + +## Make a reprex + +Start by making a minimal **repr**oducible **ex**ample using the [reprex](https://reprex.tidyverse.org/) package. +If you haven't heard of or used reprex before, you're in for a treat! +Seriously, reprex will make all of your R-question-asking endeavors easier (which is a pretty incredible ROI for the five to ten minutes it'll take you to learn what it's all about). +For additional reprex pointers, check out the [Get help!](https://www.tidyverse.org/help/) section of the tidyverse site. + +## Where to ask? + +Armed with your reprex, the next step is to figure out [where to ask](https://www.tidyverse.org/help/#where-to-ask). + +* If it's a question: start with [community.rstudio.com](https://community.rstudio.com/), and/or StackOverflow. There are more people there to answer questions. + +* If it's a bug: you're in the right place, [file an issue](https://github.com/egouldo/ManyEcoEvo/issues/new). + +* If you're not sure: let the community help you figure it out! + If your problem _is_ a bug or a feature request, you can easily return here and report it. + +Before opening a new issue, be sure to [search issues and pull requests](https://github.com/egouldo/ManyEcoEvo/issues) to make sure the bug hasn't been reported and/or already fixed in the development version. +By default, the search will be pre-populated with `is:issue is:open`. +You can [edit the qualifiers](https://help.github.com/articles/searching-issues-and-pull-requests/) (e.g. `is:pr`, `is:closed`) as needed. +For example, you'd simply remove `is:open` to search _all_ issues in the repo, open or closed. + +## What happens next? + +To be as efficient as possible, development of tidyverse packages tends to be very bursty, so you shouldn't worry if you don't get an immediate response. +Typically we don't look at a repo until a sufficient quantity of issues accumulates, then there’s a burst of intense activity as we focus our efforts. +That makes development more efficient because it avoids expensive context switching between problems, at the cost of taking longer to get back to you. +This process makes a good reprex particularly important because it might be multiple months between your initial report and when we start working on it. +If we can’t reproduce the bug, we can’t fix it!