search

r-devel / rcwg

R Contribution Working Group: fostering a larger, more diverse community of contributors to R core development
https://contributor.r-project.org/working-group
73 stars 17 forks source link

Dev stream at useR! 2021? #4

Closed lauracion closed 3 years ago

lauracion commented 4 years ago

Hi,

The organization of useR! 2021 global is getting started. I am part of the program team and based on previous activities of R Core members in useR! I would like to bring ideas to the useR team on how R Core can be more present and interact more with useR! participants. Titling this issue as "dev stream" because several forms of participation could be organized such as a keynote, tutorials, mixer, coding sprints, breakout sessions, etc according to whom we can get on board for what.

Do you have any ideas, preferences, views, opinions on how to go about this? Please add them and let´s get the ball rolling! 😸

Thank you! 🙏

hturner commented 4 years ago

I notice R Core have added a HELPWANTED keyword on bugs.r-project.org for tagging bugs and issues where a good well-tested patch would be particularly appreciated. You can see the current issues here: https://bugs.r-project.org/bugzilla/buglist.cgi?keywords=HELPWANTED.

Maybe we can build an activity around this? I.e. small groups work together to try and fix a bug, maybe the day or the weekend before useR!? We'd obviously have to think through the details, especially how this could work online without too much pain, but maybe it is something we can pilot as a group to find something that works.

gmbecker commented 3 years ago

I proposed a couple of different talks to userR last year (19), I was too late for that luckily @hturner remembered and reached out. I'd be happy to present one or both of these, as well as being involved in the efforts more broadly.

  1. The ALTREP framework, using it in packages, what it means for R internals, and where I hope we're able to go with it moving forward*
  2. My experiences, strategies and advice on contributing feature additions to the R language itself and interacting with (members of) the R-core as a non-member.

*Unless Luke Tierney is presenting on the ALTREP framework, in which case I would defer to his expertise on (1).

I also have some experience in driving and fostering comingling between R-core members and community members from my organization of the DSC for the past couple of years. Last year's had the highest gender diversity of any recent DSC I know of, and was heavily enriched for community members who had never (to my knowledge) interacted significantly in person with many R-core members.

mine-cetinkaya-rundel commented 3 years ago

I think an activity around this at/related to useR is a great idea. I don't have any experience contributing to R core but I'd be happy to collaborate on crafting an activity around it and learn along the way. I'm familiar with tidy dev day but I feel like this would need to be different in a few ways, e.g. it might be more productive to make it more structured, with an expectation that everyone works in small teams rather than individually, and potentially forming those teams ahead of based on a few survey questions we can ask participants ahead of time.

I can think of a few things that would be useful to get feedback from R core early in the planning:

jtr13 commented 3 years ago

These are all wonderful ideas. Personally speaking, starting out by trying to fix a bug sounds very ambitious, though certainly don't want to discourage anyone who is up to the task. I would vote for starting with learning more about how the whole system works, helping with documentation, learning where to ask if behavior is intended, how to report a bug, etc. +1 on having an R Core member involved who among other things can steer us in the direction of welcome contributions. -Joyce

gmbecker commented 3 years ago

So this would take some doing, but a thought I had that there wasn't time to mention in the call, is that instead of reserving bugs (and thus, keeping them in place artificially), it might be good to select a few case study bugs that have been fixed, and retroactively capture/recreate the process of fixing them.

One benefit here is that we actually have proven, in a form they would be accepted patches for the bugs in question.

Candidate bugs would ideally

If there are bugs of this nature that we can find, one of the nice things about version control (of any flavor) is that we can step back into the exact state directly before the bug was fixed and work through the bug.

Finding these bugs may well be seriously non-trivial, but (without having yet done it) I think its possible to get an initial candidate set for consideration/pruning by mining the SVN logs.

@mmaechler may also remember some bugs that might fit this description off the top of his head.

That is all if we decide this is a good idea at all.

lauracion commented 3 years ago

Thank you for all these valuable ideas and brainstorming for R Core related activities at useR2021! Please keep them coming!

Ping me if you would like to join useR2021 Slack where we discuss Program details.

Not a problem if you prefer to not have yet another Slack though, I will be summarizing all the ideas here and bringing them to the useR2021 program team 😄

hturner commented 3 years ago

This discussion resulted in the two Contributor focused tutorials at useR! 2021: Contributing to R and Translating R to your Language. So closing for this year!