Closed karthik closed 9 years ago
I don't think rOpenSci's devs are being asked to spend time on the project, unless it's a project that they (individually) want to work on. I guess a better initial question would be: what's your definition of "scientific"?
For me, I'd like client libraries to datastores, readers for new and old data types, that sort of thing. If that's "scientific", let's science. If it's not scientific, and you want to keep this fixed on science, forking seems like a good idea :)
I don't think rOpenSci's devs are being asked to spend time on the project, unless it's a project that they (individually) want to work on. I guess a better initial question would be: what's your definition of "scientific"?
I understand that. But even the time we spend curating and helping with this list becomes an activity of ours. We cannot spend time answering questions for someone interested in a gaming package of some sort (as you can tell I have no idea about this stuff). Similarly a package that queries US weekly and weekly world news is not really of interest to us. Scientific is loose, but we in this context anything that will be useful to the scientific community.
For me, I'd like client libraries to datastores, readers for new and old data types, that sort of thing.
Sure, that would squarely fall as something a researcher/scientist could add to their workflow.
Aha, makes sense. Then scope-narrowing? In fact, in the issue about proposed docs, maybe we should change "what is your target audience?" to "how does this help researchers/scientists?"
"what is your target audience?" to "how does this help researchers/scientists?"
Perfect!
Once we fine tune this, anyone can spin off for their respective communities. A bit like SO. Some questions might be fine under cross validated OR general SO but the community leaders weight in and suggest moving to relevant umbrella.
Makes total sense, and I love the analogy!
Cool, glad we're on the same page. I'll close this up.
Not sure how to deal with this note. A general R wishlist could grow really long, and if it's out of our scope, we can't really justify much time on it. Same reason there is no catch all task view. Perhaps we could create a second repo elsewhere (once we resolve the workflow here) and limit these to science use cases?