2017 Q1 Open Source Support Briefing

Editor's Notes

• #3: 1. Improving Processes (10 minutes) o Pull requests o CI, linting o New Manual 2. Community (10 minutes) o Open Apereo o uPortal 5 3. OSS Mechanics (5 minutes) o Influencing SE Work o Closing ZenDesk Tickets 4. Sustaining Engineering (10 minutes) o Q1 o Going Forward 5. Community Spotlight (15 minutes) o Oakland ReactJS discussion & demo 6. Q&A
• #5: Give a high level overview of processes
• #6: Describe how this gives contributors a starting point for getting involved
• #7: Describe how this helps guide contributors to a merge-able change request
• #8: Communicate the volume and complexity of the uPortal automated test matrix
• #9: Describe progress made, 2 automated tests to 55 automated tests Describe what needs to get done: Browser testing and additional change request feedback mechanisms Emphasis this will NOT replace manual testing, good design, or clean code practices
• #10: Describe how the community can check on a project’s status
• #17: Submitting Requests Subscribers will sometimes discover bugs they would like to have fixed in the supported software, or have ideas for minor features or other enhancements they would like to see implemented. When these arise, the subscriber contact should submit an “S5 – Request” support case and provide full details on the issue they would like to have addressed. When a subscriber contact submits a development request, the receiving engineer will first review it to ensure it is sufficiently descriptive. If further information is required, the engineer may perform some independent research or engage in further discussion with the submitter in order to fully understand and document the issue. The engineer will then provide an initial estimate for the level-of-effort required to resolve this development request. If the subscriber would like to have this issue addressed immediately, they can use Consulting Assistance time to proceed directly to getting an engineer engaged on the development work quickly. Otherwise, the team will submit the issue to the tracking system of the open source project itself (without identifying the subscriber in any way).
• #18: Just a quick recap. New, Open and Closed are simple to understand. Let’s focus on Solved [next slide]
• #19: Closing a Support Case Once a satisfactory resolution has been achieved, the engineer marks the support case as resolved. Resolution may include identification of a defect in the application or enhancements that are needed in the application to meet expectations. In these cases, the engineer creates a corresponding development issue in the issue tracking system of the open source project and provides the issue number to the support case contact. Afterward, the engineer considers updating community project documentation or other appropriate information sources to incorporate solutions to important issues.
• #20: Instead of throwing UP jira IDs at you, we are going to summarize, topically
• #21: Invalid href destinations: wound send the JavaScript context to be sent to the next page Apache Commons had an exec() vulnerability in the Java serialization parser
• #22: Christian already covered this area. I’ve added it only for completeness.
• #23: We are more documentation focused than ever. We find it critical to enable others to ramp up and get involved. It also shows project maturity.