Re: Work-needing packages report for Dec 9, 2011
Russ Allbery <rra@debian.org> writes:
> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> But there is no way to find bugs taged help given a skillset. So unless
>> you specifically think "Lets fix something in grub today" and go looking
>> for grub bugs tagged help you never find them.
>
>> Say today you want to write some manpages. How do you find a RFH bug
>> about adding or fixing manpages?
>
> That sounds great, and like something there's no way anyone's going to
> have time to do. If we had time to classify any significant number of
> bugs that way, we would have been able to resolve them, particularly the
> easy ones. :)
>
> It takes a lot of effort to maintain that level of metadata. We struggle
> with keeping up with the basic "fixed" or "not fixed" bug metadata.
I envision this not so much for actual bugs but as a way for projects to
attract new members. For things that would be nice to have but don't
make the package unsuitable for release if they aren't done. Like
getting rid of legacy functions. Or other small issues that aren't
pressing but will be done by the team eventually if time frees up.
If a package / team gets to the point where they are only keeping up (or
falling behind) with the basic "fixed" or "not fixed" bug metadata then
one could say it is already too late. But lets say they do keep up with
it, barely. Then how are they going to improve? A "RFH: please take over
developing dselect" in wnpp is not going to help as history shows. The
task is just to big for anyone new to take over. And anyone already
involved in dpkg doesn't need the wnpp bug to see dselect needs help.
Give them some bait and get them hooked before springing monumental
tasks on them. Think of it as a kind of advertising.
MfG
Goswin
Reply to: