| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 107:37:03 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,678 |
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.
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/
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.
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.
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:
2) What should I read first if I want to make a new package?
2024, ഥിസഠ4 9:33:25 PM Robert ChÊramy <robert@cheramy.net>:packages
2) What should I read first if I want to make a new package?
I usually suggest a step by step guide to people who are new, in this I suggest building existing packages from source and updating existing
before creating a new package from scratch.
Also starting with JavaScript packages makes a lot of automations to make things easier for new people. Once they pick basics of packaging with js, they can start with other packages easily.
https://wiki.debian.org/Packaging/Learn
https://debconf24.debconf.org/talks/74-attracting-and-retaining-new-contributors-insights-from-brazil/public discussions.
There was some follow-up discussion in Hacker News after a LWN post about this talk was published:
https://lwn.net/Articles/987548/ https://news.ycombinator.com/item?id=41599327
I think people interested on the subject can get some insights from the above (comments from people not involved in the project; yes, we, people already involved in the project, can be very biased). Also ignore some stupid comments, expected in those
And yes, this is something that Debian as whole needs to do better.
2024, ഥിസഠ5 2:05:19 AM Lucas Kanashiro <kanashiro@debian.org>:public discussions.
https://debconf24.debconf.org/talks/74-attracting-and-retaining-new-contributors-insights-from-brazil/
There was some follow-up discussion in Hacker News after a LWN post about this talk was published:
https://lwn.net/Articles/987548/ https://news.ycombinator.com/item?id=41599327
I think people interested on the subject can get some insights from the above (comments from people not involved in the project; yes, we, people already involved in the project, can be very biased). Also ignore some stupid comments, expected in those
And yes, this is something that Debian as whole needs to do better.
I want to comment about registering on wiki.debian.org and
salsa.debian.org specifically.
Can we setup a system for adding to allow list by DD signed emails
(like how debian.net DNS changes are done)? Possibly for IP address
allow list too.
This would help a lot during events or for local groups where getting
a wiki account takes sending an email and waiting.
Now that I think about this idea, this would also help for salsa
accounts. It takes many days to get a salsa account after an event and
I usually have to ask them to use another git hosting service till
that happens.
A DD validating email address and IP address can address the spam
concern. This will expand people who can authorize new accounts
hugely. Also reduce load on current admins and wait time for new contributors.
Robert,
I appreciate your addition to the discussion.
On Wednesday, December 4, 2024 8:53:07 AM MST Robert ChĂŠramy wrote:
1. ...
âThere are seventeen different
ways to create a Debian package. We are only going to consider fifteen of them
here. Every one is different. You should just use the one that works best for
your situation. We canât be bothered to explain to you how you can tell which
one will be best for your situation, but you will know it when you see it. Also, most of these workflows are incompatible with each other, and everyone who uses any workflow besides the one I like is an idiot. Also, I canât be bothered to explain all the intermediary steps or any corner cases, but youâll
figure them out as your go.â
I have written in other venues about the need for Debian to pick one canonical
workflow. This workflow could then be documented in detail, including corner cases, and presented in a step-by-step guide that doesnât assume any previous
knowledge about Debian. There are several people diligently working on trying
to get Debian to consolidate on one (or a few) accepted workflows, but the resistance from some developers who have their other favorite workflows is intense. In my personal opinion, for the good of the project and the need to attract far greater than 1,000 active Debian Developers, we need to overcome our personal workflow opinions and consolidate on one choice, even if we consider choice to be technically inferior to our preferred option.
2. A vast amount of the step-by-step documentation written for beginners regarding how to package for the first time is subtly outdated in ways that become very confusing to beginners. Usually, at the time the documentation was written, it was correct. But things change quickly in Debian, and often nobody revisits and updates these howto guides.
I think that if we want to get serious about ever attracting a large number of
new Debian Developers, we need a team of people (probably, again, a DPL delegation) ...
Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
that seemingly hasn't been covered yet:
The BTS is core to Debian. It is e-mail based. While I personally think e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes â as much as 10 or 15 â for replies to simple operations.
On Tue, Dec 10, 2024 at 09:18:06AM +0100, Gard Spreemann wrote:
Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
that seemingly hasn't been covered yet:
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes â as much as 10 or 15 â for >> replies to simple operations.
TBH there is a difference between "email based and asynchronous" and
"needs at least 10 minutes to process a request". It seems to be a problem specific to the BTS.
On Tue, Dec 10, 2024 at 09:18:06AM +0100, Gard Spreemann wrote:
Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
that seemingly hasn't been covered yet:
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes â as much as 10 or 15 â for >> replies to simple operations.
TBH there is a difference between "email based and asynchronous" and
"needs at least 10 minutes to process a request". It seems to be a problem specific to the BTS.
The BTS is core to Debian.
On Tue, 10 Dec 2024 09:18:06 +0100, Gard Spreemann <gspr@nonempty.org>
wrote:
The BTS is core to Debian.
And it is one of the best Bugtrackers I have ever encountered.
It could be faster, yes, but its features trump the waiting time by
far.
Here's the default crontabs for debbugs.
There do exists an handfull of other instances of debbugs, some might deviate from default settings.
GreetingsÂ
/usr/lib/debbugs/processall >/dev/null
7,22,37,52 * * * *Â
https://bugs.debian.org/debbugs-source/debian/debian/crontab
I am sincerely shocked by the default setting of doing a processing every
15 minutes by default
The BTS is core to Debian. It is e-mail based. While I personally think e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes â as much as 10 or 15 â for replies to simple operations. Not only because being assigned a bug
number is actually necessary in order to move on with some processes
like initial packaging, but also because of the mental toll that comes
from not knowing that a past operation successfully completed, and
worrying that I'd have to return to it.
Le Tue, Dec 10, 2024 at 09:18:06AM +0100, Gard Spreemann a ĂŠcrit :
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes â as much as 10 or 15 â for >> replies to simple operations. Not only because being assigned a bug
number is actually necessary in order to move on with some processes
like initial packaging, but also because of the mental toll that comes
from not knowing that a past operation successfully completed, and
worrying that I'd have to return to it.
Thanks Gard for your comment. I would like to add that it is not just a problem to newcomers. The time I can give to Debian is often 1 hour at
most per day, and waiting times being 25% of my time budget can
obviously ruin the day. And the lack of the confidence in the system
can not be solved entierly by knowledge, skill or experience, because
the core of the problem is that every year it is less guarateed that an
email is really being delivered after being sent.
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.
Kind of like a mailing list web interface (hyperkitty in mailman) that
allows sending mails from a browser after authenticating.
Say reportbug.debian.org which has a login with salsa button (and create
a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be >forwarded to the email address in salsa account.
On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen
<praveen@onenetbeyond.org> wrote:
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.
Is it not already the case that you can use reportbug without
e-mail-client or local server installed?
Kind of like a mailing list web interface (hyperkitty in mailman) that
allows sending mails from a browser after authenticating.
Say reportbug.debian.org which has a login with salsa button (and create
a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be
forwarded to the email address in salsa account.
How would the local data be collected and included?
People who can install and use an app on their mobile can also use
reportbug.
Greetings
Marc
As I said, it is not impossible, but a painful process. I use reportbug only when I have to generate a template for rm requests, otherwise I always write an email. We should avoid asking new people to run through hoops when possible. With enough practice, anyone could jump through a hoop as well.
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be configured will already help.
Is it not already the case that you can use reportbug without
e-mail-client or local server installed?
You have to quit reportbug and copy paste the text file to an email client.
I use it sometimes, but not friendly.
Le 2024-12-11 13:52, Pirate Praveen a Êcrit :
reportbug can talk SMTP directly, is that not enough for you?
without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?
It does, and that works for me (though maybe not from some places that
block some traffic).
`reportbug.debian.org` is hardcoded as the SMTP host to use when no
other SMTP host is configured.
reportbug can talk SMTP directly, is that not enough for you?
without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?
On Wed, Dec 11, 2024 at 05:50:55PM +0530, Pirate Praveen wrote:
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.
Is it not already the case that you can use reportbug without
e-mail-client or local server installed?
You have to quit reportbug and copy paste the text file to an email client. >> I use it sometimes, but not friendly.
reportbug can talk SMTP directly, is that not enough for you?
On 12/11/24 6:35 PM, sre4ever@free.fr wrote:
Le 2024-12-11 13:52, Pirate Praveen a Êcrit :
reportbug can talk SMTP directly, is that not enough for you? >>>>without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?
It does, and that works for me (though maybe not from some places
that block some traffic).
Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are obvious.
That is, it's often a pain to set up outgoing SMTP. As a user you do it
for your MTA since you just have to. But a CLI tool to report Debian
bugs? Will not be configured by any newcomer if you ask me.
Thanks, in that case, it is my mistake. I was always thinking it needs
an mta configured, may be this was a recent addition. Not sure if it was there from the beginning.
Many firewalls (for example in offices) also block almost every port
other than 80 or 443. So it'd still be valuable to have a web based
reportbug interface.
Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are obvious.
a CLI tool to report Debian bugs? Will not be configured by any
newcomer if you ask me.
Last time I had to write a removal request I asked ChatGPT and it worked well!
I would like to add that while self-sustained SMTP facilities is
useful, the reportbug tool has a strong assumption: it assumes that the
bug reporter must be using Debian (or one of the Debian derivative,
though we know it won't work well) when reporting the bug. This is an
overly strong requirement that we as a project should avoid.
I would like to add that while self-sustained SMTP facilities is useful, the reportbug tool has a strong assumption: it assumes that the bug reporter
must be using Debian (or one of the Debian derivative, though we know it won't work well) when reporting the bug. This is an overly strong
requirement that we as a project should avoid.
On Wed, Dec 11, 2024 at 09:29:08PM +0900, Charles Plessy wrote:
Last time I had to write a removal request I asked ChatGPT and it worked well!
is this debian-devel@ or -curiosa@? (&scnr)
that said, I do realize that the verb "to google" slowly is becoming "to
ask $chatgpt" or rather, that also google is a frontend to a huge statistical database...
more seriously, once you learn something which you think should be better documented, please consider contributing to some of the various documentations
for Debian.
On 12/11/24 5:20 PM, Marc Haber wrote:
On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen
<praveen@onenetbeyond.org> wrote:
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.
Is it not already the case that you can use reportbug without
e-mail-client or local server installed?
You have to quit reportbug and copy paste the text file to an email
client. I use it sometimes, but not friendly.
How would the local data be collected and included?
We can ask them to run a command and copy paste the output.
I'm not suggesting we remove email interface, just adding other options
for people who don't find email as their default communication tool.
On 12/11/24 6:35 PM, sre4ever@free.fr wrote:
Le 2024-12-11 13:52, Pirate Praveen a Êcrit :
reportbug can talk SMTP directly, is that not enough for you? >>>>without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?
It does, and that works for me (though maybe not from some places that
block some traffic).
Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are >obvious.
While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100% confident with the system, I way too often found myself waiting
minutes â as much as 10 or 15 â for replies to simple operations.
While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100% confident with the system, I way too often found myself waiting
minutes â as much as 10 or 15 â for replies to simple operations.
agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged
I'd like to help improve the docuemntation, and suggest ways to make it
less confusing to use, but the bts's own bug list makes me wonder if
anyone would review
Gard Spreemann <gspr@nonempty.org> writes:
While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes â as much as 10 or 15 â for replies to simple operations.
agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged
Gard Spreemann <gspr@nonempty.org> writes:
While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes â as much as 10 or 15 â for replies to simple operations.
agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged
On Wed, Dec 11, 2024 at 09:29:08PM +0900, Charles Plessy wrote:
Last time I had to write a removal request I asked ChatGPT and it worked well!
is this debian-devel@ or -curiosa@? (&scnr)
Being not 100% confident with the system,
I way too often found myself waiting minutes â as much as 10 or 15 â for replies to simple operations.
Hi,
While I personally think e-mail-based workflows can be quite nice, the BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100% confident with the system, I way too often found myself waiting
minutes â as much as 10 or 15 â for replies to simple operations.
agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged
I'd like to help improve the docuemntation, and suggest ways to make it less confusing to use, but the bts's own bug list makes me wonder if
anyone would review
I submitted 4 years ago https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/6,
which got some approving comments, but nobody merged it. Your time is probably better used contributing to the Debian Developers Reference
or other docs.
Honestly, I suspect bugs.debian.org is intentionally cumbersome to use
to deter "noobies", and raise the bar for submission so high, that any
bug that actually gets filed is likely already well researched by a
Debian expert and half of the time comes with a patch attached.
Unfortunately it also leads to maintainers having to put more effort
in maintaining the bug reports as the barrier for contributors to help
out with bug triage etc way too high.
Btw, for triage I used to suggest https://fabre.debian.net to
newcomers. I had some hope that it could be a start for something
bigger, so I tried to have access to the code to improve a few things
but never had an answer from the maintainer :\
On 12/11/24 5:20 PM, Marc Haber wrote:
On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen <praveen@onenetbeyond.org> wrote:
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be configured will already help.
Is it not already the case that you can use reportbug without
e-mail-client or local server installed?
You have to quit reportbug and copy paste the text file to an email client.
I use it sometimes, but not friendly.
Kind of like a mailing list web interface (hyperkitty in mailman) that allows sending mails from a browser after authenticating.
Say reportbug.debian.org which has a login with salsa button (and create a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be forwarded to the email address in salsa account.
How would the local data be collected and included?
We can ask them to run a command and copy paste the output.
People who can install and use an app on their mobile can also use reportbug.
As I said, it is not impossible, but a painful process. I use reportbug only when I have to generate a template for rm requests, otherwise I always write an email. We should avoid asking new people to run through hoops when possible.
With enough practice, anyone could jump through a hoop as well.
Initial days of the project, email was the primary communication for all the people and these things (configuring email) were taken for granted. But now email is not a primary communication tool for so many people.
I'm not suggesting we remove email interface, just adding other options for people who don't find email as their default communication tool.
reportbug can send emails through sendmail (if you have that
configured), or it can be set up so it can bypass that entirely and send email directly to an SMTP server.
- at work, not using LLMs to write code is like refusing to wear shoes
at the Olympics because Greeks did not and saying that shoes pollute
and the run is no less fun when everybody agreed to be bare feet.
True, but people taking this stance do not stay in competition.
That said, the critique is received, and I've been very, very slowly
working on rewriting the entire system to address some of these issues. [Being a parent has made my Debian time very precious, however, so
keeping things running has taken precedence.]