Dear coreboot community,
Please be reminded that our leadership meeting is scheduled for Wednesday, September 18, 2024.[1] Kindly review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you.
## Current Agenda
### [Martin] How do we want to handle code written with copilot or other AI tools. * We don’t currently have a policy, and it seems like we should. * [jpmurphy] What are the coreboot projects goals? * [jpmurphy] How do we want to manage a roadmap? * Can we start a draft of a roadmap to at least start gathering a list of features/tech debt and their priorities? * [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? * [jpmurphy] How do we utilize the OSFF to obtain NDA’s with SoC vendors and provide early silicon support? * [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * <code>Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach.</code> * <code>2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it's a Google bug. Felix S had suggested ChromeOS-Bug-Id</code> * <code>[jpmurphy] We get coverity results for free from synopsis. At the time of writing, there are 705 outstanding defects. Do we have a plan for burning these down?</code> * <code>(https://scan.coverity.com/projects/coreboot)?</code> * <code>Can we set a bar to burn these down by a certain date, and then moving forward we require that the defect count is 0 prior to releases?</code>
### [Werner] The coreboot project has a few different communication channels around (mailing list, Slack, Matrix, IRC, Google docs) All our discussions happen spreaded among those and there is no central place (accepted by all community members) where decisions are written down. * Mailing list seems suitable as it has an archive but some people opted out due to heated discussions and other issue we had in the past * Google docs could be one place but unfortunately not every community member likes them. In addition, despite the meeting minutes, there is no “official” document where centric decisions are written down, one has to search in the archive to find things * Slack/Matrix are not used by everyone * IRC is not suitable for such things as well In addition, I agree with jmurphy’s points above, we do not have a plan for a roadmap. Would a kanban-style board be something we like to have a look into for such things? I know, ranting about too many communication channels and then adding another one isn’t the best move. But still, let us at least discuss. Possible open source boards we can have a look at:(https://kanboard.org/) and (https://wekan.github.io/) It might be easier to maintain a feature roadmap this way, IMHO. And we can host it on coreboot.org to have full control over it.
## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit