Enabling github templates for Issues and PRs #1893
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| For bug reports, please respect the following guidelines and check the boxes accordingly. | ||
|
|
||
| For questions of the type: "How can this be done?", please consider posting them on Stackoverflow. | ||
|
There was a problem hiding this comment. I don't know SO so well, but can we make a link to the relevant "tag" or whatever they call it, or possibly tell people to tag their relevant questions 'mlr'? |
||
|
|
||
| For everything else ignore this template. | ||
|
|
||
| ## Bug report | ||
|
|
||
| - [ ] Start a new R session | ||
|
There was a problem hiding this comment. possibly ask people to use There was a problem hiding this comment. Stuff in the .RData should not compromise mlrs functionality. Loaded namespaces are another thing. There was a problem hiding this comment. library("mlr")
library("parallelMap")
parallelStartMulticore(2)
parallelMap(function(x) resample("classif.IBk", pid.task, cv5), 1:2, simplify=FALSE)works if run in library("mlr")
m = train("classif.IBk", pid.task)
q("yes")it will hang. There was a problem hiding this comment. I guess most things are obviously bugs or non-bugs when run in any kind of environment; requiring the user to start a new R session (or maybe not even that) will be good enough for like 99% of all cases. There was a problem hiding this comment. I wouldn't bet 😉 That is a really strange behavior. Do we have an issue for that? There was a problem hiding this comment. This is mostly described in #1898; afaics there is not much we can do about it. There is also a way of triggering #1379 this way, which is really a PITA if you don't know what's going on. What I think happens is that objects in There was a problem hiding this comment. we dont want to overcomplicate this here. people should not be forced to run vanilla. |
||
| - [ ] Install the latest version of mlr: `update.packages(oldPkgs="mlr", ask=FALSE)` | ||
| - [ ] If you use a GitHub install of mlr: `devtools::install_github(c("BBmisc", "ParamHelpers", "mlr")) | ||
|
There was a problem hiding this comment. So how is someone supposed to tick all these boxes? Install the latest cran There was a problem hiding this comment. I will make one sentence |
||
| - [ ] [Give a minimal reproducible example](http://stackoverflow.com/a/5963610) | ||
|
There was a problem hiding this comment. I suggest not linking to an explanation what exactly comprises the kind of example we want. If I were just on the fence of reporting a bug, someone expecting me to read all of this this would push me towards not doing it. There was a problem hiding this comment. Also, possibly explicitly state to surround code blocks with There was a problem hiding this comment. I can remove the link. People will hopefully know what a reproducible example is. |
||
| - [ ] run `sessionInfo()` | ||
|
There was a problem hiding this comment. Do we not just get really cluttered bug reports when we ask for this? When was the last bug where this would have helped us recognize the issue faster? There was a problem hiding this comment. the sessionInfo helps with problem in eg learners. is see @mb706 point, but IMO it is easy to scroll over the sessionInfo. it dont think it hurts |
||
|
|
||
| ### Minimal reproducible example: | ||
|
|
||
| ```r | ||
| lrn = makeLearner("classif.lda") | ||
| resample(learner = lrn, task = iris.task, resampling = cv10) | ||
| ``` | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| We are always happy to receive pull requests. | ||
|
There was a problem hiding this comment. How do we decide whether a PR gets merged? Bugfix vs. added features? Relevance to what people within the mlr team are doing? Code quality? Maintainability? Willingness of the submitter to support their part of the code? Unspoken feelings of obligation when someone obviously puts lots of effort into his PR? Hope to get someone invested in mlr to make him post higher quality PRs in the future? (I actually don't know, but maybe we should make some of these explicit here.) There was a problem hiding this comment. I think the criteria at the moment is that somebody with merge privileges has a look at it... |
||
|
|
||
| Please make sure you have read our coding guidelines: https://github.com/mlr-org/mlr/wiki/mlr-Coding-Guidelines | ||
|
There was a problem hiding this comment. Maybe a short bullet point list of the most important points, in particular the points that are important for people doing only small fixes and unwilling to read through all of that. There was a problem hiding this comment. Lets brainstorm!
I'd assume most people who are at peril of submitting PRs to us (1) know how to use git and (2) (now that we don't rebase any more) know our process of doing PRs, so maybe add an encouraging "if you just do a small fix this is probably all you need to know" There was a problem hiding this comment.
There was a problem hiding this comment.
no, lets please NOT become redundant. people can click on links There was a problem hiding this comment. i am all for adding stuff which is not in the other docs |
||
|
|
||
| Also it's helpful to find a buddy from the core team who helps you getting your PR merged. | ||
|
There was a problem hiding this comment. Who is this "core team", and how will the contributor in spe know? There was a problem hiding this comment. Maybe link to this list? However, these are all contributors and not just the 'core' guys (I do not know myself who the core guys are) |
||
| You might want to join our slack channel! | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we prefer a badly written bug reports to no bug report at all? If so, maybe say so here ("these are suggestions, not rules" or something).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my experience badly written bug reports are mostly useless, so I'd prefer to keep this as it is.