Lab Change Policy(draft)
Summary
From time to time it will be necessary for a hosting organization to make changes to the lab configuration. It is understood that changes may adversely impact developers utilizing lab resources. In order to minimize such impact it is useful to have a policy that lab support staff will adhere to when making changes to hosted environments. This is intended to be a guide and is not intended to serve as any sort of legal agreement. Ultimately the hosting organization is donating resources to the community and reserves the right to make changes at their discretion and in their own interest. The primary objective of this policy is to assure that everyone impacted is notified and understands what is going on and how it will affect them.
Change Notification
The stakeholders of a particular environment should be notified by the hosting organization at least 2 business days (48 hrs) before a change is to occur, including the window during which the change will occur, so that the impact can be accounted for and any concerns expressed. In general, a stakeholder will be anyone with access to the environment, but may also include project managers who may not necessarily have access. Notifications should provide as much detail as possible, specify any service outage, and use clear language so a proper assessment of the change can be made.
Review
All stakeholders should provide comment on a proposed change before the scheduled change is to take place, perhaps using a '+1' along with commentary, or alternately a '-1' along with an explanation. At least two stakeholders must vote on a change. If there is a dissent among the stakeholders, equal '-1' votes will be sufficient to nullify a change. In this event a change is nullified, the change should be modified to meet the majority's requirements or abandoned.
High Priority & Emergency Changes
In the event an emergency change is required, the hosting organization should provide immediate notification to the stakeholders along with details of the change and resources impacted. The change should then be completed following notification and the status should be communicated to the stakeholders. Voting will not apply to emergency replacement or service restoration activities.
Change Failure
The hosting organization should make provision for reversing a change if it does not work as intended. Notification of failure should be made as soon as possible following an unsuccessful change.
Exceptions
In order to avoid excessive restriction of activity due to a proliferation of policy, if a hosting organization is able to communicate a change and obtain sign-off from all stakeholders the notification period may be waived.
Examples
The following are some instances where the policy requires notification.
- Equipment upgrades
- Faulty equipment replacement
- Equipment re-configuration
- Connectivity interruption
