FYI, even now, I hesitate to change links in my Phobos fork
because I kinda want to remain ddoc compatible... and I can never
remember what macro it is. And I've been kinda deep in this the
whole last week.
Anyway, let's get into this:
On Sunday, 3 January 2016 at 23:16:30 UTC, Andrei Alexandrescu
Do the projected advantages of Adam's project do not include
ease of contribution? If so, how?
1) a massively simplified build. Indeed, I'll make a web form so
you don't even have to have dmd installed to make some docs.
This got posted today:
Two people whose names I recognize who have been with D for a
long time didn't know how to add a page to the website. And what
they did figure out was a multi step process.
My system already runs a single file or an entire directory and
just works. It will never forget a file because you didn't add it
to mak/DOCS of win32.mak or anything else.
I'll also make a web form to upload new pages and probably entire
projects for automatic processing too.
2) My linking system already works better than ddoc allows. You
can reference with a single macro: $(REF some.name). I also keep
MREF, XREF, and a few others for legacy phobos+ddoc
compatibility, but the user doesn't have to know a hundred
obscure macros. (There's about a half-dozen simple ones instead,
plus a few thin wrappers over HTML which I might kill but might
not since they don't really bother me.)
Combined with the ease of adding all new files, contributors can
just link new articles they write to go in depth without worrying
3) I'm also going to make a dynamic webpage once I declare this
beta where viewers will be given random pages and asked to
eyeball it for me. If they flag it as buggy - with a single click
on the page, no bugzilla signups - it'll contact me and I'll work
on the bug.
If they want to contribute to content, I can pull up the existing
comment source code and present it right there, again likely
emailed to me for integration, or the source location can be
opened in Phobos for a traditional pull request.
This will encourage crowd sourcing doc bug fixes.
4) I'll never complain about spaces vs tabs, line length, or any
other trivial nonsense. If I don't like that stuff, I'll just fix
it myself instead of letting the PR wither and die while letting
the contributor feel undervalued.