Should I copy or move my work items?
I'm sure there is no correct answer here, but I wanted to see what ideas you all have.
I have two project areas on the same server: 1) Private project area where we do all our work and only a few people are allowed to follow our efforts 2) Public project area where anyone in our community can submit defects or enhancements My team exclusively works in the Private area for all planning and execution, but I triage incoming requests from the Public project area. So, we want the items tracked in our Private project area and included in the bigger planning picture. But I also want the Publicly requested item to reflect good feedback loop. What would be a good way to handle these public requests as they come in? - Move them to Private project area and depend on email notifications for submitter to stay updated - Copy them to Private project area and resolve the Public work item - Copy them to Private project area but leave the Public copy open until the Private copy is completed. |
2 answers
I would suggest you leave the work item in the public project area and either create a linked task that you use for tracking and planning in the private area or create a copy in the private area. The trick with that model is keeping the status in sync (I guess the main thing you are concerned with is open vs closed).
Option 1 would be just having the team ensure that the item is resolved in both places. But that is manual and potentially error prone. One thing you could consider is resolving the original item as 'tracked elsewhere' (this is a resolution that exists for work items in the Foundation project area and could be added to the public project area) with a link to the copy or task in the private project. You could add a comment to the public item that the item is resolved once the linked item is resolved (they should be able to see that on the links tab). If you move it, the submitter can no longer really follow it and you are likely to get duplicates as others who may encounter the same issue won't see it or find it with 'find potential duplicates'. Comments @jstuckey thanks! Good points about not just moving it. I'll look into creating a special state of "tracked elsewhere", then closing it when it the private one is resolved. |
Ideally, for true feedback/community involvement, any discussion around the issue would take place on the public version of the work item. I think it would make sense for the public one to be the actual work item that gets assigned to a developer. Since the projects are on the same server, it shouldn't be difficult for team members to manage work loads across both project areas.
Then, when a developer has made the appropriate changes and is ready to deliver, s/he can copy the public work item to the private project, associate the change, deliver and resolve both items. Comments The problem I see with that is creating iteration plans that account for these items that are in a different project area, to reflect a person's total work. Maybe in this case, a copy is made for planning but collaboration happens on the public one. What about using a single project area and controlling visibility at a more granular level? You could have a work item category for community feedback and make it the only visible one to non-member. You could also lock down source control visibility to non-members, so essentially, all community users would see is a single work item category. @agarcher I had considered that too, but the complexity for marking "everything" but the one thing private seemed overkill and error prone. Is granular control handled by team areas? @packham Yes, it's by team area at both the SCM level and the work item category level. Perhaps we should file a feature request for an opt-in approach to visibility rather than an opt-out approach. Basically, a feature that would allow us to mark everything in the project hidden by default and then literally open up just the one work item category. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.