I would basically agree with Stephane. There has been a tendency recently to move all development issues to GitHub issues. This should be restricted to bugs and well planed enhancements. Preparatory discussions should be carried on the development list and, for broader issues where we will need memory, through Wiki pages.

I also think that we need more management of the Dynare project with a reasonable work plan and deadlines that we can monitor.

Best

Michel

Stéphane Adjemian writes:

Hi,

Another obvious solution is:

Think before adding new issues.

We should use more often the dev list (not private emails). A lot of discussions should be done in dev list rather than in issues. For instance, I think that the recent issue #588 opened by Houtan has nothing to do in Github's issues and should rather be discussed on the mailing list.

I am not convinced by the efficiency of synchronous discussions (IRC meetings).

Best, Stéphane.

On 27/01/2014 17:19, Sébastien Villemot wrote:

...

Hi,

I am getting concerned about the number of outstanding GitHub issues against Dynare. As of now, there are 133 outstanding issues, and this number is following an upward trend.

I think that having the number of issues growing too big has a negative impact, because it makes it more difficult to figure out what are the really relevant issues and act on them. It also diminishes the perceived usefulness of filing an issue, since there is a significant probability that there will be no follow up.

I am therefore wondering what would be the possible solutions to bring down the number of opened issues. I can see at least:

1. Have developers deal more diligently with issues that are assigned to

them (or otherwise mark them as unassigned)

2. Have developers pick up more unassigned issues

3. Hold meetings (as we did last year on IRC) to discuss issues for

which a collective decision is needed

4. Acknowledge that we do not have enough resources to deal with some

issues, and close them (this probably also needs collective decisions)

5. Organize bug squashing parties

Obviously items 1 and 2 are not something that we can decide as a group, but I included them for completeness and as a reminder for everyone.

What is your opinion on items 3, 4 and 5? Do you have other ideas?

Best,

---

Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev

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 1) assign bug corrections with deadlines or decide that we won't fix them 2) 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.

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

I don't think that we have yet, collectively or individually, a good sense of what we can achieve between two releases.

This is close to what you proposed below, but we should review and dispose of all open issues, not only the ones needed for the next release. The disposition should be indicated when we close an issue on GitHub. As issues on GitHub are public, we need to indicate how they will be handled with a link to the document that replaces the GitHub issue.

...

I also think that we need more management of the Dynare project with a reasonable work plan and deadlines that we can monitor.

Indeed. So far I was more or less implicitly assuming that GitHub issues were enough for planning, and the realization that it is not true led to this discussion.

Concretely, what do you have in mind? For example, are you thinking about a wiki page listing all major objectives for the next release, with deadlines, people in charge, and links to more details (GitHub issues or other wiki pages)? I can probably make a first draft of such a plan.

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.