Stream: fmg
Topic: taking stock of our lifecycle
Grahame Grieve (Dec 06 2016 at 23:52):
presently, we have a problem in gForge: we have lots of tasks marked as 'deferred' because they were put off from being in the current release
Grahame Grieve (Dec 06 2016 at 23:53):
but that's an ambiguous idea. which ones didn't go in the release this week, and which ones don't go in the final STU3? We haven't been differentiating, and that's a problem. There's plenty of quality related tasks that are just being auto-deferred at the moment
Lloyd McKenzie (Dec 07 2016 at 03:27):
Well, the idea is that WGs are free to ignore everything that came in after mid-October until such time as R3 is published. They do however have the right to go and "undefer" things they want to tackle in R3
Grahame Grieve (Dec 07 2016 at 05:13):
but do they have any status in gForge to help manage that?
Lloyd McKenzie (Dec 07 2016 at 07:43):
If they want to take something on, they can move it from "deferred" to "triaged" to put it on their "need to deal with this" list.
Paul Knapp (Dec 07 2016 at 12:19):
So why did the status just get changed to 'deferred' when we aren't publishing anything right now?
Lloyd McKenzie (Dec 07 2016 at 14:30):
@Paul Knapp We are publishing. There were so many existing tracker items that WGs couldn't get finished by the initial deadline and we had to give an extra 2.5 months to allow them to clear the backlog. Continuing to dump new ones on them didn't seem wise. WGs that are on top of things are free to move content out of "deferred" if they wish.
John Moehrke (Dec 07 2016 at 15:13):
Were workgroups expected to mark ALL unresolved STU3 items as deferred at this time? I was expecting with the deadline for STU3 ballot rec moved out that they didn't need to do such thing.
John Moehrke (Dec 07 2016 at 15:15):
My groups are carrying on mostly ignorant of the January ballot. (Ignorant convenient because none of their resources are included in any IG being balloted) I don't recall any instructions on use of deferred this time.
Lloyd McKenzie (Dec 07 2016 at 15:50):
When newly submitted items are triaged, they're automaticallly being deferred. Existing items aren't being changed. We're still expected to reconcile all items that came in during ballot (and past ballots) or that were submitted prior to mid-October. Though work groups are free to vote to punt something to the next release if they wish.
John Moehrke (Dec 07 2016 at 16:11):
Ah, yes. I knew that... although I had forgotten... now I need to think about looking at that backlog.
Paul Knapp (Dec 07 2016 at 16:14):
We had several of our uncompleted items changed from triaged to deferred which is why I made the comment above - we also aren't publishing anything now. The time when unresolved items would be set to deferred on masse I would have expected to be Feb 5.
Lloyd McKenzie (Dec 07 2016 at 16:38):
@Paul Knapp Things shouldn't be changed from triaged to deferred on you. Check the history to see who made the change. We won't bulk-defer things. Work groups need to vote on their resolutions to open items, even if those votes are to defer. We will however start leaning on WGs to do that for anything that's left outstanding after the WGM. I.e. "Either defer them or get them resolved pronto" :)
Paul Knapp (Dec 07 2016 at 16:46):
@Lloyd McKenzie I think it was Melva doing QA. I agree that things shouldn't have changed. It isn't a problem as we have a spreadsheet where we are keeping track.
Lloyd McKenzie (Dec 07 2016 at 18:28):
Were the items "triaged" or "submitted"? Anything that comes in as "submitted" will get changed to "deferred". But if something was specifically changed from "triaged" to "deferred" without a vote by the WG, that's a problem. If you give me a tracker id, I can dig to see what happened.
Paul Knapp (Dec 07 2016 at 19:15):
They were two items recently added by me marked as "submitted" - why would those be changed? I think it makes more sense to let the committees manage their items and force the remainers to deferred on Feb 5 or whatever the final date is for reconciliation.
Grahame Grieve (Dec 07 2016 at 19:21):
standard policy is that all gForge tasks created after mid-Oct are auto-deferred. Makes sure the commenter knows where they stand. I have undeferred a few, and explained to a few people why. ]
Paul Knapp (Dec 07 2016 at 19:32):
They can sit as deferred and when the committee votes this Friday I'll set them accordingly.
Josh Mandel (Dec 07 2016 at 19:35):
I'm hoping folks will read these, though: like GF#12382 seems to have been deferred but it's actually an infrastructure problem
Josh Mandel (Dec 07 2016 at 19:36):
(Because this kind of invalid extension should be detected in the build, and prohibited)
Grahame Grieve (Dec 07 2016 at 19:40):
it is assigned to the wrong committee, though how we'd sort that I don't know
Grahame Grieve (Dec 07 2016 at 19:40):
should be FHIR-I. There's a real risk that stuff like that will be missed because I'm not checking deferred tasks for domain committees
Josh Mandel (Dec 07 2016 at 19:41):
Should I just go and re-assign that?
Josh Mandel (Dec 07 2016 at 19:42):
Just did, to FHIR-I, as "Triaged", and "Fit for telecon".
Grahame Grieve (Dec 07 2016 at 19:44):
thx. though I don't think we need to telecon that one. it's just an outright publishing error
Josh Mandel (Dec 07 2016 at 19:46):
Yes, OK. I can set to a different status if you prefer!
Grahame Grieve (Dec 07 2016 at 19:49):
Resolved change required is best
Lloyd McKenzie (Dec 07 2016 at 21:09):
Everything that comes in as submitted goes through a triage process that ensures the item is complete, assigned to the (hopefully) the correct work group, is appropriately categorized by resource, page, etc. That's the process where we auto-defer. The point is that work groups shouldn't have to look at anything that came in after mid-october until after the release is published
Last updated: Apr 12 2022 at 19:14 UTC
