# Meetings to discuss issue [#1496](https://github.com/usnistgov/OSCAL/issues/1496)

---
## Meeting #1
### Date: 02/07/2023

## Agenda

1. Discuss and identify best practice for balancing recording of team member’s thoughts related to issues (for transparency with the community) and minimization of lengthy contradictory discussions.

2. Discuss - Draft decision record for the issue #1496 – see below (40 min)

3. Conclusions and next steps summary

- How do we achieve a balance between providing feedback, being curious, allowing others to express their point of view and avoiding ‘destructive discussions’. (10 min)

### Details
1. How can we fix it?

>> We can talk next week during the meeting.
 We can talk about it next week when the meeting is set up, I would rather constructively discuss it than write destructively on the topic.
 
>> Would it be possible not to stress this question until we have actually moved a few Issues onto and then off from the board? .
>> By showing what works we can then see what is no longer working / getting in the way. Apologies if this comes across as a wet blanket on a worthy initiative. I think I'm in favor of the goal just not sure how to get there most easily.
 I think this a wonderful theme we need to focus on as a group. I did not put this comment or the prior one to insist we hash it out in the comments, just adding important points about my perspective and things I will likely discuss as I review my comments and notes on the issue at that time.

2. Drafted Decission Record

1.	Declutter the pool of labels currently used.	
- important labels to keep or have:
    - priority labels,
    - effort level,
    - bug,
    - question,
    - developer experience required (DER): (e.g DER:METASCHEMA | XML | JSON |
    - discussion needed - internal (DNI)
    - discussion needed - external (DNE)
    - label for upstream blockers (e.g. Blocked)
    - label for discovery/research (e.g. Discovery)
    - label indicating RFC
    Proposal: Create a hierarchy of labels
    
2.	Document how to consistently use the labels kept or created across multiple repos.
    - standardize a set of labels across all repos and then incementally udapt to the repo's needs/topic.
    - when we create issues, the team members is responsible for using the proper label, hence the document is important. 
    - specialized templates can be used for standardized labels

3.	Use a project board for each major topics. A list I can think of today:
    - Rules,
    - Checks,
    - Controls mapping model,
    - CRM mapping model,
    - Inherited controls and Leveraged authorizations,
    - Requests for collaboration
    - Bugs breaking backwards compatibility
    
    Chris: There are concerns there will be dificult maintaining topic-specific boards (too many topics)
    AJ: Community needs a place where they read about the topic and the status without interacting with us.
    Chris: Concept of EPIC issues is what we are missing. 
    
4.	For each major topic, EPIC issues can be used to group related issues. More than one EPIC is possible for each major topic.
    - EPICs requires maintanence too. 

5.	The (decluttered) labels can be used for issues associated with the EPICs.
Note A diagram can be added, if needed. Some definitions must be also included.

MISSING: a way to "tell the story" about topics of work.

PROPOSAL:
A TOC.md with hyperlinks of all EPICs and related issues and the status pulled from the issue? Files can be maintained in the OSCAL GitHub repo and generate a OSCAL status dashboard page on OSCAL pages that will list all Project boards, and automatically populate the summary with the TOC.md. A user can navigate to learn more and offer to collaborate with a click of a button that would mailto:oscal@nistgov (invoke the mail client app) and include the selected topic in the subject line.
CONCERN: This takes extra work to manually generate and constantly maintain the TOC.md up to date if no auto generation is possible. Can the process be automated? 

NOTES:
AJ: The main thing we want is a way of documenting what are we working on and what is the status. AJ can try to show through an example of breaking 'rules' into parts and show the relation to 'checks'.
Wendell: He agrees with AJ, EPIC tracking can help.
AJ: Need to comunicate better what are we working on and where the work is. 

3. Conclusions of the meeting:
1. Draft an ADR for labels (labels to delete, labels to create) - https://hackmd.io/UrSjUKGiQRuiA2VJLG-Mpg
2. Draft an ADR how to handle EPICs and the related issues - https://hackmd.io/eUhzIQx3RW6zYcGZ_iIJUQ
3. Implement a workstream of tracking EPICs (AJ volunteered to spike this)
4. Research output will create 'business requirements' for the engineering helping with breaking down the implementation into EPICs (related) and smaller tasks. But until pillar 3 operates as expected, we need immediate solutions provided by 1) and 2)
5. Defer the OSCAL pages until we decide and implement what we discuss for our internal process.
.

## Meeting #2
### Date 02/13/2023

1. Discuss - Draft ADRs (architectural decision records) for the issue #1496
- Draft ADR for labels (labels to delete, labels to create) - https://hackmd.io/UrSjUKGiQRuiA2VJLG-Mpg
- Draft ADR how to handle EPICs and the related issues - https://hackmd.io/eUhzIQx3RW6zYcGZ_iIJUQ

2. Conclusions and next steps summary

### Details

#### Draft ADR for labels (labels to delete, labels to create) - https://hackmd.io/UrSjUKGiQRuiA2VJLG-Mpg
- Great work was done. I suggest using the rest of the meeting today to review the draft ADR (the labels)
- All labels were re viewed and marked accordingly for deletion, retention and/or lower case.
#### Draft ADR how to handle EPICs and the related issues - https://hackmd.io/eUhzIQx3RW6zYcGZ_iIJUQ
- No work was done for this issue