Set tasks due to github milestone due date?

[vantreeseba]

Should we set the tasks due date on import to the milestones date?

I'm willing to work on this, but just thought I would ask what people thought before I dug in too far.

[ryneeverett]

Makes sense to me. There may be some ambiguity added by github features down the road -- this new "Projects" thing I haven't looked at may have it's own concept of due dates, github may add a duedate feature to issues, etc -- but those can always be resolved by giving precedence to the most immediate due date.

[irl]

Do we talk to anyone at @github? Maybe they would have input or could at least point us at a roadmap of what they think their projects thing is. It would be in their interest if people building tools to work with GitHub weren't fighting against their new features.

[gdetrez]

It could be annoying if someone use personal due dates to organize their tasks and bugwarrior systematically resets them to milestone dates the same way it resets task descriptions or projects.

IMO this feature should be optional but I think there is no need to introduce yet an other option, instead pull the milestone date in a UDA (e.g. githubmilestonedate) and make sure that you can set the due date with a template:

due_template = {{ githubmilestonedate }}

Bonus: add timedelta to the rendering context and you can do cool and useful stuff. Like if your goal is to process all issues in the week after they are created:

due_template = {{ githubcreatedon + timedelta(weeks=1) }}

or if you want to finish coding a month before the milestone is released to let people test stuff:

due_template = {{ githubmilestonedate - timedelta(months=1) }}

[vantreeseba]

I think @gdetrez is right about going the UDA path. Especially if more due dates are added to other parts of the issues/projects, this will keep it from becoming tied to any single point of data.

I think that, for now, we could set the default due_template to the milestone date.

This, to me looks like a good path foreward, so I'm going to proceed on it.

[ryneeverett]

The conclusion is that this use case would be better served by a milestone duedate UDA. Adding UDA's isn't a lot of work and we're fairly lenient about merging those pull requests so I'm going to close this since nobody has wanted it that seriously for the last 5+ years.