This report started as a summary from the sponsorship BoF held during
Debconf 11 in Banja Luka. The full video stream is available on [0].
These were the major points, as interpreted by Arno Töll and David
Bremner. As it was being written up, a few relevant things happened
with debexpo (mentors.debian.net) and/or were discussed on the list,
so we added some pointers to those as well.
Q: Why does Debian sponsor uploads?
- -----------------------------------
Many present agreed that the main reason to sponsor uploads is
training. New contributors need experience and training to get
packages in shape. Therefore the mentoring process can be seen as
incubator to develop new (uploading) Debian developers. One impression
to support this is that as new contributors tend to package software
for a fairly narrow target group.
On the other hand, several people outlined the technical benefit of
sponsoring packages, which is to get new software (typically that the
sponsors themselves consider useful or interesting) into Debian.
Similarly sponsors upload packages which have been orphaned by the former
maintainer.
Debian has several teams, at least some of which are highly effective
at mentoring, and all of which have more specialized expertise than
the debian-mentors mailing list. In principle the mentoring process
should generally endorse people to join existing teams. This is
mutually beneficial, as new contributors learn best practices and
workflows while helping with the workload of teams. Unfortunately
apparently [1] only 20% of all RFS requests appear to be related to
the work of existing teams.
Q: How are we doing, what could we improve?
- -------------------------------------------
Several problems were identified with mentoring process (or with the
experience of mentees). Broadly speaking these are in the (overlapping)
areas of making connections with sponsors, getting feedback, and
variability/fairness.
There was some discussion about how people have succeeded in finding
sponsors, and how sponsors like to be found. One or two people
mentioned only succeeding because of a pre-existing social
relationship. Most, but not all, sponsors preferred email over IRC as
a contact point.
Lack of feedback in the mentors process is a problem for several
reasons. The current mentors process has a fairly large degree of
uncertainty. Often it is unknown to sponsorees how they are doing as
there is no (visible) progress or feedback at all. This is
discouraging for new contributors. In fact the mentors FAQ already
gives some ideas about what to do in this case (ask on IRC, ask again,
and so on). It isn't clear how much people read this FAQ, maybe some
automatic messages could be generated from mentors.debian.net with
hints about future steps.
Another, quite different problem with the mentors process is that it
seems based on the false assumption that every package belongs to
Debian. Many packages are either too immature or don't add anything
really new to Debian. We should be willing to tell people this,
rather than politely ignoring packages and hoping they go away.
Debian is supposed to be "Do-ocracy", in particular as many decisions
as possible are left to the individual developer. From the sponsoree
perspective the result is a bit chaotic: they hear different stories
about what is mandatory and what is suggested. There is also the
element of developer taste, which varies widely in terms of what
software they find interesting and worthwhile. This can result in a
high quality package providing software for special interests gets
lost, while a less good package but targeting a more popular area of
interest is sponsored. There was no concensus about whether it was
possible (or desirable) to change these subjective aspects, but see
below for a technical proposal about matching packages and sponsors.
Recently, Michael Gilbert asked to switch the reviewing part of the
mentoring process to the Debian Bug Tracking Systems (BTS) [2]. If you
are sponsoring packages or being a sponsored maintainer, please tell
us your opinion here, as there are possible improvements over the
current procedure observable, as well as concerns. Help us to find
the best solution.
Q: Should there be a mentors team, or some other structure?
- -----------------------------------------------------------
The discussion, whether there should be a "mentors team" can be seen
From two perspectives. First, one could see it as team which looks for
"lost and lonely" packages, and sees as last resort, whether it could
be uploaded to Debian. Generally this idea did not seem to attract many
persons in the audience.
Alternatively, this could be seen as collaborative maintenance team,
similar to the QA team (including its drawbacks), where sponsors and
maintainers get together to collectively improve packages. Some people
casted doubts on this idea as well, mentioning the QA team as refer-
ence, where everyone but effectively nobody feels responsible for
certain packages for example.
Q: Technical solutions for social problems?
- -------------------------------------------
It was suggested to provide a list of potential and willing sponsors,
where they can outline their personal sponsor guidelines and area of
interest - see below. This is also related to Paul Wise's sponsor
metrics [3]. That's an idea to bring together sponsors with
packages. For example, a software mechanism would collect attributes
related to a package and its packages (e.g. section of a package,
purpose, mind of the packager about NM/DM) on a best match basis to
potential sponsors. We are looking for volunteers implementing that to
mentors.d.n, Serafeim agreed to coordinate efforts taken here [4], or
talk to the Debexpo team directly [5].
Some efforts regarding sponsor metrics are currently staging on the
Debexpor platform and supposed to be deployed soon. See below for more
information.
It was suggested to improve the mentors.debian.net platform. For
example it should provide more technical information about a package.
It shall be noted here, that mentors was relaunched meanwhile, provi-
ding some of the requested features now. Most notably some QA checks,
including a Lintian run can now be seen when visiting a package page
on Mentors.
Also it was discussued how to avoid follow-up RFS mails for successive
uploads to the debian-mentors mailing list. Those are typically a sign
of a non-functional mentoring process, as it implies that either the
maintainer did not know about the suggested tight relationship between
sponsor and maintainer, or the sponsor did not reply in time. In the
first case the maintainer should learn about the whole concept of
mentoring. Here, the Debian Women project was mentioned who apparently
provide every new contributor a fixed mentor, e.g. similar to the
application managers for NM. In the later case no obvious answer was
found. Maybe a sponsor should not consider sponsoring a package, if he's
conceivable short of time or unwilling to sponsor successive uploads.
This is, because it leaves a contributor without possibility to maintain
his own packages, without sponsor who would advocate him at some point
to come over this problem and the software archive with
old/outdated/buggy software.
Finally it can be observed many developers don't take part of the
mentoring programme at all. This is something which can maybe be
improved, once it is disclosed what discourages them from
sponsoring. Several people confirmed they would start to sponsor
packages again, once the metrics idea is implemented, as they are not
willing to sponsor everything.
Sponsor guidelines and tracking
-------------------------------
Up to now, sponsor metrics do not exist yet. For now we rely on static
lists, giving people hints whom they shall ask for sponsoring if the
general RFS procedure on debian-mentors did not yield any success (or,
also along the usual RFS procedure).
I (Arno) am currently staging a patch to Debexpo introducing limited
support for sponsor metrics. It does not (and will not) feature the
whole idea, but will allow developers, who are sponsoring packages to
publish their personal sponsor guidelines in a more or less structured
way. This will allow sponsored maintainers to learn about potentially
interested developers more reasily, as the information is being coll-
ected on a central, common place. Please stay tuned, I will announce
this feature on behalf of the Debexpo team when it is deployed. Mean-
while you are invited to test it and give feedback on it. Please
contact Arno [6] if you want to have an exclusive look.
Please note, no further matching is effectuated, in particular we are
not trying to guess the right sponsor for a package. A sponsored main-
tainer is on its own to find the best sponsor for his package. Nonethe-
less it is hopefully still an improvement and can be used as starting
point for further work.
[0] http://penta.debconf.org/dc11_schedule/events/781.en.html
[1] Who said this? It would be nice to have some hard numbers.
[2] [🔎] 20110905151209.05edc47147b9d5355c42c81b@gmail.com">http://lists.debian.org/[🔎] 20110905151209.05edc47147b9d5355c42c81b@gmail.com
[3] http://wiki.debian.org/DebianMentorsNet#Metrics
[4] Please contact Serafeim Zanikolas <sez {a} debian.org>
[5] http://expo.debian.net/contact
[6] Arno Töll <debian {a} toell.net>
P.S. Mail followup set to -mentors
Attachment:
pgpZTJGt6H8u2.pgp
Description: PGP signature