Hi, hmmm, I would just put the ticket into “unassigned" state. But this would mean that from time to time we need to check all tickets in that state - as nobody will work on these or see these.
If we do not want to use the ‘unassigned’ state - using a tag is probably a good option. thanks Christian On 3. Apr 2018, at 16:50, Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Sorry, I mistakenly re-used previous subject… please reply to this message for comments on this topic. From: iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Heldt-Sheller, Nathan Sent: Tuesday, April 3, 2018 7:49 AM To: Christian Gran <g...@lynxtechnology.com<mailto:g...@lynxtechnology.com>>; jaehyun3....@samsung.com<mailto:jaehyun3....@samsung.com> Cc: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: Re: [dev] New filed request for distinguish IoTivity and IoTivity-Lite(IoTivity-constrai Christian (and others who may have suggestions), On the ATG call today a question came up about how to flag JIRA tickets as “needing developer resource”. The example in this case is the Core Privacy CR which has a JIRA ticket but no implementation owner. We felt it would be a useful thing if we could run a query at the TSC level that would bring up all features needing implementation owners. My first though was a simple tag “NEEDS_DEVELOPER_RESOURCE” or similar, but first, do you know if there’s an existing JIRA BKM for this kind of thing? Tags are great, but they have a way of not being used consistently, especially at a high level that spans multiple components. Thanks, Nathan
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev