Russ Allbery <r...@debian.org> writes:
> Tollef Fog Heen <tfh...@err.no> writes:
>
>> I've always (well, since they were introduced) thought about the RFH
>> bugs as either «we're now starting a team effort to fix up $package,
>> please come and help» and more commonly: «I'm stuck maintaining this
>> package with a mostly nonexistent/dysfunctional team, if somebody else
>> who uses this would like to chip in, it'd be great». So, a way to
>> highlight sore spots and get attention.
>
>> A «please help me» bug that's been open for an average of almost three
>> years isn't getting attention, nor highlighting anything.
>
> My first inclination would be to publish a clear definition like that
> somewhere and then auto-close RFH bugs after three months. After three
> months, the team has either formed or not, and the dysfunctional team has
> either gotten fixed or one should consider escalating to RFA. The
> maintainer can always reopen if they think they'll have more luck asking
> for help the second time around.
Maybe we also need a different "need help" system where it is easier to
find something fun and usefull to do on a rainy day.
Something where RFHs for small jobs can be added with some tags for
required skill sets and so on and a frontend to filter out stuff you
could do. Mikro RFHs. Most important would be the frontend. If that then
looks through wnpp bugs or a postgress database or whatever doesn't
matter. It should also be possible to select "package that I have
installed" in some way.
As an example a mikro RFH for a project could be:
----------------------------------------------------------------------
Mikro-RFH: fuse: Replace use of index() with strchr().
Added: 2011-12-10
The fuse library still uses the legacy index() and rindex() functions in
parts of its code. Your mission, if you accept it, will be to replace
those with the equivalent strchr() and strrchr() calls.
----------------------------------------------------------------------
I believe such mikro RFHs could be far more usefull for getting things
done incrementally and to attrackt new people that would otherwise be
daunted to join a large project. People that would never respond to
"please help maintain grub" are more likely to help out in a small
way. And maybe they then stick with it.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4651e2f.fsf@frosties.localnet
