Lucas Nussbaum wrote:|
On 24/09/13 at 08:37 +0200, Thijs Kinkhorst wrote: > On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote: > > Did you tag them 'gift'? > > https://wiki.debian.org/qa.debian.org/GiftTag > > This may just be me, as it's very personal, and no offense intended at > you, but I really detest the name 'gift' of that tag and that prevents me > from using it. > > Tagging something 'gift' gives me a really condescending association, > where the Big Maintainer has been so kind to hand out a 'gift' of doing > work to the little newbie who should be grateful to receive it. Because > these are the connotations of the word gift to me: that people should feel > happy to receive it, while actually we should be happy if people do work > for the project. Yeah, the 'gift' name was intended the other way around: make a gift to Debian.
With such a definition, it seems every ticket should be tagged "gift".
> I realize this is absolutely not your intention in naming this tag and > also that it's highly subjective matter. I'm raising it only because it > prevents me from using it. If it's just me, than that's that. We could try to tune documentation into either clarifying the 'gift' name, or diminishing its importance (by hiding the name where it's not strictly needed).
Whether or not the "gift" name can make sense in some way, I agree the name should be avoided. But I'd suggest to consider solutions other than renaming. The gift tag appears to convey 2 or 3 pieces of information:
The second objective might be achieved better with a field
listing volunteers who are interested in mentoring whoever wants
to work on a fix. A "Resource persons" field with email addresses,
A rather simple way to specify requirements could be to quantify
the time needed for solving and to separately say how skilled an
interested contributor would need to be. #234567 needs 1 hour from
a contributor with medium skills, say.
In addition to the intrinsic difficulty of specifying
requirements, we must consider that the exact skills needed to
solve an issue are sometimes not well known in advance, and that
time spent specifying required skills is costly.
With all these difficulties, I think it would be wise to try
finding inspiration in how other ITS-s specify requirements (those
I know don't).
I wish a solution could also get rid of the help tag, although
we'd first need to agree on what that one means. If it means
maintainers don't have enough time, shouldn't maintainers rather
file an RFH (or find some other way to attribute that information
directly to the package)? If it means a change would take too much
time for them or require too much skills, then the fields
discussed above appear to be less relative solutions. If it means
a change is important, an importance field as discussed in #704874
would be more meaningful.
-- Filipus Klutiero http://www.philippecloutier.com