[CMake] The CMake bug tracker and "the backlog" of unresolved issues

[Michael Hertling]

On 02/03/2011 11:34 PM, David Cole wrote:
> Hello CMakers,
> 
> The CMake issue tracker is located at:
> http://public.kitware.com/Bug
> 
> All of the issues except for the most recent 15 or so have been assigned and
> looked at by at least one CMake developer at one point in each issue's
> history. However, not all issues that are assigned to developers are being
> actively worked on. Personally, I have just over 100 issues assigned to me,
> and I know it would take me on the order of months to work through all of
> them, even if I were able to work on them full time.
> 
> I would like very much for us to introduce the notion of a "backlog" in the
> CMake bug tracker, where we can send bugs that are not being actively worked
> on, and we can review the backlog periodically for issues that should be
> brought forward into active development again.
> 
> Since we do not have a status of "backlog" -- but we don't really use the
> status values of "acknowledged" or "confirmed" very much, I am thinking we
> could define "backlog" as:
>  status=acknowledged
>    AND
>  assigned to="" (empty string, none)
> 
> As an exemplar, I just sent this one to the backlog by  setting its status
> and de-assigning it:
>  http://public.kitware.com/Bug/view.php?id=7867
> 
> Does this seem like a reasonable technique? Any comments or questions before
> we start sending more things to the backlog?
> 
> When we send around the request (coming up soon, after the final 2.8.4
> release is ready) to vote for your favorite issues... you'd still be able to
> vote for things in the backlog. And if we can find somebody willing to do
> the work, we'll assign it to them and set status=assigned again...
> 
> 
> Let me know what you think -- thanks for reading,

Spontaneously, I like this idea of dividing the issues into the ones in
progress and the ones in backlog. If someone is interested in an issue,
it's quite helpful to see whether it is currently worked on to either

- annoy the assigned developer when it will be finished, how it will
  look like, if additional features could be incorporated etc. ;-)

or

- ask for support on the mailing list in order to (re)activate it, or
- start working on it without the risk that the effort will become
  obsolete by a CMake developer's parallel work in the meantime.

However, IMO, the introduction of a backlog should be accompanied by a
mechanism - possibly a quite informal one - how to bring an issue into
the active development state. Periodical reviews, e.g. several times a
year corresponding to CMake's new release cycle, are certainly a good
foundation. Additionally, substantial contributions to an issue could
be a suitable indicator for this purpose, too, as they usually denote
a serious interest. So, if there're qualified proposals, constructive
criticisms, patches with tests and the like since the latest review,
this should be regularly used as an opportunity to (re)consider the
particular issue for active development.

In summary, I think that a backlog could help in multiple aspects: The
CMake developers can focus on explicitly fewer issues at the same time,
the users see if a solution for a specific issue is about to arrive in
the near future, and people willing to contribute can pick up an issue
and be sure not to get in the official development's way, so as for me,
feel encouraged.

Regards,

Michael