Bits from DPL

[Soren Stoutner]

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.

I think one of the best things we could do to attract new contributors, and to
encourage those who are currently Sponsored Maintainers to become Debian
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation. This would
build on the excellent work Phil Wyett is currently doing as the unofficial
Mentors Triage.

Too many contributors prepare a Debian package, submit it to Mentors, and then
never have it reviewed and sponsored by a Debian Developer. This can be
highly demotivating for the contributor. I think that having a team of Debian
Developers dedicated to reviewing every package submitted to Mentors would do
more to encourage more contributions to Debian, and more people becoming
Debian Maintainers and Debian Developers, than anything else I could name.

In my own case, I was lucky enough that my first contribution to Mentors caught
the eye of a Debian Developer who responded in a timely fashion and mentored
me through the process of getting the package into shape for sponsorship. At
the time, I assumed such a response was common for every submission. It was
only later that I discovered that my experience was the exception.

Shortly after becoming a Debian Developer, I tried to make a contribution to
Guix. With each submission, there was a long delay without any response.
Each person who did eventually respond suggested some change, which was
quickly made. However, the person making the suggestion then didn’t respond,
and much time passed before a different person responded with a different
suggestion. Eventually, I just gave up and the submission was never merged.

Unfortunately, I think that many contributor’s experiences with Debian are
closer to what I experienced with Guix than what I experienced with Debian.
If we can change that, I think we would see an influx of contributions to the
project.

[Antonio Russo]

Post by Soren Stoutner
Unfortunately, I think that many contributor’s experiences with Debian are
closer to what I experienced with Guix than what I experienced with Debian.
If we can change that, I think we would see an influx of contributions to the
project.

As a contributor who would like to contribute more, I can second (third?)
this. I am continually coming across minor-to-major problem which I
eventually resolve for myself. In the past, the difficulty of even getting
bug reports with patches that resolve issues to be looked at, much less
merged really wore on me.

My personal journey has been to establish pipelines to rebuild packages with
those fixes in them for myself and my family members. After getting those
issues diagnosed (a strict requirement), my top priority is now to maintain
those pipelines. From a "boundary setting" perspective, I limit my time
trying to communicate those fixes, either to Debian or further upstream.

Moreover, I'm increasingly of the opinion that fixes should only be presented
when they are both absolutely perfect for myself and from a software
engineering perspective, since it seems that even minor details will be
criticized, if the issues are even responded to at all. If projects don't
seem receptive, I often de-prioritize sending patches to them. Debian falls
into that category.

This means that some issues go years (and counting) without those fixes
merged. And my personal drive to get them merged is near-zero at this point,
since it doesn't really even benefit me personally.

I understand everyone is busy (as I am, too). But seeing contributions go
unacknowledged demoralizes people a lot.

Perhaps teams could start looking at human-contributed MRs and patch-tagged
bug reports that have been untouched for more than (say) 6 months? I haven't
mustered the care to try to send another RFS in over a year, but looking
at debian-mentors triage work recently, it seems like things might be
better.

Antonio

[Phil Wyett]

Post by Antonio Russo

Post by Soren Stoutner
Unfortunately, I think that many contributor’s experiences with Debian are
closer to what I experienced with Guix than what I experienced with Debian.
If we can change that, I think we would see an influx of contributions to the
project.

As a contributor who would like to contribute more, I can second (third?)
this. I am continually coming across minor-to-major problem which I
eventually resolve for myself. In the past, the difficulty of even getting
bug reports with patches that resolve issues to be looked at, much less
merged really wore on me.
My personal journey has been to establish pipelines to rebuild packages with
those fixes in them for myself and my family members. After getting those
issues diagnosed (a strict requirement), my top priority is now to maintain
those pipelines. From a "boundary setting" perspective, I limit my time
trying to communicate those fixes, either to Debian or further upstream.
Moreover, I'm increasingly of the opinion that fixes should only be presented
when they are both absolutely perfect for myself and from a software
engineering perspective, since it seems that even minor details will be
criticized, if the issues are even responded to at all. If projects don't
seem receptive, I often de-prioritize sending patches to them. Debian falls
into that category.
This means that some issues go years (and counting) without those fixes
merged. And my personal drive to get them merged is near-zero at this point,
since it doesn't really even benefit me personally.
I understand everyone is busy (as I am, too). But seeing contributions go
unacknowledged demoralizes people a lot.
Perhaps teams could start looking at human-contributed MRs and patch-tagged
bug reports that have been untouched for more than (say) 6 months? I haven't
mustered the care to try to send another RFS in over a year, but looking
at debian-mentors triage work recently, it seems like things might be
better.
Antonio

Hi Antonia,

It is easy to feel criticized in a project such as Debian. You can submit to
three packages in two teams and each may have their own contribution criteria.
Modifying patches or MR's to make them comply or make them better is all part
of the game and in most cases not personal at all. Never feel a contribution
needs to be perfect prior to submission, we learn contributing and who you
submit to can also learn from your contributions and interactions in some
cases.

Regards

Phil
--
Donations...

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Liberapay: https://liberapay.com/kathenas

--

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Wiki: https://wiki.kathenas.org

Instagram: https://instagram.com/kathenasorg

Threads: https://www.threads.net/@kathenasorg

--

[Richard Lewis]

Post by Soren Stoutner

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.

I think one of the best things we could do to attract new contributors, and to
encourage those who are currently Sponsored Maintainers to become Debian
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation.

I dont disagree with anything you wrote, but i think people are looking
at "Needs a DD to make the process work" and assuming that the only
solution is to increase the number of DDs. But the process itself can
also be changed.

at least some of the feedback so far is that people want to contribute
without having to be a DD

[Soren Stoutner]

Post by Richard Lewis

Post by Soren Stoutner

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.

I think one of the best things we could do to attract new contributors,

and

Post by Richard Lewis

Post by Soren Stoutner
to encourage those who are currently Sponsored Maintainers to become

Debian

Post by Richard Lewis

Post by Soren Stoutner
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation.

I dont disagree with anything you wrote, but i think people are looking
at "Needs a DD to make the process work" and assuming that the only
solution is to increase the number of DDs. But the process itself can
also be changed.
at least some of the feedback so far is that people want to contribute
without having to be a DD

That is true. Not everyone who wants to contribute to Debian would like to
become a Debian Maintainer or a Debian Developer. And we want to make sure
that we always have a welcoming environment for such contributions.

But my personal experience working with people making contributions to Debian
Mentors is that more than half of them do have interest in becoming a Debian
Maintainer or a Debian Developer, but are stymied in the process along the
way. When thinking about increasing the number of Debian Developers, I
consider these people to be the low-hanging fruit. They have already
expressed a desire to contribute to Debian. They have already put forth
enough effort to do some level of packaging and upload it to
mentors.debian.net. They often need some further technical guidance (I
certainly did). But it would take a lot less effort to get them over the hump
than it would to start fresh with someone who has no exposure to Debian, which
is where it seems that the majority of our recruitment efforts focus.

[Soren Stoutner]

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

packages

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

That’s a really nice resource. I am surprised I haven’t seen it before.