|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
antesa - 21/Feb/03 09:31 AM
we have large hierarchical list of components. High level components are assigned to groups (several groups in one project); issue goes automatically to group leader when it is created. So, there are no groups under project, as far as I understand, and no possibility to associate a set of components to one group that has a leading developer responsible for these components quality.
I agree.
Our software product [accounting] is structured as follows: modules (customers/stock/suppliers etc) = Components I think that lack of support for hierarchical organization of projects is the inconvenience number one in JIRA.
If you take a look at average installation of JIRA - like this at codehaus: you will notice that there are too many things visible at the top level. So JIRA should be able to support a hierarchy like Maven ---- Maven Core
at the Moment it just supports: Maven Core When number of projects is growing it is becoming not maintainable and things are very difficult to find. Michal,
What you are asking for it sub-projects, not sub-components. You can already group projects into project categories - which I think that codehaus are using? Subcomponents would be useful on jira.atlassian.com. We could have "Custom Fields", and then "Custom Field requests" as components.
I use sub-components for my 'management' project. In this project we plan/evaluate/prioritize change requests for all enterprise projects. this creates a horrible mess if we have one flat component namespace, so I utilized the new cascading select for this, where the parent == platform and the child == component.
I have experienced a different problem since utilizing this method: Scott,
>Michal, >What you are asking for it sub-projects, not sub-components. Yes - you are right. IMO the entire concept of "component" is not really needed in jira. >You can already group projects into project categories - which I think that codehaus are using? Yes codehaus is grouping feature but the number of groups is getting out of control as only flat hierachy is allowed. Note also that there are diffrent grouping staregies are often used. For example you can assign projects to active/inactive groups. Once you do this afaik you cannot have subgroups of projects active/clientX Michal I completly agree with all your comments about subcomponents. I just would like to insist on the possibility to affect specific groups to those components/subcomponents.
I would like to pile on regarding the desire to have "sub-projects". We have a large degree of IP reuse among projects, and ideally, all end-products would be described within Jira as a collection of other projects. When an issue is logged against "Fender, version 1.10", then all other projects containing "Fender, version 1.10" should get a clone of the issue - or someting similar.
Scott wrote:
"You can already group projects into project categories ..." (Not in the Pro version) Even with project categories you can only have a 1..1 association between any set of projects when you need 1...N. Jira should have 1...N project associations as well as 1...N component levels. We would love this feature. In fact we are having to break the metaphorical connection between how our real development teams work and how they are represented in Jira. Our product is very large and has around 40 major components (or what we'd like to call components) and each component has a potential average of 5 sub-components). Since we can't really handle this in Jira, we are using a cascading select custom field. But considering the well known problems with not being able to sort custom fields, and not having the same 'visibility' as components, we are really not happy with our current solution.
As an aside, having some meta data about components and versions and potentially subcomponents would also be a great help for us. It makes training new users in the system much easier (they have descriptions for the various components, and secondly it allows us to set the meaning and missions of the various versions). It sounds like components and subcomponents naturally fit many business' and teams work environments. From out point of view this is a must have feature. Component hierarchies within a project will really help. In JIRA there already is good starting - we can point to actual cause of issue by defining a component. With hierarchies we will more precise information.
By the way, this issue should be reviewed in conjunction with JRA-1991. can someone please specify when is this feature will be available in JIRA?
Cheers Hi Shobhit,
Unfortunately, there is no scheduled date for implementation of this feature as yet. The following document details how new features and improvements are scheduled by Atlassian: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements Regards, As a work around to this issue, we use a cascading custom field, tho would love for there to be subcomponents for the many benefits components privide.
As a (minor) workaround i have created a listener that updates the component field from the first value of the cascading cutom field every time the issues is modified in any way. The listener takes two parameters, the project key, and the name of the custom field. This allows for multiple instances of the listener to be running across different projects using different custom fields. I am happy to contribute this listener if anyone is interested Hi Sam,
Can you send me details how I can setup this listener? Thanks, Irina This is one of the only areas of lost functionality that we'll experience moving from our current system to JIRA. It will definitely cause us some pain. I hope it will be considered at some point soon.
I have one project that needs this feature. As said before, this is a loss from the system we are migrating off of.
This is something that we need as well - project categories just don't cut it. Ideally a true "sub-component" is desired, but is there any way that a multiple select custom field could be based off of a current field. So this sub-component would just be a "Cascading Select" custom field, where the parent fields would be locked to the components. Not sure if this would be easier or not to implement as a work-around. (this kind of functionality might be useful for other things as well)
Sub-Components is a key feature for us which is very well supported by our current issue tracking system (but it has other limitations
 . When can we expect to get this feature? This may very well be a buy/no buy reason for us. I am not sure we need a subcomponent. If we can share component across the Project, It while do the jog and I thin it more simple to implement. Ex. I have two executable exec1 and exec2 (projects) that use the same CommonLib (component). I want to be able to see on the release note of exec1 the change that has been made in exec2.
Thanks Subcomponents are essential.
You need subcomponents for each system/app. Pretty much a system breakdown The definition of a project is that it is timebound i.e. has a start and an So in Jira two views would be nice. One from the NOTE! A jira record in a project does not have a mandatory link to a system Regards email: sundstromlars@yahoo.com.au Subcomponents would be great!
Another thing id like to see is relations between components, compare .net dll's and their dependencies among them selves.. So when i touch component A i would like to know that component x,y and z are dependant of this and needs to be changed/recompiled/tested. We then close in to continous integration.. but /Johan sub projects really does sound like what we would be looking for. We have a huge list of projects each managed by an individual group. Each group of course is working on more than one thing. sub components would get us the functionality we need but sub projects is probably a more correct term. Either way a more granular breakdown of projects / components would be greatly appreciated.
Just to add a more comprehensive "me too" to this than just a simple vote allows... Not being able to have sub-components is really beginning to get in the way of our ability to correctly represent our projects in Jira.
I'd just like to add another "me too, please" comment to this request.
We have several core projects, made up of several high-level components with myriad detailed components. Reporting on what is costing us time/effort is a nightmare without enumerating the subcomponents, but having hundreds of components for a project doesn't make any sense. Additionally, grouping projects doesn't do anything but put several projects into the same cosmetic space when navigating. Maintaining several projects is nightmarish when the prospect of synchronizing version numbers, SVN histories, release schedules, etc. between them. Please, please help those of us who are using JIRA alongside a long-term team-wide multi-project plan! Sorry that should be JRA-1538 and JRA-846 require support for subcomponents and cross project issue tracking. The issue of coordinating and tracking issues across projects (as noted above, a project may only be a current phase of work, while components live on) is an issue we see Jira as handling very poorly.
Is there any hope of addressing this issue? I'd like to echo on Matt's comment.
We are currently looking for a tool that integrates powerful issue tracking with project management functionality. Jira seems to come with the necessary features. However, we are a software company that highly leverages the component based development approach for our applications. The lack of possibility to share one reusable component among multiple projects, and to be able to run project management features such as time tracking and release note generation on the whole project tree, limits the planning capability to a degree where the whole functionality becomes almost useless to us. And with it, IMHO Jira looses one of it's main competitive advantages. My questions are the same as Jason's: This definitely gets my vote.
We use JIRA for keeping track of issues in embedded systems - both the software and electronics. One such product contains 3 pieces of software (application, bootloader, self-test), and 2 PCBs (motherboard, communications board), each of which has its own version label and components. Together they make up a single assembly, which has a corresponding assembly number. At present, each of these parts is a project in itself, which is not ideal - not least because you don't need many products being tracked on JIRA for the project list to become very, very long. Having sub-projects would tie together the various projects making up a product very neatly. In addition, we're currently experimenting with using JIRA to track errata in our documentation (user manuals, etc). Again, each document has its own version numbers, and possibly components (chapter headings or similar) as well. We produce a significant number of documents, which again could make the project list very long. The Categories function could help a bit with both these - but we're reluctant to spend $4000 to upgrade to the Enterprise edition for such a small change in functionality. why not generalizing this by providing a way to add keywords to a jira (like we can in confluence) ?
this could fit many needs, couldn't it ? Generalizations often also mean inferior interfaces.
For example, we're currently "solving" the problem by expressing our having hierarchical names, let's say: Input But since JIRA doesn't know the logic behind this, searching for issues in component "Input" doesn't find issues in component "Input: Keyboard", even though the user might expect this. You can add keywords all you like to a JIRA issue (use a custom field), but this doesn't really help in any way, because you don't get any logical relationship between the keywords. Note that project categories doesn't really work for solving this problem. We tried it when first importing our data, and there are quite a few problems. For example, when you search for items, they get grouped by project - which is logical if they really are projects, but otherwise just confusing.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Open
Major
Support for subcomponents
