Sébastien Villemot writes:
There are some tasks which we promised to third parties within a given deadline; for these tasks the deadline monitoring is easy.
For the other tasks, even though I often have a rough idea of the work time needed to fix the issue, I cannot transform this into a deadline, because I do not know the schedule of each developer, and I am certainly not going to manage your time. I guess the more practical way forward is to ask the responsible person to set a realistic deadline herself, and then I would nag her if she does not deliver on that promise.
I don't think that we have yet, collectively or individually, a good sense of what we can achieve between two releases.
I agree that, at the beginning of a release cycle like today, it's hard to foresee what will be in the next release. By the end of the release cycle, things get clearer and it becomes necessary to focus on those issues that are blocking the release. At that point the "milestone" field of GitHub issues becomes especially useful, and I will take care of maintaining it properly (as I did for 4.4).
I still think that making explicit the amount of time planned for a given task should be indicated in the task description, most often by the person assigned to the task.
I have the feeling that we all commit to too many things for a given deadline and keeping track of time budget would help us to be more realistic.