Page MenuHomeFreeBSD

status/2026Q3/doceng: Add doc project report
Needs ReviewPublic

Authored by ziaee on Wed, Sep 30, 6:45 PM.
Tags
None
Referenced Files
F174184439: D60182.id188236.diff
Thu, Oct 1, 5:22 AM
F174183436: D60182.diff
Thu, Oct 1, 5:11 AM
F174164818: D60182.id188236.diff
Thu, Oct 1, 1:50 AM
F174164107: D60182.diff
Thu, Oct 1, 1:42 AM
F174154163: D60182.id188236.diff
Wed, Sep 30, 11:43 PM
F174154118: D60182.id188236.diff
Wed, Sep 30, 11:42 PM
F174150047: D60182.diff
Wed, Sep 30, 11:00 PM
Subscribers
None

Details

Summary

I have never done a doceng report before. To be honest, I do not feel
that the template we used historically is meaningful today*. The needle
on translations** does not move. Actually people send in translations on
github and nobody reviews them, and then the submitter garbage collects
their branch. What is meaningful I think are the many projects in the
tree that we should showcase. So, here is a first draft at that, it
probably needs some help.

Please tell me about your projects or offer corrections!

*: Actually I think we should nuke freebsd.org/docpro*. Nobody is
maintianing it, all of the information is available elsewhere, and
docs.freebsd.org is understood to be the projects homepage now. The only
attention it gets is pruning stale links for several years now.

**: Except the Russian translations get a lot of love.

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 77535
Build 74418: arc lint + arc unit

Event Timeline

ziaee requested review of this revision.Wed, Sep 30, 6:45 PM

This is probably not the right forum to discuss this but I cannot help but comment:

The needle on translations** does not move.

I have been contemplating this issue for good decade, outside of FreeBSD as wll, and see several possible reasons for that. Some of them are that with the modern tools (a) having a translation is not that necessary anymore and is not a significant issue as it used to be (b) it could be done consumer side automatically with adequate quality and negligible cost. One can argue that the end user <> documentation way of interaction has already changed to the point where the end user rarely actually reads anything on docs.freebsd.org themself. In short, maybe the needle doesn't move simply because there is no need for it to.

I deliberately leave out the elephant in the room question of whether we as the project want to adopt modern practices of working with documentation or keep the traditional way (i.e., pretend nothing happening).

The report looks good.