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

[Koehne Kai]

> -----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 ...

> 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. 

> 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 :)

> 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 :)

Regards

Kai