Steffi LaZerte

rOpenSci

Stefanie Butland

Nicholas Tierney

We're excited to announce that we'll be hosting monthly social
coworking + office hours sessions via Zoom, starting September 7th!

Coworking is a great way to be productive and reduce feelings of social
isolation (especially important over the last year)!

These sessions will give you the opportunity to

- Meet other package developers and rOpenSci staff
- Cowork independently on work related to R (and perhaps focus on work
  that often gets neglected)
- Get answers to your questions

We will host sessions on the first Tuesday of each month, alternating
times to accommodate different parts of the world.Come for the full 2
hrs or only as long as you need!

Our first two sessions take place **[Tuesday September 7th 2021 9-11am
American Pacific time](/events/coworking-2021-09/)** hosted by [Steffi
LaZerte](/author/steffi-lazerte/) and **[Tuesday October 5th 2021 9-11am
Australian Western time](/events/coworking-2021-10/)** hosted by [Nick
Tierney](/author/nicholas-tierney/).

## Format

We'll be following the format we developed during our experimental
label-athons:

1.  We start with introductions, giving everyone a chance to socialize
    and network before getting down to business
2.  We work for 30min either in a Quiet or Noisy room
    - Mix and match as you like
    - 'Noisy' room is for discussing problems, asking questions, and
      chatting
3.  We have 5-min breaks with fun scavenger hunts to get you up and
    moving
4.  Repeat! We'll do a total of 3x 30min work blocks each separated by a
    5-min break
5.  Wrap up, a chance to share what we did and say good bye

## Building on our successful Label-athon experiment

In case you missed it, as a follow up to the community call [Set Up Your
Package to Foster a
Community](/blog/2021/04/28/commcall-pkg-community/),this past spring
and summer we experimented with hosting four coworking label-athon
events on Zoom.

During these events, participants introduced themselves and shared what
they wanted to work on.We had two Zoom rooms, a quiet work room and a
'noisy' chat room, where we could socialize, ask questions, or discuss
our work.

In line with the theme of the community call, we encouraged participants
to work on making their packages more contributor friendly, such as
labelling issues to invite contributions, or creating road maps.However,
this wasn't a requirement for participation and many people worked on
other things such as general package development and organization,
research and planning for future development, setting up personal GitHub
READMEs and preparing useR! 2021 presentations.

