Open discussions on specific topics selected by the Software Working Group and selected from the list of SWG Topics For Discussion.

Wednesday February 24, 2021 - Radiant - What You Need to Know - The goal for this resource is for you to worry about your project and not the hardware where your project is running.  During this roundtable we will show how to get on Radiant, how we can create Virtual machines, as well as how we create Kubernetes clusters.

Video: https://uofi.box.com/s/ehtibzr1v4y7yxjxckavu6cm872q5gom

Attendees


Code reviews are as essential to code writers as editors are to authors.  Give your work a good view before requesting a PR.  We will discuss an article of how to get reviewers to fall in love with you.  https://mtlynch.io/code-review-love/

Check style guides and use automated checks.  Fresh eyes will give you a different perspective.  Sleep on it before asking for a review. Remember, reviewers are to help you and your code. We should try to find a balance between the number of people who code review.  How to become a good code reviewer?  There is no test; you need to practice and learn from your peers.  We often rely on the same reviewers and then one person is the "go-to" reviewer, which puts a strain on that person.

Problems reveal themselves at the code review - could we have too many reviewers? Not just on the code, but on the branch itself.

We should keep architectural record of changes made. https://en.wikipedia.org/wiki/Architectural_decision
Clowder is trying to implement something like this, where they create a wiki page where you describe why you want to make a change, followed by a design change and how it will affect other parts of the instance.

Change requests are used in LSST. Usually the person asking for the change should implement it as well.  Documentation and comments are integral into why the change request was made.

What if we are starting from scratch? Can we commit just pieces? How many people are working on the code?  What if I am the only one working on the code?

The story of a dif is often difficult to follow.  Studying pieces makes it difficult; we need to see the BIG picture - we need a way to track why changes are made.

What doesn't work is just as important as what does work!

Separate tickets should be created for each issue so that it can be checked off as done rather than putting several issues in one ticket.

Be sure to follow up on code reviews when you ask for PR's.  Communication is critical between the reviewer and the coder.  If it will take some time to review, let the coder know that you've seen the PR but need some time.

Remember that although reviews slow down the deployment, they are extremely necessary to make sure the code is done correctly.

Go forth and review!




  • No labels