-
Notifications
You must be signed in to change notification settings - Fork 6
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
Software support docs update #35
Conversation
## Continous Support | ||
|
||
An additional 2 weeks per quarter are dedicated for handling small issues. We refer to this as continious support, as it's suppport time between dedicated sprints. This amounts to roughly 6 hours a week to stay on top of GitHub notifications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 week per what? For someone external I would just say, we allocate X hours or X FTE per quarter that stuff happens in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, is this much information (task levels per dev how many hours) really necessary? What is the rationale for giving this much insight? (I ask because external folks may assess the speed with which they get a response with the perception that someone has 6 hours per week without knowing all of the context.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 week per what? For someone external I would just say, we allocate X hours or X FTE per quarter that stuff happens in.
I can probably change this to "roughly 6 hours a week between support sprints."
Also, is this much information (task levels per dev how many hours) really necessary?
Writing down the expectations for continuous support was one of the action items that came out of the last retro. Originally, I was going to make it internal, but couldn't see the harm of including it here. I usually big on transparency, but if there is reason it might be a problem in this context I'm open to moving it internal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated this, and moved most of the original text into the internal docs.
I kinda just want this merged so I just removed all the stuff about continuous support and internal stuff. We will point USGS devs to the internal doc independent of this page so those admonitions were also removed. |
Updating the software support docs to add more context and a mention of continuous support.
Licensing
This project is mostly composed of free and unencumbered software released into the public domain, and we are unlikely to accept contributions that are not also released into the public domain. Somewhere near the top of each file should have these words: