On Wednesday, December 4, 2024 10:30:34 AM MST Andreas Tille wrote:
Am Mon, Dec 02, 2024 at 06:15:22PM -0700 schrieb Soren Stoutner:and
I think one of the best things we could do to attract new contributors,
Debianto encourage those who are currently Sponsored Maintainers to become
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.
Speaking both with and without my DPL hat, I don't think a delegation is
necessary. Instead, I would prefer to establish a way to direct sponsees
to the appropriate team for their package. From my experience, the teams
I work with are quite effective at sponsoring packages that fit their
scope and are maintained within the team's Git repository. I believe
that ensuring a package fits properly into a team is a key prerequisite
for a good sponsor-sponsee relationship.
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need
is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure
and workflows.
I have directed several RFS (Request For Sponsor) towards appropriate teams, when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.
I suspect the RFS process would be more successful in finding a sponsor
if the requests went to debian-devel rather than another opt-in mailing
list. I rarely go looking for more work to do by viewing
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable
so I would never find a RFS unless someone ping'ed a packaging group
that I'm part of to help.
The noise level of debian-devel would go up, but if we collectively find
RFS being ignored a serious problem, then maybe making noise about a
serious problem is a good idea.
But after seeing the ping's I decided to help on packages that^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
happened to be some that I had some familiarity with already. So at
least for these packages, ping's did increase the sponsorship rate.
On Wed, Dec 04, 2024 at 08:03:49PM +0100, Simon Josefsson wrote:
I suspect the RFS process would be more successful in finding a sponsor
if the requests went to debian-devel rather than another opt-in mailing
list. I rarely go looking for more work to do by viewing
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable
so I would never find a RFS unless someone ping'ed a packaging group
that I'm part of to help.
Do you think people who aren't interested in reviewing or sponsoring
random packages and so don't go to the link you provided will sometimes sponsor some package they noticed on d-devel@? Or how should this change increase the sponsorship rate?
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need >>> is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure >>> and workflows.
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need >>> is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't >>> involve authority, but rather a deep understanding of Debian's structure >>> and workflows.
Is this sort of thing documented anywhere?
It's not the sort of thing that needs to be strictly updated like a man page or other technical document. It just needs to be a couple of pages that describe the "general" (big picture structure an workflows) to get that established as a reference andthen some of the "specifics" for at least the larger teams who have workflows more complex than "apt info package | grep -i maintain".
Not only would it help outsiders and newbies get a feel for how things work, but it would create visibility among the existing teams and allow them to compare and contrast their workflows (with some mentions of "different != bad").
These are valid concerns. I think the tooling from Phil should help
with your point 2 and 3. For 4-6, I personally never expect the same DD would provide long-term support after sponsoring. Maybe making that
clear on the Debian wiki[1] would help with aligning the expectations.
[1] https://wiki.debian.org/DebianMentorsFaq
Am Thu, Dec 05, 2024 at 08:03:36AM -0600 schrieb rhys:and then some of the "specifics" for at least the larger teams who have workflows more complex than "apt info package | grep -i maintain".
It's not the sort of thing that needs to be strictly updated like a man page or other technical document. It just needs to be a couple of pages that describe the "general" (big picture structure an workflows) to get that established as a reference
Not only would it help outsiders and newbies get a feel for how things work, but it would create visibility among the existing teams and allow them to compare and contrast their workflows (with some mentions of "different != bad").
IMHO the most natural thing to seek for friends is looking for packages
with functionality covering a similar use case or written in the same programming language. Than you do
apt showsrc similar_package(s) | grep ^Maintainer
and if you are lucky you have found some friends.
It doesn't seem good for Debian, or the sponsee, for the DD to sponsor
it through NEW and then leave the sponsee in limbo.
Xiyue> Thanks for your input! For sure if what-you-suggest happens"Xiyue" == Xiyue Deng <manphiz@gmail.com> writes:
As an outsider trying to help, the natural thing I looked at was the RFH process to dip my toes into things.
But only 56 packages have RFH bugs and they're usually not very clear on what help they need. And most of those were requested >1 year ago.
On Tue 10 Dec 2024 at 01:31pm GMT, Ahmad Khalifa wrote:
As an outsider trying to help, the natural thing I looked at was the RFH
process to dip my toes into things.
But only 56 packages have RFH bugs and they're usually not very clear on what
help they need. And most of those were requested >1 year ago.
They are usually still valid. I have one from last year and I would
still like help.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 160:38:23 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,056 |
| Messages: | 6,416,493 |