We set up a work-flow to identify rOpenSci packages with [issues
labelled "help
wanted"](https://github.com/search?q=org%3Aropensci+label%3A%22help+wanted%22+state%3Aopen&type=Issues),
so we can tweet anything that came out of the coworking events.

We had quite an international turn out, with 3-8 participants per event
from 12 countries.Feedback was overwhelmingly positive, with
participants enjoying the opportunity to work on neglected projects, ask
questions about package development, meet other devs and participate in
the fun scavenger hunts 😸

These were a few of their favorite things:

- *"The vibe. Welcoming, friendly, and down-to-business."*
- *"It was nice to be accountable and have friends around ..."*
- *\"\[The organizers\] "...did a *great* job creating a welcoming
  environment and helping normalize that non-coding work, like
  documentation, is a valuable part of software development.\"*
- *"Hearing what other people were working on. Being able to ask
  questions. A sense of community."*

Come join us!


We’re excited to announce that we’ll be hosting monthly social coworking + office hours sessions via Zoom, starting September 7th!

rOpenSci Introduces Monthly Social Coworking and Office Hours

Sina Rüeger

Maëlle Salmon

Hugo Gruson

Mark Padgham

Last Thursday we held a [Community
Call](/commcalls/apr2021-pkg-community/) discussing how to set up a
Package to Foster a Community.

This call included speakers [Maëlle
Salmon](/author/ma%C3%ABlle-salmon/), [Hugo Gruson](/author/hugo-gruson)
and [Steffi LaZerte](/author/steffi-lazerte), and was moderated by
[Stefanie Butland](/author/stefanie-butland).

<figure class="center">
<img src="speakers.png" width="600"
alt="Headshots of the three speakers" />
</figure>

## Summarizing the community call

Scientific software development - and with that R packages - is a
community effort. While there are often just a handful of developers
maintaining an R package, the development really starts to thrive when
users start to contribute.

In principle, every open source package has an open invitation to
contribute. The question is how this invisible rule can be turned into
something more explicit (and less intimidating) so that users who want
to contribute can do so easily and feel welcomed and at ease. This
brings us to the topic of rOpenSci's last community call.

Over the course of an hour, the three speakers emphasised various
aspects of an R package that can be used to invite code contributions,
and to manage expectations of both users and contributors, for example
through a contributor guide, or through explicit instructions how to use
issues on GitHub. Speakers also emphasised the importance of the "soft
skills" of package maintainers, especially the importance of considering
the effect of how package maintainers interact with contributors, such
as fostering opportunities to learn, being kind when saying "no", and
always acknowledging contributions.

### Speakers

The three speakers were:

- **Maëlle Salmon**, a research software engineer, part-time with
  rOpenSci
- **Hugo Gruson**, a research software engineer and evolutionary
  biologist
- **Steffi LaZerte**, an R programming consultant, and part-time
  community assistant at rOpenSci

### Material

- [Living
  document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit)

- [Recording](/commcalls/apr2021-pkg-community/)

- [Labelathon](/events/labelathon01/)

### Maëlle Salmon: Community of a package ([video](https://vimeo.com/540502735#t=4m55s)) {#maëlle-salmon-community-of-a-package-videohttpsvimeocom540502735t4m55s}

A package has many different actors - the package authors, the users,
the contributors - and they may act and interact with each other in a
variety of ways.

Each role has slightly different needs. Everyone wants a better,
well-maintained package. But the authors may want citations and grateful
users, the users themselves may want certain features, and the
contributors might seek recognition.

Also, authors may need help in tackling issues and who better to help
than someone with a user perspective!

Before diving into tips, Maëlle talked about how authors can improve
their communication with contributors. One of the best ways to encourage
and retain contributors is simply being kind. But emojis can also be a
great tool to compensate for lack of nuances, for example, when having
to say "no".

Maëlle then suggested **three steps** to foster a community for a
package:

#### 1. Define rules & standards for your package

Some "rules & standards" include:

- Add a **code of conduct**: `usethis::use_code_of_conduct()`
- Add a **citation** to help people to cite your package:
  `usethis::use_citation()`
- Add a **contribution guide**: store as `CONTRIBUTING.md`, add style
  preferences, process preferences, scope lined out, how you prefer
  testing to work.

#### 2. Add them in publicly visible places

#### 3. Help users & contributor find them

Add links everywhere: in GitHub repository and pkgdown website.

<figure class="center">
<img src="summary_maelle.png" width="600"
alt="Summary slide of Maelles talk: Conclusion: Summarize the rules and quirks of your pakcage; Store them in standard places; Help users &amp; contributors find them. and the whole time, be kind!" />
</figure>

### Hugo Gruson: Journey from user to contributor ([video](https://vimeo.com/540502735#t=20m00s)) {#hugo-gruson-journey-from-user-to-contributor-videohttpsvimeocom540502735t20m00s}

Hugo spelled out the obvious - that every package contributor is a) a
user first and b) starts out as a beginner.

Hugo himself followed his favourite package where at one point he
noticed something that needed fixing. So he fixed it - an intimidating
process at first. But he repeated that, and after some time became an
official maintainer.

Hugo's talk focussed on how to facilitate the transition from user to
contributor and suggested **five tips** for package maintainers to make
contributing less scary:

#### 1. Have confidence in your project + expect contribution

