[Development] New JIRA type 'Feature'? (was RE: FW: Proposal for RFC like feature process)

[Alan Alpert]

On Tue, Aug 20, 2013 at 4:59 AM, Koehne Kai <Kai.Koehne at digia.com> wrote:
>
>> -----Original Message-----
>> From: Alan Alpert [mailto:416365416c at gmail.com]
>> Sent: Tuesday, August 20, 2013 12:31 AM
>> To: Koehne Kai
>> Cc: Blasche Alexander; Bubke Marco; development at qt-project.org
>> Subject: Re: New JIRA type 'Feature'? (was RE: [Development] FW: Proposal
>> for RFC like feature process)
>>
>> [...]
>> Alex's argument is entirely correct here (rant esp.). So I'm only in favor of a
>> new feature type if we can agree on the meaning and then have a realistic
>> expectation that we'll apply it consistently.
>>
>> Specific questions I have about the feature type are
>>
>> A) Do we have a clear distinction between Feature and Suggestion (also
>> Feature and Task)?
>
> A suggestion is something that a normal contributor will file with some (more or less worked out) idea. Features will be created by approvers, most likely maintainers. A Suggestion might result in a Feature once an approver picks up the idea, and takes up the responsibility to push it further.
>
> There is a bigger overlap with tasks though. I understand that also mere end users can right now create Tasks, though we should probably change that. The differentiation should IMO be that a Task is more a personal work list. It scope & format is pretty much free, while a Feature is something that other's will be interested in, should adhere to stricter standards & should be announced / discussed on the mailing list.
>
> To make an example, https://bugreports.qt-project.org/browse/QTBUG-18579 and https://bugreports.qt-project.org/browse/QTBUG-29806 are Tasks - they might be important (P1), but they won't probably require a discussion on a mailing list, show up in the Changes file etc. https://bugreports.qt-project.org/browse/QTBUG-14861 is a Feature.
>
> I imagine a Feature to also meet some structure where the Rationale & Motivation is made explicit, potential alternatives are discussed etc.  Just out of the top of my mind you typically want to describe (inspired a bit by http://www.python.org/dev/peps/pep-0001/):
>
> Motivation -  Why is the Feature needed?
> Rationale - API/design decisions made. Alternate designs that were considered, related work ...
> Status - links to discussion on the mailing list, codereview ...

This structure sounds like what you want more than the separate
Feature type. If we just introduced the Feature type yesterday, I'd
have filed a bunch of features with a one-line description (link to
the Qt CS wiki page which had the discussion on it). Something tells
me that wouldn't have accomplished our goals.

What I like most about PEP-0001 is that it provides a concrete example
of the structure required. If Feature is going to be introduced with a
defined template/structure, can we have an example of what that
template/structure would look like?

Without that additional structure I think we'd be better off
coordinating more on how to deal with tasks/suggestions in a common
way, as most features are already listed there, somewhere, and there
are better options for searchability (like tags, or tasks with a
future "fix version" date).

>> B) Can contributors create Tasks?
>
> I've been told they can.
>
>> If not, would using Task again help?
>> Since it's already there we can start using it while having the discussion of
>> what it means, call it an advanced feasibility use-case trial.
>
> Sure, using Tasks more consistently would be an improvement, too. I just think personally that a dedicated type might help to separate the wheat from the chaff.
>
>> C) Isn't a "roadmap" in an open governance project now defined by what
>> tasks people are working on?
>
> + What (relevant) people _intend_ to work on, or think that must be done for a release even if nobody has been taking up the task right now :)
>
>> So wouldn't "in progress" state on high priority
>> suggestions/tasks/bugs be more appropriate as the "roadmap"?
>
> I'm personally using 'in progress' mostly as my personal list of things I'm working on right now, and it seems a lot of people do this too.

Right, and my point was to try and get a roadmap "for free" out of
what most people are doing already. With shorter release cycles any
major feature is going to have to be "working on right now" for much
of the release cycle  (until it's in by feature freeze ;) ).

>> Why are contributors who are working on such items any different from
>> approvers?
>
> I agree that's a weak spot. Maybe everyone should be able to file Features ... as long as we can ensure that half-finished , incomplete Feature issues just pile up because nobody processes them. But I'm afraid the noise (people creating feature types that should rather be suggestions, or bug reports) is not worth it ... after all you can always send the maintainer a suggestion that is already so good he can easily promote it into a Feature :)

If we have someone processing features, perhaps this would work -
features can easily pile up even if only approvers can make them.

I would prefer to include contributors in the process, because that's
more open. It would be hard to fill with noise if there was a way to
tie it into actual work, as opposed to drive-by contributors trying to
file "super suggestions".

>
>> I would also not expect stakeholder discussions to be easier or more fruitful
>> if they could happen in JIRA instead.
>
> I don't think that most discussions have to happen in JIRA. But the core points of the discussion, conclusion etc should be recorded in JIRA, because digging through lengthy mail threads, looking for a final decision that might never have been made explicit just sucks.
>
>> Which some possibly should already
>> have done, so my ability to consistently communicate through JIRA may not
>> be high enough to handle a new issue type ;) .
>
> Coming back to my original mail,  I wanted to see what QML language changes are planned for Qt 5.2.  I spent half an hour browsing through the mailing list, the JIRA QtQml component, and the Qt Contributor Summit wiki, and still think I might have missed something :) I'd like to have an easy way to get to such a list, not only for QtQml, but also for other modules of interest. I'd like us to use JIRA more consistently to plan features & document design decisions. I don't mind the exact way we get this going, as long as we get there :)

I agree that we need better communication and knowledge sharing, but a
summary of discussions per feature sounds more like a wiki page.
Should I make a copy of
http://qt-project.org/wiki/Qt_Quick_Architecture for QML, or has that
page not been helpful either?

--
Alan Alpert