Note - This email was originally send directly to Andreas Tille, as my
MUA ignored his "Mail-Followup-To: header".
Andreas asked me to answer to debian-devel@lists.debian.org. Please note
that I have not subscribed to debian-devel and do not plan to subscribe
at the moment. If you want me to read your answer or to clarify a point,
please take me on Cc:.
Hi Andreas,
I'm not sure if you are looking for feedback on attracting newcomers. I
was tempted to answer the last "Bits from the DPL", and as the topic
comes up again in this new "Bits from the DPL", so here you are. If you
are not looking for feedback - just ignore this email, I won't be
offended 😉
I am not a Debian developer, but tried twice to package software into
debian.
I've already done some debian packaging as a developer
(https://metadata.ftp-master.debian.org/changelogs//main/i/ipfm/ipfm_0.11.5-4.3_changelog)
and I would describe my debian skills as an admin/user as quite good. I
have been using Debian as my primary desktop and for servers for about
25 years. I'm not an English native speaker, and I hope my email is
clear enough and not too hard to read.
My last attempt was about two years ago. I wanted to package gns3 and
relevant tools. Here is my experience.
1) Documentation
There was a lot of reading involved (no problem here - it is great to
have a detailed documentation) but it was very confusing that there were
different guides addressing the same things:
Debian Developper's Reference
- https://www.debian.org/doc/manuals/developers-reference/index.en.html
- More the organizational aspects - OK, no problem here.
Then three different guides which cover more or less the same topics and
reference to each other and are/were partially outdated:
- Debian New Maintainer's Guide
https://www.debian.org/doc/manuals/maint-guide/index.en.html
- Guide for Debian Maintainers
https://www.debian.org/doc/manuals/debmake-doc/index.en.html
- Debian Policy Manual https://www.debian.org/doc/debian-policy/
This is not good. Debian packaging is quite overwhelming and difficult
to learn for a newcomer, in particular when he wants to build a package
from scratch (which may not the best way to start). Having three
different Manuals do not help. At least the "Debian New Maintainer's
Guide" should completely be removed from debian.org.
2) What should I read first if I want to make a new package?
When I read https://www.debian.org/devel/join/index.en.html, I miss a
link to the Debian Developper's Reference and the Guide for Debian
Maintainers or the Debian Policy Manual.
I read that I should subscribe to a lot of mailing lists, work on
work-needing packages, do secondary tasks (docs, website, translation,
QA), but nothing about how I can start the rough path to make a debian
package.
Even in https://www.debian.org/devel/join/newmaint , I do not find a
link to a documentation on how to make a package.
Sure, I will finally land on on of the three documents above. With some
bad luck, I will land on the (old) "Debian New Maintainer's Guide".
3) Salsa
It is not clear to me if salsa is exclusive for DD or open to anyone.
https://www.debian.org/devel/join/newmaint.en.html states "prospective
Debian Developers" should create an account.
My understanding is that salsa should be open for everyone, like in
github. If I have a problem with a debian package, I would like to fork
it on salsa, patch it an submit a PR. I don't have to be a debian
developper for this and it could be a great entry point for potential
developers.
It probably is. Just write it explicitly on:
- https://www.debian.org/devel/join/newmaint
- https://wiki.debian.org/Salsa
- https://www.debian.org/doc/manuals/debmake-doc/ch10.en.html#salsa-repo
4) Localization on www.debian.org
I live in Germany, and was born in France, so my language preference in
firefox is de > fr > en.
When I visit debian.org, I get it in German. So far, so good.
When working in an English context, I prefer using the document in
English (for example in order to write this email).
I choose "English" at the bottom of debian.org and get the page in
English. So far, so good
When I click on most of the links, I get the generic URL and not the
localized one (index.en.html). So I'm back to German and have to choose
English manually or in some docs (developers-reference / debian-policy)
I must click on a link, manually replace ".de." into ".en." in the URL,
and click on the home of the document). This is very annoying and make
the process of learning how to package harder than it could be.
Sure, I could read it in German, change my browser preferences or use
Chrome with English preferences. It's just one more challenge in the way.
With these difficulties plus the constant need of prioritizing my time,
I ended in installing gns3 with `pip install` and pushing my next time
trying to package something for debian (doing the things right) in some
future day. I probably did not tried hard enough, or the challenges
along the way were too big for the effort I was ready to invest in it at
the time. I work on other open source projects where the entry barrier
was lower.
Debian is still a matter of the heart to me, and it was important enough
to me to take the time to write this email even if I don't know if it
will land in your trash 😉. I will probably try the process again in a
few years. In the meantime, I hope that my feedback can help Debian to
somehow flatten the path for new developers.
Keep on the good work!
Robert
Am 02.12.24 um 17:32 schrieb Andreas Tille:
Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.
My personal impression is that we sometimes fail to convey that Debian
is not just a product to download for free but also a technical
challenge that warmly invites participation. Everyone who respects our
Code of Conduct will find that Debian is a highly diverse community,
where joining the project offers not only opportunities for technical
contributions but also meaningful social interactions that can make the
effort and time truly rewarding.
In several of my previous talks (you can find them on my talks
page[mt4]--just search for "team," and don't be deterred if you see
"Debian Med" in the title; it's simply an example), I emphasized that
the interaction between a mentor and a mentee often plays a far more
significant role than the documentation the mentee has to read. The key
to success has always been finding a way to spark the mentee's interest
in a specific topic that resonates with their own passions.
Bug of the Day
--------------
In my presentation[mt3], I provided a brief overview of the Bug of the
Day initiative, which was launched with the aim of demonstrating how to
fix bugs as an entry point for learning about packaging. While the
current level of interest from newcomers seems limited, the initiative
has brought several additional benefits.
I must admit that I'm learning quite a bit about Debian myself. I often
compare it to exploring a house's cellar with a flashlight--you uncover
everything from hidden marvels to things you might prefer to discard.
I've also come across traces of incredibly diligent people who have
invested their spare time polishing these hidden treasures (what we call
NMUs). The janitor, a service in Salsa that automatically updates
packages, fits perfectly into this cellar metaphor, symbolizing the
ongoing care and maintenance that keep everything in order. I hadn't
realized the immense amount of silent work being done behind the
scenes--thank you all so much for your invaluable QA efforts.
