---
# System prepended metadata

title: OSCAL Sprint Planning Meeting 20221212

---

# OSCAL Sprint Planning Meeting 20221212

- How do manage and plan our engineering activities? Specifically, we need to think about:
    - Robust strategy for maintaining OSCAL models
    - Target dates for key milestones
    - Tech transition plan
- What isn't working or needs improvements?
    - Managing scope of different tracks and priorities (not comprehensive)
        - Different tracks and dependencies need enumeration, not clear or well-defined to everyone (TBD today or soon)
            - OSCAL models
                - Documentation generation for OSCAL
                - OSCAL public website(s)
                - OSCAL specifications: profile resolution, etc.
            - OSCAL toolchains for example production and rendering
            - Metaschema superset
                - Core Metaschema model
                - Library implementations (XSLT, Java, JS/TS, etc.)
                    - Schema generators
                    - Documentation generators
                    - Content generators
                    - Parsers and object mapper libraries
            - Supporting developer tooling
                - hugo-uswds and website theme/template tools
        - How do we manage scope of miscellaneous or peripheral OSCAL-related work
            - Security and CI/CD templates across OSCAL projects
            - usnistgov/blossom-case-study
            - variety of XSLT-based demo applications, XSLT utility libs
            - oscal-deep-diff
        - How do we manage in-house dependencies (original/derivative XML/data format libraries, CommonMark-conformant libs, etc.)
        - How do we manage datasets of OSCAL content that are semi-official (NIST SP 800-53, 800-53A, others TBD)
    - Developers are heavily siloed.
        - Visibility of work by individuals is limited
        - Reasons:
            - Scope of work is broad (see above)
                - hard to reason on
                - hard to debug
            - Fragmentation of expertise / too many technologies
            - Existing code is not approachable by new developers
                - Missing / incomplete documentation 
            - Work is not self-explanatory and even adding tests may be insufficient
    - Progress is slow
        - Reasons:
            - Limited tests
            - Limited documentation
            - **Few explantions of how/why things were designed in a specific way**
            - Poor prioritization or not following priorities
                - Sometimes the high prority issues are nebulous, lower priority issues are more specific; gravity towards specificity
                - Smaller, low priority tasks are often used to unwind or take a break
    - Some aspects of the project are overly complex
        - We wanted to be extremely flexible and enable the community, they may not hear that message or understand why it has been strongly implied.
        - Don't define well where complexity is necessary
        - Much development has been organic, complexity has accreted
    - Engaging in OSCAL modeling is difficult to get started on
        - Need some kind of quickstart
        - People can understand the domain and application, but not the modeling -> quickstarts, examples are necessary to engage newcomers
    - Our target audience for engineering is front-line developers
        - Use of GitHub here is consistent with other open source projects
        - Other stakeholders need engagement through different channels
    - Issues are clearly documented in what goals and acceptance criteria are needed to complete
        - Team members leave goal and AC fields in template as-is, do not customize them, and often do not check off relevant/all items when complete (so why are we even reviewing them)?
        - Development goes beyond the essential needed to meet goals
        - Developers are responsible for clarifying goals and ACs at work onset and afterwards
        - Identify which issues are not complete and ready to start
    - Not enough design at the front end to clarify development
        - Developers are responsible for clarifying design at work onset and ongoing
    - Primary developer for some issues is not clear
    - We do not asynchronously acknowledge issue changes, comments, or feedback in a team-wide norm
        - Team wide norms
            - "Thumbs up" acknowledgement?
            - "eyes" reaction for reading
            - Monitor mentions?
    - PR review
        - More peer review of PRs are needed
        - Potentially reduces siloing over time
            - Code owners reinforces siloing, but gauratees a review
            - How do we create incentives for more reviewers? How do we measure?
    - Too many topics for a given sprint
        - Community to focus in different aspects and areas of OSCAL
        - Large number of developmental areas (i.e., OSCAL models, tools, CI/CD)
        - No clear team understanding of what the critical path is
        - What is a definition of *done* for OSCAL?
            - Macro: What are we trying to accomplish with OSCAL at a broad scale?
                - What is the portion of the ocean we are trying to boil? What is out of scope?
                - What method do we use to define the scope?
                - How do we keep OSCAL open (e.g., FISMA, ISO 27002), while scoping it?
                - What responsibility does the community have in pushing OSCAL within it's scope?
            - Micro: How do we address small feature requests and refinements requested by the community?
                - Community responsiveness for early adopters is important to keep them engaged
            - How do we prioritize both?
                - Empower the community to help us raise issues and work problems on the small scale?
                - What are the rules of the game for the community to play? How to get solutions vs problems?
                    - How do we get community consensus on the problem, before recommending a solution.
                    - How would the *thing* get done without OSCAL?
                    - What are the incentives, how do we make them clear and equitable, internally and externally?
                - The team need a shared understanding of what the most critical issues are that need to be worked.
                    - How do we raise and work out an action plan to address blocking concerns or significant development risks?
    - Not enough examples to support development
    - What is the pathway to developing schemas, examples? Is there one, many?
        - As a new developer, how do I change a schema or provide an example? How do I demonstrate a use case?
        - Accepting CI/CD runs for a new developer
        - Is CI/CD a complication? Maybe oscal-cli is a solution?
    - How do we balance the perspectives of suppliers vs operators?
        - vendors (suppliers) -> front line developers
        - agencies (operators) -> data and risk owners - How do we get more feedback from this group?

# Parking lot

- How do we engage community adopters who need deeper, directed help with specific examples or establishing initial OSCAL architecture?
