The FreeBSD Ports Security Team (headed by the Security Officer) + is specifically tasked with handling security issues discovered in + ported software, maintaining the security of the packaging tools and + infrastructure. Similarly to the Security Team their + responsibilities include keeping the community aware of issues + primarily by maintaining the VuXML database of vulnerabiities and + the quarterly Ports security branches.
+ +Email sent to the Accounts Team is currently forwarded to Cluster Administration.
The Backups Administrators handle all backups on the FreeBSD cluster.
-Email sent to the Backups Team is currently forwarded to Cluster Administration.
The DNS Administrators are responsible for managing DNS and related services.
-E-mail to the DNS Administrators is currently forwarded to Cluster Administration.
+ +The Forum Administrators maintain the &os; Project's web forum site, + located at https://forums.freebsd.org/ + and lead the group of moderators who work to ensure the relevance and quality of + forum content.
+ +The GitHub Automation team oversees the export of &os; source + code repository content to the read-only repository instances on + GitHub
+ +The Jenkins Administrators run continuous build and integration tests + against the HEAD revision of the &os; Source Code.
+ +E-mail to the Mirror Site Coordinators is currently forwarded to + the Cluster Administration team with the + addition of:
+The Phabricator Administrators are responsible for maintaining the &os;'s + instance of the Phabricator on-line code review tool located at + https://reviews.freebsd.org/
+ +The FreeBSD Subversion team is responsible for maintaining the health of - the Subversion Repositories.
- -Email to the Subversion Administration team is currently + forwarded to Cluster Administration.
+Email to the Webmaster Team is currently forwarded to the Documentation Engineering team with the + addition of:
+The current set of core-appointed hats is core secretary, head release engineer, the security officer, and postmaster.
-It is suggested that shortened terms longer than half of a core - term be considered a full term for purposes of eligibility.
+The FreeBSD Core team has approved the following hats term limits + policy. This was first posted to the Developers mailing list on June 22, + 2012, and amended in June 2015.
-This policy will begin with the start of the next core term, and - all hats will start off with zero terms at that time.
+The FreeBSD Core team approved the following hats term limits - policy which was posted to the Developers mailing list on June 22, - 2012.
+An individual may serve as a core-appointed hat so long as:
-Hats are appointed at the pleasure of core. Appointments may be + rescinded by core at any time where this serves the needs of the + project.
+ +Each hat's term begins three months after the start of a core + team's term and ends three months after the end of a core team's + term. Hats are explicitly approved by the new core team at the + start of a hat's term.
-An individual may serve as a core-appointed hat for at most two - consecutive terms. Each hat's term begins three months after the - start of a core team's term and ends three months after the end of - a core team's term. Hats are explicitly approved by the new core - team at the start of a hat's term. An individual who serves as a - hat for two consecutive terms may serve again after a break of at - least one full term.
+If a hat becomes vacant during a term, core shall appoint a + replacement for the remainder of the term.
Core shall review all hats annually.
-If a hat becomes vacant during a term, core shall appoint a - replacement for the remainder of the term. It is at core's - discretion whether the shortened term will count for purposes of - limiting the terms of the replacement.
+It is expected that each hat will serve for no more than two + complete two-year core terms, but this is not a hard limit and + role-holders may continue for longer.
+ +Each hat should appoint a deputy who can cover their role in the + case of absence or illness, and be trained and ready to take over + the role (subject to core approval) should the role holder resign + before the end of their term.
If a core team is dissolved prematurely, then the next term for each hat will begin three months after the new core team's term - begins. It is at the new core's discretion whether the shortened - term will count for purposes of limiting the terms of current - hats.
+ begins.These limits apply to individual hats and not to teams. For teams with a single lead role, the limits shall apply to the lead