I think that: - what it calls "needs triage" is currently called "new" - what it calls "in discussion" is currently called "in progress" - what it calls "patch ready" and "needs MFC") no longer exist or aren't used currently (although see the patch-ready for the former) - what it calls "issue resolved" is currently "closed" with resolution "fixed" but I can't swear to it. While there, maybe review the rest of it for currency. Spotted while rooting around for when/why to MFC info.
Thanks for the report. Known issue for a while, hadn't tracked it in Bugzilla, thank you for reporting. Happy to address these issues via an issue management page on the wiki, from which a correct/accurate summary can be added on the website
(In reply to Kubilay Kocak from comment #1) Link me? I'll see what I can do beyond my educated guesses above.
Re staleness, there is a Note: > Since the list of individuals who have volunteered > to be the default assignee for certain types of PRs > changes so often, it is much more suitable for > the FreeBSD wiki. But the linked Wiki page was deleted in July 2025. Contra "changes so often", there were no substantial edits for many years before! https://wiki.freebsd.org/action/info/AssigningPRs?action=info -------------------------------------------------------------------- MIPS support only survives as Tier 2 on 13.x (EOL April 30, 2026) so the "problem specific to the MIPS architecture" example in Table 3 could be removed. -------------------------------------------------------------------- Cultural expectations have also changed since the page was first written: > Joe pulls an all-nighter and whips up a patch that he thinks fixes the problem Perhaps best not to celebrate "macho" programming habits given increased awareness of the health importance of sleep and controversy over industries imposing "crunch culture" on developers. The sentence would work fine as "Joe whips up a patch".
I was just looking at it over the weekend. It absolutely and completely stinks and needs a rewrite. Also true for the Contributing article. I guess I need to build a doc toolchain.
(In reply to Mark Linimon from comment #4) Willing to hash it out with you by email. I also have a docs toolchain installed, so I can spare you the installing effort and learning curve if you'd rather.
A broader issue if the docs are to be rewritten to reduce confusion for new users: it's unfortunate that when FreeBSD issues are discussed on forums or mailing lists, the terms "PR" or even "submit a PR" may refer both to a Bugzilla "Problem Report" or a Git(Hub) "Pull Request". I suspect if the latter was common currency earlier, then "Problem Reports" would have been called "Issue Reports", "Bug Reports", or something else with a less ambiguous abbreviation. This isn't the venue to discuss renaming (perhaps such a proposal is worth floating elsewhere), but the docs should be sensitive to potential confusion when using the term "PR". Note that Problem Reports docs are the top hits for search terms like "create PR FreeBSD" or "submit PR FreeBSD" on multiple search engines, whereas without "FreeBSD" the search results overwhelmingly refer to Git(Hub)! Of course this also affects other pages, including - https://www.freebsd.org/support/bugreports - https://www.freebsd.org/docproj/submitting - https://docs.freebsd.org/en/articles/problem-reports Now the FreeBSD Project supports GitHub Pull Requests, one solution might be to add a Note, after introducing the term "PR" as Problem Report within the article, to inform readers that: - "PR" is also a common abbreviation for a Pull Request on Git, - in this document "PR" will refer only to Problem Reports, - provide a link to an appropriate guide to the Project's support of GitHub PRs in case the reader was misdirected to this page by their search engine. As an appropriate target for the last point, there is a comprehensive article by Warner Losh in the Foundation's May/June 2024 FreeBSD Journal: https://freebsdfoundation.org/our-work/journal/browser-based-edition/configuration-management-2 If it was preferred to direct to the Project's docs, technical details are present in https://docs.freebsd.org/en/articles/committers-guide (However, I can't find Project-maintained documentation covering the etiquette of GitHub PRs, or which contributions are suitable for them, so Warner's article seems more useful to new contributors. I wonder if a version of it could be adopted into the official documentation so could be maintained if workflows change in future, but that's another issue.) The phrase "Problem Report" is intended to be more inclusive than terms like "Bug Report", to encompass feature requests and errors or lacunae in documentation (including on the website) which many users may not realise count as "bugs". Hopefully a comprehensive rewrite will help this document reflect the wider meaning of PR: several sections currently treat it as synonymous with "bug", "bug report", "software defect", etc.
(In reply to B.S. from comment #6) > I suspect if the latter was common currency earlier, then "Problem Reports" > would have been called "Issue Reports", "Bug Reports", or something else with > a less ambiguous abbreviation. "Problem Report" dates from the old GNATS days and is simply ingrained in the Project lore. As you add later, the best we can do for the short-term is to make sure that any existing article that uses "PR" prepends "Bugzilla" to it. > If it was preferred to direct to the Project's docs, technical details are > present in https://docs.freebsd.org/en/articles/committers-guide which stinks just as badly as the Problem Reports article. Possibly worse. (That's actually the one I am tackling first) Right now, I am trying to figure out what to tackle first. Perhaps the first step is to get rid of the recommendation for .shar submissions, and then do the other work.
(In reply to Pau Amma from comment #5) Thanks. We can do either email, or Problem Reports, or Discord if you use it. I have spare machines so installing the tools is not that bad, but, it's just one more task that I don't need to prioritize right now :-)
(In reply to Mark Linimon from comment #8) Let's stick to Bugzilla, since we started on it and to keep B.S. in the loop. Just cc me and them on any other PRs you open for this project.
OK, as a first step, I have disambiguated "PR" in the Contributing article. (It is afflicted with the same issues, and is probably where most users would look first.) Please see https://reviews.freebsd.org/D53638 .
Adding two new Phabricator patches for review. This Article (and its siblings) still needs a lot more work.
I don't have a Phabricator account but just wanted to point out the summary (don't know if these can be edited) at https://reviews.freebsd.org/D53638 > As a first step to bringing it up to date, disambiguate > the "PR" term, and spell it out as "Bugzilla Problem Request". Obviously "Problem Request" here was intended as "Problem Report"! Many thanks for following up on my suggestion to disambiguate with GitHub PRs.