Hello world 👋

I'm Hugo Gruson [ygo gʁyzɔ̃]. I'm primarily an Evolutionary Biologist but I fell in love with R and package development during my PhD. I am now a Research Software Engineer in Epidemiology and I can enjoy building tools to facilitate research of others.

I'm particularly proud about the following R packages I'm maintaining or I've helped build:

• pavo*: Perceptual Analysis, Visualization and Organization of Spectral Colour Data
• lightr*: Read Spectrometric Data and Metadata
• rromeo*: Access Publisher Copyright & Self-Archiving Policies via the 'SHERPA/RoMEO' API
• mcmcensemble*: Ensemble Sampler for Affine-Invariant MCMC
• contactdata: Social Contact Matrices for 152 Countries
• asymptor: Estimate Asymptomatic Cases via Capture/Recapture Methods
• fundiversity*: Easy Computation of Alpha Functional Diversity Indices
• cransays*: Creates an Overview of CRAN Incoming Submissions

(* collaborative projects. Please check the full list of authors!)

I'm always super happy to receive feedback about my packages so feel free to get in touch to talk about any problems you encounter, possible improvements, feature requests and just tell me about how you used my packages! I want my projects to be really community projects and not just open-source projects.

But I didn't get started with open-source development with R packages. My initial involvement in a community project was with HTTPS Everywhere, a browser extension to force HTTPS connection to websites via a manually curated list of rewrite rules. I started as a happy user who wanted to increase the HTTPS coverage provided by the extension. I enjoyed the experience of collaborating to build something great together and continued contributing, until I eventually became one of the main contributors and then a ruleset maintainer.

You can interact with me here on GitHub or on Twitter (@grusonh)!

If I submitted a PR in one of your repository

Below are some things to know if I submitted a PR in a repository:

• my PRs are just suggestions. Feel free to request any amount of tweaks before merging or even to close them if you don't like my changes or if you can think of a better way to fix them.
• in general, I prefer to be asked to tweak my changes myself rather than you directly editing on my branch. I think this provides better learning opportunities. However, if I left you the technical possibility to do it, it means you can go ahead if you think that's a better option
• I usually try to re-organise my commits in a logical way before submitting a PR. Because of this, I strongly recommend you review my changes commit by commit. This will be much easier than reviewing all changes at once.