COMMS Product Suggestion Acceptance Criteria

To maintain product integrity, scalability, and value for all clients, the following criteria must be met for any new feature or change request to be considered for development within COMMS (Course Outline Mapping and Management System):

  1. Cross-Client Applicability
    • The proposed feature or change must provide clear value to the majority of licensed clients (or potential clients).
    • Requests serving the interests of a single client only will generally be deferred or rejected, unless they can be generalized for broader applicability.
  2. Neutral and Inclusive Terminology
    • Terminology and data structures used in the proposed change must be vendor-neutral and education-sector appropriate. When available, language and terminology defined by the Ontario of Ministry of Colleges and Universities will be prioritized.
    • Organization-specific language (e.g. "XYZ College Program Review Form") must be abstracted or made configurable to avoid coupling the product to one institution’s internal vocabulary or processes.
  3. Alignment with Product Scope
    • Requests must fall within the functional scope of COMMS as a course outline creation, mapping, and management tool.
    • Features that fall outside this scope (e.g., financial management, textbook inventory, LMS hosting) will be rejected or redirected to more suitable platforms.
  4. Technical Feasibility and Sustainability
    • Changes must be technically feasible to implement within COMMS’ current architecture without introducing significant technical debt or requiring disproportionate effort relative to benefit.
    • Proposals must not compromise application performance, security, maintainability, or scalability.
  5. Avoidance of Client-Specific Custom Code
    • All features must be implemented in a way that avoids hardcoded client-specific logic.
    • If a request introduces a variation in behavior, it must be supported via configuration, feature toggles, or metadata-driven design.
  6. Regulatory and Policy Alignment
    • Proposed features should align with relevant academic policies, data governance standards, and accessibility requirements (e.g., AODA compliance in Ontario).
    • If the change introduces risks or noncompliance, it must be rejected or modified.
  7. Effort vs. Impact Assessment
    • Each proposal will be assessed using an Effort vs. Impact framework (e.g., low effort + high impact = prioritized; high effort + low impact = likely deferred).
    • Resource allocation and roadmap prioritization must also be considered in final decisions.
  8. Strategic Alignment
    • The proposed change should align with the long-term vision and roadmap of COMMS.
    • Features that align with strategic objectives (e.g., improved data insights, better integrations, increased automation) may be prioritized even if not client-requested.
  9. Operational and Security-Driven Changes
    • Changes originating from the development team that address operational efficiency, technical debt, security, or compliance requirements may be prioritized, even if not client-requested. These are essential to the ongoing reliability and security of the platform.
  10. Client Consensus (Where Applicable)
    • For ambiguous or moderately scoped features, the team may seek input from multiple client stakeholders (e.g., via user group sessions) to validate the need and design direction.
  11. Backward Compatibility
    • Any change must preserve backward compatibility or include an upgrade/migration path that does not disrupt existing client use.