[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ITS gift tag and specifying requirements in tickets (Re: Paths into Debian)

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:
  1. The change required is not too difficult
  2. Someone can coach whoever wants to do the change and has volunteered
  3. Perhaps, the change is "interesting" (not trivial)

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, maybe.
Points 1 and 3 could be achieved with a field indicating the difficulty of solving the ticket. Specifying a difficulty for tickets was discussed in #704874 as data instrumental to ticket prioritization. It should be noted that in #704874, "difficulty" is essentially synonym to the time needed to implement a fix. Another definition of difficulty would be how much skills one needs to tackle a solution. Clearly, there is correlation between these 2 definitions. But they aren't the same. Some changes may require following a simple method, but they can be costly if a lot of code needs to be examined. The "small" and "bitesized" suggestions from others make me think about the first definition (cost), not about the kind of difficulty which the "gift" tag seems to be interested in.

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.
Obviously, such a system would be imperfect. Someone with high skills may be able to solve in, say, just 40 minutes. Or, someone with low skills could have to start by spending an hour learning, but still manage to solve after.
Moreover, quantifying someone's Debian development skills in a simple scale going from lowest to highest is quite simplistic. Just see SourceForge's developer profiles to see how granular skills can be made.

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
Reply to: