What do your Due dates mean? I bet at times yours have very different actual meanings. That’s ok, but only if you are sticking to a workable policy, such as the example below.
In private (in My Tasks with private tasks or in my own private projects) I often set Due dates for use with Rules (formerly auto task promotion) so I make sure I get reminders and nothing falls through the cracks. The Due date represents the day I’d like to be reminded, perhaps to follow up on the task or to begin working on it (which is not the same as when it’s Due necessarily, should it take a week to complete, for example).
In public (in shared projects), I never value Due date in that manner because it would be confusing to others. That’s because Due date–from a team perspective–represents a meaningful deadline (requested or imposed) when something should be done, not a somewhat arbitrary reflection of a person’s start date for their workflow. Clearly, it would be confusing to see some tasks with Due dates representing bona fide “to be done on” dates and others representing “so and so wants to remember to do something on” dates.
In public, don’t set a Due date if the task doesn’t have one yet. Or if you feel you must, adopt a way to clearly indicate the anomaly, e. g., use a tag or custom field like “Estimated,” for example.
For your own reminders to public tasks, consider “Create follow-up task” Shift+Tab+F to create a private follow-up task and using an appropriate My Tasks section for when to do/follow-up work (instead of trying to use the Due date for that purpose), or perhaps use a Start date (if on a paid plan), though that doesn’t help when using the Rule trigger for when a date is approaching and you can now use rules for Start date is approaching.
Facilitate your own workflow with Due dates, but not at the expense of others when in collaboration.
Larry
?