Re: Report from the debconf11 sponsoring/mentors BoF.
David, thanks for the report.
Another issue that was mentioned during the Q&A is that debian-mentors is a
misnomer and should ideally be called smth like debian-packaging.
debian-mentors should become a discussion list for people that care about
mentoring in Debian.
Nitpicking aside, I care about mentoring but I don't have time for RFS calls
(other then the people I already sponsor) so it'd be wasteful to subscribe to
-mentors and I would rather have this discussion in -project instead.
I suspect I'm not the only one like that.
On Sun, Sep 11, 2011 at 08:44:23AM -0300, David Bremner wrote [edited]:
> 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  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.
Arno, Janos (Cc'ed) expressed interest during DebConf in helping out as well,
but I haven't had the time to ping him about it.
I understand that there's two sides in this effort: debexpo plugins that
produce additional info about certain package features, and a repository of
sponsors' interests/preferences/requirements. Do I understand correctly that
you implement both things within debexpo? Are DDs expected to enter their
preferences via the debexpo web ui?
My idea instead was to maintain DDs' preferences via an ikiwiki instance
(using something structured like yaml), and make the wiki data accessible to
debexpo via a REST interface. At the end of the day, it's up to whoever will
do the work, but it's wise to remember that geeks prefer their favourite text
editor than a web browser.
Anyhow, thanks for stepping up, and whatever your approach, please share any
code you have with Janos and see whether/how you could work together.
Every great idea is worthless without someone to do the work. --Neil Williams