Posted by leafish_paul on January 10, 2006 at 8:32pm
Jump to:
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
A nice feature when marking issues as duplicates would be to allow the user to specify the issue its being marked a duplicate of, but instead of doing this just in the follow up content, we could submit a nid for the issue, allowing the original issue to be automatically 'bumped' somehow to reflect the duplicate, which is essentially another occurence or instance of the issue.
Did that make any sense?
Comments
#1
both http://drupal.org/node/57782 and http://drupal.org/node/64408 are duplicate with this same basic idea. for certain values of the status (the existing "duplicate", my proposed "blocked" -- which now that i've read it, is basically sara's proposed "parent/child") and in certain other cases (sara's proposed "related to", not sure if that's useful as a status setting in the same way duplicate and blocked are), it'd be great to be able to input the node id of another issue. ideally, changes to the status of the related issue could automatically alter the status of the other (e.g. when the parent is closed/fixed, the child can move from blocked to active, or when a duplicate is set, the other issue gets a new comment added automatically ("url/title marked as a duplicate of this issue"...). not sure how to best handle this. maybe we should move discussion over to http://groups.drupal.org/relationships-site-structuring and/or http://groups.drupal.org/issue-tracking-and-software-releases.
#2
created http://groups.drupal.org/node/555, which i cross-posted to both of the groups i mentioned above. let's move discussion there for brainstorming and design ideas. we can come back to this issue once we have a plan and can start dealing with project-specific patches, etc. if you don't have a groups.drupal account, you can just use your existing drupal.org username with "@drupal.org" appended to it (e.g. "dww@drupal.org").
#3
Nice idea. Giving it a real version. Could be done with node reference I guess.
#4
#5
@catch: yes. However, it's still postponed. I don't want to discuss it in here, I want to discuss it over at http://groups.drupal.org/node/555 first to brainstorm how we want to go about it, then come back here once we have a reasonable plan we can agree on and implement.
#6
subscribing. looks like i'll be working on something similar for work.
#7
There was a quick BOF at the end of Paris Drupalcon where that issue was also brought up as being a key issue in usability. Furthermore, I don't feel the groups.d.o discussion is particularly complicated or leading away from a consensus, so I think this should be considered active again.
I have also posted extra specs on the groups.d.o page.
#8
so it's been almost a month since I posted those specs on the group and almost two years since dww postponed the issue. when do we know we agree?
i would very much like to see this in, i guess the only implementation-level question remaining here is whether this is implemented standalone or we reuse existing code.
#9
Ok, so what do we need to do to start the ball rolling, development wise? Be great to start working on this. I too feel core is losing contributors (myself included) because the issue queue is too hard to unravel. I wouldn't set the priority as "minor" either, because I don't think it is minor!
#10
Honestly, I think #569552: Provide a mechanism for issue meta discussions is more important in the short term for improving the workflow on d.o. That would be greatly helped + facilitated by wrangling a decision on #651484: Enable CCK and node_reference...
#11
Sigh. If only we had a mechanism for issue meta discussions, this would be so much easier. ;-)
Heading over there to read up now.
@dww - you should hold up an umbrella when you walk around or something. You're a very useful tour guide! ;-)
#12
subscribing...
#13
http://drupal.org/node/651484#comment-3398242
#14
... as suggested by Derek (dww), I am posting here the screenshot of how bugzilla.mozilla.org handles issues relationships:
#15
I just had some ideas about relationships between issues during ironing (call me a Drupal nerd) and saw that there isn't any active discussion on g.d.o. so I'm taking the liberty to air them here.
Basically what I'd like to see is a way to define (m-n) relations between issues like klonos shows in #14. If there's a relationship between issues it's possible to order them in importance and show an issue tree. A project owner could define a mile stone issue (a new release for example) and define which issues are blocking this mile stone. This would give everyone the opportunity to give priority to issues.
An extension to this would be to be able to define an estimate time amount for each issue. If this would be defined a basic scheduling algorithm could be used to define the critical path or to give an estimate time for a issue chain to be resolved.
If only we would've had this tools for the upcoming D7 release.. But of course the "Project" and "Project issue tracking" projects are used in many smaller issue tracking projects as well, and the above addition could come in very handy.