-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document process for servicing a package addition request #2936
Comments
For python packages, Step 1: Figure out how complex it will be(Assuming #2934 is done)
Make a quick determination of wether the package is expected to be a simple addition or not, and leave a comment acknowledging this. Communication with the requestor is important here, and something we should have an SLA for. Ideally, this would also mention how long we expect to take to service this. Step 2: Make a PR just adding the packageAdd the package to the appropriate |
For R packages, Step 1: Figure out how complex it will be(Assuming #2934 is done)
Make a quick determination of wether the package is expected to be a simple addition or not, and leave a comment acknowledging this. Communication with the requestor is important here, and something we should have an SLA for. Ideally, this would also mention how long we expect to take to service this. Step 2: Make a PR just adding the packageAdd the package to the appropriate file in the appropriate hub image. This needs to be properly structured - currently, the file names are a bit scattered across various images. |
I think another important thing to figure out is just timelines - sometimes the packages are needed in two days, sometimes in two weeks. We should prioritize and respond accordingly as well. |
Some amount of normalizing the structure of our image directories will also help a lot here I think. I want it to be super clear where exactly a new package will need to be added. |
@yuvipanda Thanks for breaking down the package addition complexities. This gives me a useful framework to think about some of the package requests that we get and the kind of communication that needs to be shared. Any package addition request gets assigned to @felder and me currently. As a process, if @felder is available then I would let him respond from a package addition and SLA standpoint as he is thorough in his communication with the teaching team, Felder will escalate issues to Yuvi as and when required! If @felder is unavailable (taking a day off), I will respond to the package request, and if it looks like a simple request (as outlined by @yuvipanda) that is also time-sensitive I will create the required PR. If not I will acknowledge the package request and highlight the SLA we had defined for package requests earlier. Sharing that below for your reference, SLA for package installation: “Acknowledgement within two working days.” SLA for RAM increase: “Acknowledgement within two working days.” SLA for admin access: “Request completed within two working days.” SLA for data archival request: “Request completed within three working days.” https://ds-modules.github.io/curriculum-guide/faq/onboarding.html?highlight=sla @felder @yuvipanda Let me know if that works for you all. Just to confirm, for Python, we are looking at making edits to environment.yml file and for R, we are looking at making edits to install. R? Is that right? |
We should more thoroughly document the process for how admins can service a package addition request. This will show us places where we can streamline our operations to make sure they can be done as quickly as possible.
The text was updated successfully, but these errors were encountered: