dch, glebius, hrs, rene were present at the conference.

dch had a talk with title "Core Team: Personal Perspective"

Core received a question if it is OK to remove links to X/Twitter from the project website.

As the handle is not being used, core thinks this is fine.

The Project still needs to control the handle to avoid abuse by others.

The link can be re-added if someone in the project or Foundation can use those SNS accounts well.

An idea is to compare traffic flows between freebsd.org and freebsdfoundation.org

Collaborated with doceng and deployed.

Brought up by inquirers from the developers.

Core identified there are some existing documentations but should ask doceng/portmgr/srcmgr for more input.

From the feedback of the community, the preferred way is staggered core terms.

One idea is to rate half of core every year instead of rotating possibly. all of core every two years, so that in-progress work and experience do not get lost.

Some developers have strong ideas about this (like rotating a third of core each year instead of all of core every two years) and would like to be involved.

We need to have the bylaws changed for this, the standard is high.

There are suggestions from the community for we just change the bylaws as core does not legally represent anybody. Is that really a good idea?

This discussed at core session at BSDCan developer summit 2025.

Core is continuously working on this toward to setup staggered core terms.

Brought up by an inquiry from a developer

We need (updated) documentation on how to rebuild the critical systems to ensure business continuity of the FreeBSD Project. This encompasses three aspects:

Our own project business continuity (loss of key personnel or infrastructure)

Replication for end consumers of FreeBSD

How does our release engineering work, and which of the various teams are impacted.

Currently too much knowledge depends on tribal memory, need to collect, sort and documented.

An artifact of the STA work is that release documentation is written (next to the releng article in doc repository). Some corner cases are currently missing.

A question came from a developer about whether pseudonyms can be used as committer names.

There is a higher concern about how to deal with any copyright issues.

Core however does not feel that using pseudonyms is endorsed as it makes paperwork and restoring cluster access more difficult, and suggests mentioning the advantages of using real names.

Another way pseudonyms could cause problems is when the identity is shared, e.g. in case of a vendor commit bit, who will be the spokesperson?

The Core Team is in the process of drafting a policy on using AI and LLMs.

For this effort, it also plans to consult with other groups, such as the Foundation’s legal counsel and people in the Linux and other open source communities who are working on related topics.

There are various questions about copyright, guaranteeing code provenance, best practices and "common sense" by both developers and external contributors, and what can and cannot be done with AI (assisted) tools.

There have been many follow-up discussions after BSDCan and EuroBSDCon, and core is organizing and summarizing them.