Skip to content

Latest commit

 

History

History
73 lines (53 loc) · 4.75 KB

Change_Management_Policy.md

File metadata and controls

73 lines (53 loc) · 4.75 KB
Raw

CHANGE MANAGEMENT POLICY

Classification Level

Publicly available

Review Information

Mandatory Review Period

Yearly

Date of Last Review

Februrary 23, 2024

Introduction

A change management policy helps employees and external parties understand the processes by which we change our software and systems. Specifically, it helps us and them reason about when, how, and why things might change that may have an impact on functionality.

Goal Statement

At present, we are a small company (literally everyone in the company knows everyone else on a first name basis). Any change is easily vetted with all internal stakeholders and subject matter experts. However, it is easy, especially within a group that is very comfortable with one another, to grow complacent in our rigor around validating the impact of a change. To that end, there is some benefit in formalizing aspects of change management or, at minimum, capturing what commonly occurs. When contemplating or initiating change we should always apply due diligence in the consideration of client needs while balancing our needs as well.

Background Statement

We, at Fonticons Inc., know our culture but it is entirely reasonable for others planning to use our technology to desire to understand how and why are software and services might change. This is especially true as some of our changes may not be backward compatible or may have unforeseen impacts (since our software is open source and thus can and is often leveraged in ways that we do not expect).

Definitions

Terms

  • The word "we" shall mean Fonticons Inc., all Fonticons employees, and any individuals contracting with Fonticons to complete work.
  • The word Fonticons will be synonymous with Fonticons, Inc. for the purposes of this policy.
  • Employee shall mean an individual directly employed by Fonticons and all contractors, consultants, temporary employees, or business partners.
  • User shall mean any individual who is not an employee.
  • Fonticons products/services refers to any and all paid or free products and/or services offered by Fonticons.
    • Product shall mean, specifically, the icons, their digital representation, and associated icon functionality present in code.
    • Service shall mean, specifically, the technologies that make the Fonticons product available to clients, users, and site users.
  • Client shall mean a person or entity who installs or configures part or all of Fonticons product/service for use on a website or product not owned or otherwise controlled by Fonticons.
  • Fonticons system shall mean any computers, communication systems, platforms, and any other information technology systems used by Fonticons to provide the Fonticons products/services.

Policy

  1. This policy applies to changes that directly impact clients. Like-for-like functional changes such as those associated with operations or security follow a different policy.
  2. All employees may suggest, request, or initiate a change to the Font Awesome product or service.
  3. Any user with access to GitHub may suggest or request a change to the Font Awesome product or service.
  4. All changes must either be classified as technical or design changes.
    1. Technical changes are changes to the Font Awesome service or the aspects of the Font Awesome product that are not direct visual representations of icons and their metadata.
    2. Design changes are changes to direct visual representations of icons and their metadata.
  5. Technical changes must be approved by the head of development.
  6. Design changes must be approved by the head of design.
  7. The head of development and head of design should take special care to consider the impact on clients and users within the bounds of expected usage.
    1. To facilitate this policy Fonticons must maintain an up-to-date expected usage statement.
  8. The head of development and head of design should consult with the CTO or other department heads (e.g., head of security or head of operations) if the proposed change is significant or otherwise has special significance in another department.
  9. All changes must ultimately be tracked in our project management software unless they are an emergency fix. In those instances, the fact that the fix was an emergency must be recorded in code management.
  10. We will attempt to release standard changes every 6-8 weeks.
  11. The head of development and CTO may choose to release an emergency or maintenance fix at any cadence they deem necessary for the stability of the product or service.

Procedures

  1. An employee that detects any violation of this policy must report the issue to their supervisor, the head of development, the head of design, the head of security, or the CTO.
  2. Intentionally or maliciously violating this policy is a serious offense and grounds for termination of employment.