Le mardi 28 janvier 2014 à 11:23 +0100, Michel Juillard a écrit :
Sébastien Villemot writes:
Le lundi 27 janvier 2014 à 20:15 +0100, Michel Juillard a écrit :
However, I don't think that fully answers my concerns. The list of GitHub issues that are either bug reports or clearly defined enhancements is quite big.
My proposal is that we formalize your role, Sébastien, as the manager of the Dynare project in charge of the work flow. Big priorities should still be discussed collectively.
Your first task would be to go through the list of issues and
- assign bug corrections with deadlines or decide that we won't fix them
- sort enhancements between the ones that we will do in the near future
and that are assigned with deadline and the ones that it would be nice to do sometimes in the future.
This can be partly delegated to the people already assigned to issues.
I am happy to take a more proactive role in the management of the project. So far I've been reluctant to decide certain things myself, but I will now be a tad more aggressive. Of course I will make mistakes, but since there is nothing that cannot be reverted, this should not be a big problem.
It would be good if you could attach to each task an estimation of the time needed so that you can later both nag people who don't deliver on time and stop people to accept more tasks than can be realistically achieved
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).