On Tue, Aug 20, 2013 at 4:59 AM, Koehne Kai <[email protected]> wrote: > >> -----Original Message----- >> From: Alan Alpert [mailto:[email protected]] >> Sent: Tuesday, August 20, 2013 12:31 AM >> To: Koehne Kai >> Cc: Blasche Alexander; Bubke Marco; [email protected] >> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
