|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
William Crighton - 14/May/04 04:36 PM
Is some of this functionality available via 'project categories'?
In the developer workload report, I would like to see "the number of hours already worked on an issue". Right now that report has "projects". I would like to see this broken down into issues and how much time has been spent working on this issue. This should also be a column that is available to added in the "issue navigator column" screen as "total work logged". This would allow me to output an excel file with this information in it.
Also, I want the numbers of hours worked on "Project ABC" between "this date" and "this date" which can be filtered by developer. Right now there is only total hours worked by project. The description is rather confusing, using 'components' in the non-JIRA sense, but I think the idea is to be able to group projects in some sort of hierarchy, and modify reporting to potentially take this hierarchy into account.
I don't think the description is confusing - the component reuse is JIRA
components. for example if I create a "Database" component in one project, I want to make that same "Database" component available to many other projects. A screen where you could simply bring Components from other projects into a Project would be a good start. Being able to report from a component perspective rather than a Project perspective is critical. This idea stems from the fact that many of us work on a Project basis, but we're actually working using the same set of product components or services across each of these projects. For those whose projects are cleanly segmented this issue doesn't arise. cheers Nick Jones Terminology is a bit confusing as JIRA uses 'components' to represent sub-systems or components within a project and some of us are more generically referring to a component as a dependent project of a project if you will. But yes, what ever the terminology my objective would be to group projects in a hierarchy and have reporting take the hierarchy into account. My project has many JAR libraries and because each of those libraries can be shared within the organization across many projects I treat each library as a trackable project in it's own right. Each JAR library project (internal/external) has it's own version and issues and is dependent on zero or more other projects. More concretely at a point-in-time, MyAmazingProject - version 1.0 Such that I could report on any of the projects and see open issues as now but I could also look at MyAmazingProject and see all open issues for the versions of it's dependent projects along with the associated bug fixes. This would be useful. In our case, however, we have a number of common library components that are shared between numerous, shipped products. To customers and even QA in some cases, it isn't clear whether the issue being reported is occuring in the application or in one of the underlying libraries.
We'd like a cleaner way of reporting a single issue against multiple JIRA projects and their respective versions. This would be similiar to the cloning tool, but would allow one to specify a list of projects and versions. The issues would automatically be linked together, but could be tracked separately as far as status goes. I think originally this issue was created to track 2 possible improvements. Lets leave this one for 'Shareable subprojects' and use JRA-8663 for shareable components.
It seems to me that the distinction people are trying to capture here is the difference between "products" and "projects," where one is user-/support-visible, and needs to be able to have issues logged against it, and the other is developer-/manager-visible and is the level at which internal tracking and fixing occurs (and so needs to be able to have issues logged, which "belong" to the individual project but are linked to the issue at the product level).
I'd say that this model is the norm for most companies that release software products; our company very much needs this functionality as well. It sems like JRA-5884, JRA-2698 and many others are really asking for this same feature (which means that the # of votes for this feature are much higher than the count here would suggest. If there's a way to do this in JIRA already, I'd love a pointer to info about it. I don't think "categories" fits. Note: it seems like it would be possible to do this with a combination of Maven and JIRA where the JIRA "product" is really a virtual project, and a Maven project w/ dependancies on "real" JIRA projects. However, this means that users of JIRA who aren't maven users lose out, and given that the set of users who work in this way probably exceeds the set of users who use maven to manage their projects, it would be nice if JIRA supported this directly. Thanks for stating this so clearly Dave. As can be seen in the original External Reference it is this tracking of issues related to reuseable modules/products/components across projects that is important to me. Whether or not that shared module/product/component is tracked in a JIRA project is a related but separate issue. If this issue JRA-1072 is for shareable subprojects then this is less important to me, as is a level of detail lower than the logical starting point for tracking. Once you're tracking shared components then its a logical step to have enhanced functionality around tracking them as a separate project. Meanwhile, simply being able to associate the same component with multiple projects would be a great improvement. I've added my vote to JRA-8663 and removed it from here to signal my intent.
I feel that there is a deeper need for components not only to be shared between projects, but also versioned individually.
This would avoid long lists of projects where an individual component is modified independently from the containing project. As components often have a life of their own the list of top-level projects can quickly become ridiculous, especially where one is integrating with a large number of external systems. In that case, one could have a top level project: Integration Project A ------- Integration with system B, v 0.90 (i.e. this is the version this project is actually using) Thanks. I need more deep levels of components, and I think that te idea of subprojects could resolve this problem.
Thanks. Yes! I completely agree with Dave. Our company is consistently banging it's head against this issue. It really is JIRA's Achilles Heal.
If we had shareable subprojects, we might be able to do something like this....first, all my components, packages, apps, versionable binaries (whatever you want to call them) would be represented by it's own JIRA project, complete with it's on version history. I'll just call these Package Projects. Then I would create JIRA projects for OUR development projects which are arbitrarily named. I'll call these Dev Projects. Each Dev Project would reference specific versions of specific Package Projects. When looking at the Dev Project I would see stats and issues coming up from Package Projects so I would know the true state of the development projects. If bugs came in from customers against a particular package, the bug would be reported against that package, but it would show up in whatever Dev Projects that referenced that Package Project. Bugs coming in from Software Test working on a given Dev Projects would be reported against that Dev Project, but developers could move those issues down into the appropriate Package Projects once they understood where the issue really is. If Dev Project A had a dependency on Package B v1.1 and another Dev Project released with a new version of Package B, say v2.0, then Dev Project A could change it's dependencies to rely on this newly released Package. In this scenario what you'd really find is that the Dev Projects would contain most non-functional or project related management tasks that didn't map to a package, all the other issues reported against the Dev Project would have been marshaled to the appropriate package, BUT you could still view all package issues via the Dev Project so your stats represent the project as a whole. These are the kinds of things we're wrestling with to the point that some groups within our company are hesitant to adopt JIRA. JIRA really needs a robust solution in this area!! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Shareable subprojects
