Re: aims of the wiki?
On Mon, Aug 18, 2025 at 10:42:00AM +0200, Beatrice Torracca wrote:
> I'd like mostly to point out one of my major pet peeve/dissatisfaction with
> the current wiki: redundancy, both internal and external (with the website).
If you'll excuse my own little ramble, I've spent some time on packaging docs
and think they're an interesting example of redundancy...
The Guide for Debian Maintainers[0] strikes me as a good canonical reference
for downstream writers who want to know the correct answer to questions
the authors never thought to ask, like how to use the phrase "patch unapplied".
But it's no use for newbies, because the learning curve is too steep.
Otto Kekäläinen has written a series of blog posts[1] about packaging.
I've never talked to him, but I would describe them as saying "here are
the tricks I wish I knew when I was becoming a member of the Debian community".
Praveen A has recently worked on Packaging/Learn. Again, we've never talked,
but I would describe his approach as answering the question
"what is the packaging route to becoming a member of the Debian community?".
I've written MakeAPrivatePackage and rewritten PackagingWithGit, and would have
found an excuse to rewrite the equivs-build man page[2] if it weren't so
annoyingly perfect. I think they answer the question "how do I use Debian's
software stack to solve my problems, which may or may not have anything
to do with the Debian project?".
Any given reader would see them as redundantly covering the same topic,
at most one of them successfully. So it would be tempting to merge them.
But in fact they each address a slightly different audience,
so IMHO they should all stay and people should be directed to
the most appropriate resource for them.
On the other hand, PackagingFAQ ruthlessly merges several other FAQs
that IMHO make more sense on a single page. Asking readers to hop from
one FAQ to the next would just waste their time.
Going back to the "wiki aims vs. our aims" issue - I would hate to think
we had to choose between Praveen's series and mine, but I would love for
the Packaging portal to direct users towards the right resource for them.
So instead of always aiming to avoid duplicate content, it would be better
to develop a range of tools (portals, navboxes etc.) to capture the range
of relationships between pages.
[0] https://www.debian.org/doc/manuals/debmake-doc/index.en.html
[1] https://optimizedbyotto.com/post/debian-packaging-from-git/
[2] https://manpages.debian.org/testing/equivs/equivs-build.1.en.html
Reply to: