* What do on the team we need to know about our dev work?
- D: I really need best practices on executing on well-defined work.
- A: Seems to me what is not clear about changes is: Why? Who will benefit? Who will it hurt?
- D: I usually know these answers from the issue and acceptance criteria, I do not understand the immediate impacts of our changes and it is really procedural implications.
- W: "hard place that's a good place" and these are hard questions, but these are growing pains in the maturity of the project. D's feedback is also an important issue.
- W: We have to break out the kinds of work and what layer of the project it touches (Metaschema, document, research effort)
* What do we want the community to know about our dev work?
- D: We don't really "count" on issue comments, votes, etc.
- A: how would they understand what to comment on and/or vote on?
- D: 3-5% is really the maximal extent to what we can expect for participation in any community, so 3-4% is optimistic.
- W: That is how we end up were more stable traditional organizations and processes like advisory boards.
- D: People don't know what they want until they try what they're given.
- W: we should be using the GitHub issues to do this
* If different does the difference matter?
- A: so sounds like it does matter. Our devs care about details and best process/procedures to implement it. Our community wants the outcome.
- C: Let's talk about the cliche of the "50,000 foot view."
- Ground level: work as individuals versus
- Flying level: for the team overview and/or general public
- "People don't want to look at GitHub issues"
* Do we measure work by models or capability?
- A: "Our community doesn't care about the models", look at the analytics.
- D: "We need to learn about assessor's and practitioner's point of view who would use the tools of our first tear of the actual OSCAL-based tools developers."
- W: we were asked to solve an interchange problem.
* Do the community measure work by models or capability?
- A: we talk about the models and our comms are model-centric, not clear our community wants to be.
- C: acknowledge where we are in the progression: OSCAL initially moved people off paper, but it is *not* the future
- C: SSPs were not even the worst thing I had to deal with when I dealt with things related data conducive to different OSCAL models
- I relate things back to FHIR a lot, but only one person in one instance went back to look at how the model had an issue/problem incongruent with their software.
- A: it is not
* How do measure work across models or capabilities?
- C: keep things at the depth of detail based on the teams building a system and how
- C: FHIR had resources with a maturity level with every resource (model) and it started at 0.

Possible action item (D&W): monthly communication by Michaela and/or others on updates to high-level development goals