I am a student at the University of Michigan and I’m taking a Software Engineering course here. Our last homework is to contribute to an open-source project and my partner and I have decided to try contributing to OpenMC for the next couple of weeks!
We would really appreciate any feedback or information that may be helpful to us during this process. Our initial plan was to take a look at Issue #2123 (Weight window bounds ordering · Issue #2123 · openmc-dev/openmc · GitHub). However, during the process of reading through the Developer’s Guide, we found that two issues were tagged for first time contributors. We would also appreciate your opinion on our contribution to Issue #2123 and whether or not there may be better issues for us to work on.
We were also unable to join the slack for OpenMC because we did not have an email domain that matched. Would it be helpful for us to join the slack or is it okay that we are unable to be on it?
I did take a look at the two issues labeled as “first timers only” and I’m wondering if those issues are slightly out of date now as they were made in 2017 and 2018.
I’m sure we can find you a nice issue to work on. I think @April was making a nice collection of “first timer” issues just today.
Perhaps we can raise a couple of issues for you and tag you on GitHub. Could you let us know your GitHub usernames?
Something that jumps to mind as straight forward and always welcome is additional type hinting on the python arguments. It is not the most interesting PR but helps get an overview of the code. If you are keen you could add some type hinting to any python file that is missing type hinting. Take a look in this folder to find a relevant file.
I have done a few type hinting PRs that helped establish where we want them (on method and function args and return statements, but not on getters and setters). Perhaps these example PRs help Pull requests · openmc-dev/openmc · GitHub
@ywkim1025 Thanks to both you and Christina for your contributions (present and future)! If you want to continue on the type hinting path, in my opinion the ones that would be particaruly valuable are the classes that are most often used, including: openmc.Model, openmc.Geometry, openmc.Materials, openmc.Material, openmc.Cell, openmc.Universe, etc. Happy to sketch out a full list of priority classes/functions if it would be useful.
If you have a list of tasks we could work on, we would be super open to hear about it!
I would ask that you provide us a relatively wide range of difficulties in the tasks (but maybe not so much of the hard) because we are very new to this project. While we don’t know if we will be able to get to those tasks and complete them for sure, we can definitely try it out.
Please feel free to provide us a list. Thank you so much for helping us!
Our homework actually requires us to complete a task where we can complete some sort of QA activities. Whether it’s using Travis CI or using analysis tools, we must do some sort of testing.
I was wondering if there are any other task suggestions that may allow for us to do this that aren’t too difficult for first-time contributors to complete. We are still working on type hinting but we figured it may be good to also work on other tasks!
Another thought since you’ve been working on type hinting – one thing we could add is some static type checking in our CI by using mypy, pyright, or another static type checker. That is, given the type hints that now appear in the code, does our own internal use of functions/classes obey those type hints. If not, that’s a good indication that either the code is wrong or the type hints are wrong.
Sounds great! Would making a new folder in regression tests called typehint and including an init.py and test.py where we run mypy on all of the files that we have added type hinting to work?
Yes, the proper thing to do would be to run it as a GitHub action as you suggest @Shimwell. Note that I just tried this locally (mypy openmc) and got nearly 200 errors It looks like most of them have to do with mypy not being happy when a property getter/setter don’t appear next to each other. So, that might be another item of work — run mypy locally and start working through these errors; I suspect many of them will be easy to fix.
It looks like most of them have to do with mypy not being happy when a property getter/setter don’t appear next to each other. So, that might be another item of work — run mypy locally and start working through these errors; I suspect many of them will be easy to fix.