Re: constructive criticism to make this list more useful to more people:
Suggestion 1: accommodate questions related to non-base-R packages
This has been addressed by many already. The current
de facto situation is that such questions are asked and often answered.
Perhaps the posting guide should be altered so that such questions fall
within the guidelines.
Suggestion 2: expand beyond plain-text mode
I assume there is a reason for this restriction but
it seems to create a lot of delay and often havoc. Also, many questions on
this list relate to graphics which is an important part of R (even base R)
and such questions may often be more easily communicated with images.
Eric
On Thu, Jan 13, 2022 at 6:08 PM John Fox <jfox at mcmaster.ca> wrote:
> Dear Avi et al.,
>
> Rather than proliferating R mailing lists, why not just allow questions
> on non-standard packages on the r-help list?
>
> (1) If people don't want to answer these questions, they don't have
to.
>
> (2) Users won't necessarily find the new email list and so may post to
> r-help anyway, only to be told that they should have posted to another
> list.
>
> (3) Many of the questions currently posted to the list concern
> non-standard packages and most of them are answered.
>
> (4) If people prefer other sources of help (as listed on the R website
> "getting help" page) then they are free to use them.
>
> (5) As I read the posting guide, questions about non-standard packages
> aren't actually disallowed; the posting guide suggests, however, that
> the package maintainer be contacted first. But answers can be helpful to
> other users, and so it may be preferable for at least some of these
> questions to be asked on the list.
>
> (6) Finally, the instruction concerning non-standard packages is buried
> near the end of the posting guide, and users, especially new users, may
> not understand what the term "standard packages" means even if
they find
> their way to the posting guide.
>
> Best,
> John
>
> --
> John Fox, Professor Emeritus
> McMaster University
> Hamilton, Ontario, Canada
> web: https://socialsciences.mcmaster.ca/jfox/
>
> On 2022-01-12 10:27 p.m., Avi Gross via R-help wrote:
> > Respectfully, this forum gets lots of questions that include non-base
R
> components and especially packages in the tidyverse. Like it or not, the
> extended R language is far more useful and interesting for many people and
> especially those who do not wish to constantly reinvent the wheel.
> > And repeatedly, we get people reminding (and sometimes chiding) others
> for daring to post questions or supply answers on what they see as a pure R
> list. They have a point.
> > Yes, there are other places (many not being mailing lists like this
one)
> where we can direct the questions but why can't there be an official
> mailing list alongside this one specifically focused on helping or just
> discussing R issues related partially to the use of packages. I don't
mean
> for people making a package to share, just users who may be searching for
> an appropriate package or using a common package, especially the ones in
> the tidyverse that are NOT GOING AWAY just because some purists ...
> > I prefer a diverse set of ways to do things and base R is NOT enough
for
> me, nor frankly is R with all packages included as I find other languages
> suit my needs at times for doing various things. If this group is for
> purists, fine. Can we have another for the rest of us? Live and let live.
> >
> >
> > -----Original Message-----
> > From: Duncan Murdoch <murdoch.duncan at gmail.com>
> > To: Kai Yang <yangkai9999 at yahoo.com>; R-help Mailing List
<
> r-help at r-project.org>
> > Sent: Wed, Jan 12, 2022 3:22 pm
> > Subject: Re: [R] how to find the table in R studio
> >
> > On 12/01/2022 3:07 p.m., Kai Yang via R-help wrote:
> >> Hi all,
> >> I created a function in R. It will be generate a table
"temp". I can
> view it in R studio, but I cannot find it on the top right window in R
> studio. Can someone tell me how to find it in there? Same thing for
f_table.
> >> Thank you,
> >> Kai
> >> library(tidyverse)
> >>
> >> f1 <- function(indata , subgrp1){
> >> subgrp1 <- enquo(subgrp1)
> >> indata0 <- indata
> >> temp <- indata0 %>% select(!!subgrp1) %>%
arrange(!!subgrp1) %>%
> >> group_by(!!subgrp1) %>%
> >> mutate(numbering =row_number(), max=max(numbering))
> >> view(temp)
> >> f_table <- table(temp$Species)
> >> view(f_table)
> >> }
> >>
> >> f1(iris, Species)
> >>
> >
> > Someone is sure to point out that this isn't an RStudio support
list,
> > but your issue is with R, not with RStudio. You created the table in
> > f1, but you never returned it. The variable f_table is local to the
> > function. You'd need the following code to do what you want:
> >
> > f1 <- function(indata , subgrp1){
> > subgrp1 <- enquo(subgrp1)
> > indata0 <- indata
> > temp <- indata0 %>% select(!!subgrp1) %>%
arrange(!!subgrp1) %>%
> > group_by(!!subgrp1) %>%
> > mutate(numbering =row_number(), max=max(numbering))
> > view(temp)
> > f_table <- table(temp$Species)
> > view(f_table)
> > f_table
> > }
> >
> > f_table <- f1(iris, Species)
> >
> > It's not so easy to also make temp available. You can do it with
> > assign(), but I think you'd be better off splitting f1 into two
> > functions, one to create temp, and one to create f_table.
> >
> > Duncan Murdoch
> >
> > ______________________________________________
> > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
[[alternative HTML version deleted]]
I concur on both of Eric's suggestions below. I love R but I couldn't imagine using it on a daily basis without "key" packages for various regression and classification modeling problems, etc. Likewise on being able to embed images (within reason... maybe establish a max KB or MB file size for attachments). Thanks, Tom On 2022-01-13 12:25, Eric Berger wrote:> Re: constructive criticism to make this list more useful to more > people: > > Suggestion 1: accommodate questions related to non-base-R packages > This has been addressed by many already. The > current > de facto situation is that such questions are asked and often answered. > Perhaps the posting guide should be altered so that such questions fall > within the guidelines. > > Suggestion 2: expand beyond plain-text mode > I assume there is a reason for this restriction > but > it seems to create a lot of delay and often havoc. Also, many questions > on > this list relate to graphics which is an important part of R (even base > R) > and such questions may often be more easily communicated with images. > > Eric > > > > > On Thu, Jan 13, 2022 at 6:08 PM John Fox <jfox at mcmaster.ca> wrote: > >> Dear Avi et al., >> >> Rather than proliferating R mailing lists, why not just allow >> questions >> on non-standard packages on the r-help list? >> >> (1) If people don't want to answer these questions, they don't have >> to. >> >> (2) Users won't necessarily find the new email list and so may post to >> r-help anyway, only to be told that they should have posted to another >> list. >> >> (3) Many of the questions currently posted to the list concern >> non-standard packages and most of them are answered. >> >> (4) If people prefer other sources of help (as listed on the R website >> "getting help" page) then they are free to use them. >> >> (5) As I read the posting guide, questions about non-standard packages >> aren't actually disallowed; the posting guide suggests, however, that >> the package maintainer be contacted first. But answers can be helpful >> to >> other users, and so it may be preferable for at least some of these >> questions to be asked on the list. >> >> (6) Finally, the instruction concerning non-standard packages is >> buried >> near the end of the posting guide, and users, especially new users, >> may >> not understand what the term "standard packages" means even if they >> find >> their way to the posting guide. >> >> Best, >> John >> >> -- >> John Fox, Professor Emeritus >> McMaster University >> Hamilton, Ontario, Canada >> web: https://socialsciences.mcmaster.ca/jfox/ >> >> On 2022-01-12 10:27 p.m., Avi Gross via R-help wrote: >> > Respectfully, this forum gets lots of questions that include non-base R >> components and especially packages in the tidyverse. Like it or not, >> the >> extended R language is far more useful and interesting for many people >> and >> especially those who do not wish to constantly reinvent the wheel. >> > And repeatedly, we get people reminding (and sometimes chiding) others >> for daring to post questions or supply answers on what they see as a >> pure R >> list. They have a point. >> > Yes, there are other places (many not being mailing lists like this one) >> where we can direct the questions but why can't there be an official >> mailing list alongside this one specifically focused on helping or >> just >> discussing R issues related partially to the use of packages. I don't >> mean >> for people making a package to share, just users who may be searching >> for >> an appropriate package or using a common package, especially the ones >> in >> the tidyverse that are NOT GOING AWAY just because some purists ... >> > I prefer a diverse set of ways to do things and base R is NOT enough for >> me, nor frankly is R with all packages included as I find other >> languages >> suit my needs at times for doing various things. If this group is for >> purists, fine. Can we have another for the rest of us? Live and let >> live. >> > >> > >> > -----Original Message----- >> > From: Duncan Murdoch <murdoch.duncan at gmail.com> >> > To: Kai Yang <yangkai9999 at yahoo.com>; R-help Mailing List < >> r-help at r-project.org> >> > Sent: Wed, Jan 12, 2022 3:22 pm >> > Subject: Re: [R] how to find the table in R studio >> > >> > On 12/01/2022 3:07 p.m., Kai Yang via R-help wrote: >> >> Hi all, >> >> I created a function in R. It will be generate a table "temp". I can >> view it in R studio, but I cannot find it on the top right window in R >> studio. Can someone tell me how to find it in there? Same thing for >> f_table. >> >> Thank you, >> >> Kai >> >> library(tidyverse) >> >> >> >> f1 <- function(indata , subgrp1){ >> >> subgrp1 <- enquo(subgrp1) >> >> indata0 <- indata >> >> temp <- indata0 %>% select(!!subgrp1) %>% arrange(!!subgrp1) %>% >> >> group_by(!!subgrp1) %>% >> >> mutate(numbering =row_number(), max=max(numbering)) >> >> view(temp) >> >> f_table <- table(temp$Species) >> >> view(f_table) >> >> } >> >> >> >> f1(iris, Species) >> >> >> > >> > Someone is sure to point out that this isn't an RStudio support list, >> > but your issue is with R, not with RStudio. You created the table in >> > f1, but you never returned it. The variable f_table is local to the >> > function. You'd need the following code to do what you want: >> > >> > f1 <- function(indata , subgrp1){ >> > subgrp1 <- enquo(subgrp1) >> > indata0 <- indata >> > temp <- indata0 %>% select(!!subgrp1) %>% arrange(!!subgrp1) %>% >> > group_by(!!subgrp1) %>% >> > mutate(numbering =row_number(), max=max(numbering)) >> > view(temp) >> > f_table <- table(temp$Species) >> > view(f_table) >> > f_table >> > } >> > >> > f_table <- f1(iris, Species) >> > >> > It's not so easy to also make temp available. You can do it with >> > assign(), but I think you'd be better off splitting f1 into two >> > functions, one to create temp, and one to create f_table. >> > >> > Duncan Murdoch >> > >> > ______________________________________________ >> > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> > https://stat.ethz.ch/mailman/listinfo/r-help >> > PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> > and provide commented, minimal, self-contained, reproducible code. >> > >> > [[alternative HTML version deleted]] >> > >> > ______________________________________________ >> > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> > https://stat.ethz.ch/mailman/listinfo/r-help >> > PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> > and provide commented, minimal, self-contained, reproducible code. >> >> ______________________________________________ >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code.
Marc Schwartz
2022-Jan-13 20:08 UTC
[R] (Off-Topic) Time for a companion mailing list for R packages?
Eric, With respect to your second point, as one of the moderators for the R-Devel list, where the same considerations apply to all "official" R lists like R-Help here, the issue of plain text content restrictions is multi-factorial, partly with security considerations in mind, but has historically been imposed by the university (ETHZ) that hosts and archives all of these R related lists. It is also, historically, very common with open source communities generally. If one sends a message to the list that is only HTML, or perhaps a multi-part MIME message with both HTML and plain text sub-parts, the HTML markup will be stripped, leaving only the plain text part. You will usually see a line at the end of the post/reply as follows: ? "[[alternative HTML version deleted]]" when that occurs. When we see some messages here that appear to be a single, longish, unformatted and largely unreadable paragraph, with no obvious line/para breaks, where the sender may have actually formatted the message in HTML before sending, that is the result of the HTML filtering by the ETHZ server, perhaps also influenced by how the sender's e-mail client formatted the plain text sub-part of the message. That is why it is best, and recommended, to format the e-mail message natively in plain text only to begin with, and there are numerous e-mail clients that support that functional distinction. Also, there are still folks out there that use plain text only e-mail clients, yes in 2022, where we have to recognize and be sensitive to that reality as the official R support venues. With respect to attachments, a limited set of them are allowed here for the R lists. Primarily, these are PDF, [E]PS, PNG and JPG, which would generally accommodate the graphics related scenarios that you mention. As has been noted elsewhere in this thread, there are a number of other venues that provide R specific, community based, support using online forums with varying levels of, perhaps more "modern" functionality. The most prolific likely to be StackOverflow which, without any doubt, and to some extent via the gamification on that platform, has markedly reduced the traffic volume here over the years. That shift initially started in circa 2009 when that platform began, and then rapidly grew, with traffic volume on R-Help peaking in 2010. I occasionally run traffic volume reports comparing the two venues over time, and having been a part of the R community for ~20 years now, the drop-off here post 2010 is quite noticeable. I don't label that phenomenon as good or bad, it is simply the reality of the situation and this is not a competition for traffic. As noted in this thread, other locations find R related interactions as well, which would include LinkedIn, ResearchGate, RStudio's forums, and some package developers provide support via their GitHub repos, using the Issues functionality, even if not a bug. In the case of RStudio, having their own support forums, and as comes up here, there is frequently a lack of distinction between RStudio the third party GUI, and R itself, resulting in confusion by users, and subsequent "energetic" discussion here. I am not advocating the general use or non-use of any specific platform, but am primarily addressing the limitations here on the official lists as currently implemented. For the record, I am not an RStudio user and do not participate on StackOverflow, albeit, in the latter case, Google searches on technical subject matter do lead me there on occasion. We have had numerous online and offline discussions over the many years of sub-setting the official R lists by common subject matter. The challenge is always, how much granularity do you impose on the list structure, even if you just create an "R-Newbie" list, which specifically has been discussed many times over the years. The more granularity you impose, the more difficult it becomes to manage and interact with those "stove pipes", when there may not be a clear separation in subject matter, and there will be the inevitable overlap in content. You also need relevant, volunteer, community members to then be willing to moderate, subscribe to and participate on those multiple lists, if they are to be of value. That would be the challenge even with an R-Packages list. Will every, or most, or the most popular, third party package developers subscribe to that list, so that if someone posts a query, they are likely to get a timely reply? Would enough community members with relevant experience do so? Or would a useR then re-post the query to R-Help after a period of time of no replies anyway, and in time, give up on the other list due to the lack of traffic? For many third party packages, especially those that have a longer history and have a reasonable useR base, posting here is fine in my mind, and helpful community replies are reasonable to expect. For others, communicating with the package maintainer directly may be the only recourse, because there is perhaps not broad experience with the package in the community. It may be difficult for the useR of such a package to make that distinction a priori, unless they (hopefully) take the time to search the list archives first, perhaps using rseek.org or Google, which is also recommended. I always begin with the assumption that the question that I have has been asked before, and hopefully an answer will also be present. That may be in the relevant documentation, including package vignettes where available, or otherwise online here or elsewhere. Certainly, if there is a bug or a reasonable suspicion of one in a third party package, the package maintainer should be the primary point of contact. Regards, Marc Schwartz Eric Berger wrote on 1/13/22 12:25 PM:> Re: constructive criticism to make this list more useful to more people: > > Suggestion 1: accommodate questions related to non-base-R packages > This has been addressed by many already. The current > de facto situation is that such questions are asked and often answered. > Perhaps the posting guide should be altered so that such questions fall > within the guidelines. > > Suggestion 2: expand beyond plain-text mode > I assume there is a reason for this restriction but > it seems to create a lot of delay and often havoc. Also, many questions on > this list relate to graphics which is an important part of R (even base R) > and such questions may often be more easily communicated with images. > > Eric<...earlier content snipped...>