Add "How we work" blog post on full package review #335
Conversation
✅ Deploy Preview for tourmaline-marshmallow-241b40 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
✅ Merge Schedule |
|
|
||
| Our regular code reviews take place on GitHub, using Pull Requests. For full package reviews, we also use Pull Requests in Epiverse-TRACE. This means that all the features from GitHub are available to make suggestions, approve the code, or leave precise comments at a specific line in the code. | ||
|
|
||
| What is different, is that all the files are considered new, and part of the review. This includes the files already present in our [package template](https://github.com/epiverse-trace/packagetemplate), but also all test files, documentation, and more. A full package review is usually triggered by an upcoming release, either on GitHub or CRAN. |
There was a problem hiding this comment.
Not a comment on the content but a reflection for the future: we could exclude the very first commit, which should correspond to packagetemplate infrastructure, if we wanted in the future.
|
|
||
| [Since joining Epiverse-TRACE](../chjh-intro-blog/index.qmd), I participated in many full package reviews, but did not until quite recently initiate my own. For the new package **safeframe**, [I recently requested a full package review](https://github.com/epiverse-trace/safeframe/pull/40). This highlighted two quirks I did not realize before. | ||
|
|
||
| First, it feels like doing something that can easily go wrong. I have been using Git for over a decade[^1], but this was completely new to me. Given that git operations can sometimes cause issues, I was hesitant to just run the shell commands. Maybe having a demo video showing it works, will help contributors gain confidence in doing this. |
There was a problem hiding this comment.
This is where we should have a blog post on our backup infrastructure that we could link to 😁
|
|
||
| [^1]: My GitHub account is from 2011, but at that time I did not understand what GitHub was or did. | ||
|
|
||
| Second, reviewer suggestions are great, but getting them on a full package review involves manual work to include them. I try to leave actionable suggestions directly in the code when I review, so they are easy to accept and integrate into the codebase. With full package reviews, receiving suggestions became slightly annoying. Not because of the reviewer, but because the suggestions have to be manually recreated in a separate branch that will actually be merged. It would be great if we had a way to keep the ease of integrating reviewer suggestions in full package reviews. |
There was a problem hiding this comment.
From the text, I don't know for sure if you are aware that code suggestions can be applied in full package reviews.
The trick is to apply suggestions as you'd normally do in a standard PR. They result in commits in the review branch and at the end of the review you can change the PR target from empty to main and directly merge the changes from the review.
It's another case of "the whole full review process is a hack on top of git and it confuses even advanced git users" but it's quite convenient.
This is a blog post on "How we work" in Epiverse-TRACE. I figured I'd write one about requesting my first full package review, also as a way to highlight this practice within the ecosystem. It is nothing fancy, but it is always good to highlight the ongoing practices, I figured.
I propose scheduling this blog for December 9th, if agreeable in terms of content.
/schedule 2024-12-09T08:00:00