(if you don't, you may miss messages from users)

#### 2. Show that you are available and want to communicate

Use GitHub, Twitter, email for that. For example, tweet the NEWS file
after a release.

#### 3. Don't let contributors work for nothing / feel ignored

- Mention the name of the person.
- Keep them in the loop.
- Always have the latest version on GitHub.
- Share a roadmap of project.

#### 4. Reduce workload for contributors

- Disable failing tests.
- Disable unimportant bots (Hugo mentioned the notoriously confusing
  coverage bot)

#### 5. Leave opportunities to learn

In GitHub, don't abuse "allow edits from maintainers", as this is
demotivating ("Don't take the keyboard from the learner", Carpentry)

<figure class="center">
<img src="summary_hugo.png" width="600"
alt="Summary slide of Hugo&#39;s talk: Have confidence in your project and expect contribution; Show that you are available and want to communicate; Don&#39;t let contributors work for nothing / feel ignored; Reduce the workload; But leave opportunities to learn" />
</figure>

### Steffi LaZerte: GitHub Issues as the low hanging fruits ([video](https://vimeo.com/540502735#t=32m28s)) {#steffi-lazerte-github-issues-as-the-low-hanging-fruits-videohttpsvimeocom540502735t32m28s}

Steffi found the low-hanging fruits in making packages more
contributor-friendly - [GitHub issues](https://github.com/issues)!

GitHub issues can be labeled, and labels can be searched by users who
want to become contributors but are maybe too shy to tackle an
unlabelled issue.

So why not label some well-defined issues with `"help wanted"`, a clear
open invitation to users.

Other options for labeling include:

<figure class="center">
<img src="summary_steffi.png" width="600"
alt="Alternative issue labels from Steffi&#39;s talk: help wanted; good first issue; documentation; feature" />
</figure>

Because package maintainers rarely have time for this, the idea of a
[social **label-athon**](/events/labelathon01/) - labeling issues in a
social setting - was born and is happening for the first time on
**Thursday 29 April 2021 at 16:00 UTC** ([sign
up](https://form.jotform.com/210906095013043)).

At this Social, participants will get together on Zoom, have some time
to meet and greet, and will then spend time co-working (working at the
same time on different projects) to make their repositories more
contributor-friendly.

The idea is to make this relatively low-priority task a bit more fun,
and to offer a chance to socialize with others in the rOpenSci
community.

## Questions ([video](https://vimeo.com/540502735#t=43m58s) \| [document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.xiqdo4ak8lpd)) {#questions-videohttpsvimeocom540502735t43m58s--documenthttpsdocsgooglecomdocumentd1upyoemopwr11jtmxyoypxka5xvwgv-e4axcy6pd-ri8editheadinghxiqdo4ak8lpd}

- (Athanasia Mo Mowinckel) How do you label issues you want help with
  that are really hard? ([video](https://vimeo.com/540502735#t=44m04s)
  \|
  [document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.xhnf3ret6q33))

- (Lluís Revilla Sancho) Are there examples/stories of "help wanted"
  labels on issues that were taken by users/external contributors?
  ([video](https://vimeo.com/540502735#t=46m16s) \|
  [document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.ox46tfo5o962))

- (Kathryn Doering) Any tips for working with contributors that aren't
  that comfortable with git/github?
  ([video](https://vimeo.com/540502735#t=50m55s) \|
  [document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.rjo09tjc0lqd))

- (Silvia Canelón) Some packages ask contributors to sign a Contributor
  License Agreement (CLA) -- when is this recommended/necessary?
  ([video](https://vimeo.com/540502735#t=54m30s)\|[document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.vkb15ssc0lt5))

- (Rob Crystal-Ornelas) Many of the suggested files have standardized
  names, is this convention or does it enable features on GitHub?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.mnvh7htd8kyb))

- (Athanasia Mo Mowinckel) Are there any best-practices in terms of
  formatting NEWS.md files?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.q1fyb2oyrdyx))

- (Silvia Canelón) What kind of positive response did Hugo notice after
  sharing NEWS.md on social media?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.9jq9163k9b3y))

- (Jeremy Selva) The easystats R package has this cool feature to
  classify issues. Any idea how to do this?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.m1oodsbypd52))

- (Sina Rüeger) Maëlle, you mentioned badges for README, can you
  elaborate on that?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.bblr3pfkgm3e))

- (Ella Kaye) In terms of encouraging users to contribute, do you have
  any advice on how to leverage twitter to get attention for it?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.vcfsgl3qtegg))

- (Sina Rüeger) Now that there will be labelathons in co-working mode,
  could there be a time where some issues are tackled in co-working
  fashion, similar to a tidydev day?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.sk8hgb5bc8k))

- (Wayne Smith) Is there a convention for where to put ORCID--readme.md?
  Citation? or?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.5vo9zs9qs1tq))

- (Valentina Costa) For a released package that is still a work in
  progress do you suggest immediately adding contributors to your
  contributor list?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.1sv86z22y6g))

- (Janani Ravi) Is there a good way to indicate in contributing
  guidelines that contributions may result in
  co-authorship/acknowledgements in the subsequent publication?
  ([document](https://docs.google.com/document/d/1UpYoeMoPWR11JTmxYoypXkA5xvWgV-e4aXCy6pd-Ri8/edit#heading=h.qcsorq1lbu7j))


Last Thursday we held a Community Call discussing how to set up a Package to Foster a Community. This call included speakers Maëlle Salmon, Hugo Gruson and Steffi LaZerte, and was moderated by Stefanie Butland. Summarizing the community call   Scientific software development - and with that R packages - is a community effort.

Messaggi di Rogue Scholar

rOpenSci Introduces Monthly Social Coworking and Office Hours

Set Up Your Package to Foster a Community - Community Call Summary