Introduction

• SOS is open to Change Requests from users of its software products..
  • Users can suggest Change Requests at any time using public resources, see Support Resources.
  • Customers can ask for consideration of Change Requests for specific releases.
• SOS accepts Bug Reports from users of its software products.
  • Users can publicly report bugs, see Support Resources.
  • Customers have access to the SOS Ticket System to report problems of the software or its documentation.
• Planning and tracking of Change Requests and Bug Reports is performed by SOS.

Resources

• Change Requests, Bug Reports
  • Public Ticket System for users of the Open Source License
    • SourceForge JobScheduler Ticket System
    • SourceForge YADE Ticket System
  • Private Ticket System for customers of the Commercial License
    • SOS Ticket System
• Change Proposals
  • Public JIRA Change Management System
• Changes
  • Public GitHub Source Code Repositories

Definitions

Changes

• Definition

  • Error rendering macro 'excerpt-include'

    User 'null' does not have permission to view the page.

  • For SOS products we distinguish between the following types of Changes:
    • Changes in the Software (Features, Improvements, Bug-fixes): such Changes are subject to the Change Management Process and require communication with SOS in order to be implemented.
    • Changes in the product configuration: such Changes might not require any support from SOS if the know how is in-house with the user. This type of Changes is not subject to a Change Management Process but is handled within the scope of Configuration Management.
• Resources
  • Changes are documented with the public Change Management System.
  • Changes are visible with the public GitHub Source Code Repositories.

Change Requests / Bug Reports

• Definition
  • Change Request is a formal Request for Change of an SOS product by a user. The requested change can be a new feature or an improvement.
  • Bug Reports are created if the behavior of SOS software products is different from its documentation.
• Resources
  • Change Requests and Bug Reports are added by users using public Support Resources.
  • Change Requests and Bug Reports are added by customers using the private SOS Ticket System.

Change Proposals

• Definition
  • A Change Proposal is a joint document that is accepted by both the user/customer and by SOS and that is added to the public Change Management System.
  • Change Requests
    • Change Proposals are based on requirements, therefore they are the result of a Requirements Management Process.
    • Change Proposals specify the functionality of a Change, for example what functionality a new feature will provide, not how the feature will be implemented.
    • Change Proposals include an estimate of effort by SOS.
  • Bug Reports
    • Change Proposals are targeted at re-establishing the functionality as specified with the documentation.
• Resources
  • Change Proposals are added to the public Change Management System.

Change Management Process

• Change Requests and Bug Reports can be submitted at any time by users and by customers:
  • Users
    • can submit Change Requests and Bug Reports using our public Support Resources and
    • will receive a feedback either by the community or by SOS.
  • Customers
    • can add Change Requests and Bug Reports to the private SOS Ticket System and 
    • will receive a review of their request/report by the SOS Support Team and
    • will receive a release assignment for accepted Change Requests and Bug Reports.
• Change Requests and Bug Reports are subject to a workflow that includes steps for
  • Specification of a Change Proposal: this step is performed with the Change Management System.
  • Acceptance of Change Proposal: this step is performed with the Change Management System.
  • Adoption of Changes: this step is performed with the GitHub Source Code Repositories
• Triage
  • The nature of a Change Proposal being a Change Request or a Bug Report is decided on by SOS when completing the specification of the Change Proposal.
  • For Bug Reports the following policy applies:
    • Bugs are immediately analyzed to identify the scope and risk related to a problem.
    • Bug-fixes are added to the next maintenance release of any software product branches under maintenance.
    • In rare cases a bug-fix can be denied for an LTS maintenance release should the bug-fix require a change that breaks compatibility or that exceeds the scope acceptable for modifying source code of LTS releases.
  • For Change Requests the following policy applies:
    • Change Requests are specified to a Change Proposal that is agreed on between the user/customer and SOS.
    • The following options apply when deciding about implementation of a Change:
      • If the Change Request is related to a vulnerability then SOS will apply the Change with the next available release.
      • If the Change Request is voted for by users/customers and if a substantial number of votes becomes apparent then SOS will assign the Change Request a future release.
      • If the Change Request is paid by a customer then the customer can decide about assignment to a release.
      • If none of the above applies then the Change Request remains in place for future community feedback but is not assigned a release.
• Implementation
  • When a Change is implemented then the Release Policy - Feature Life Cycle Management applies that updates the status of a Change with the Change Management System.
  • Any modifications of the software product due to a Change are visible from the GitHub Source Code Repositories.