Improved issue/task management

[Thomas De Schampheleire]

Hi Dominik, all,

On Sun, Oct 23, 2016 at 1:38 PM, Dominik Ruf <dominikruf at gmail.com> wrote:
> Hi all,
>
> I strongly believe we need to improve the issue and task management in our
> project.
> Currently we use a mix of bitbucket wiki pages, bitbucket/kallithea pull
> request/changeset comments and bitbucket issue tracker.

I agree that the current situation is not optimal. While it works in
this 'unorganized' way, it could perhaps be made better. Some of this
has also been discussed on the developer gathering we held in the
beginning of this year (present were Mads, Søren, Andrew, Jan Heylen,
Mathias De Maré and myself).

Some points I think about:

- for code contribution, the goal should be to use Kallithea itself.
People like to call it 'eat your own dog food'. So while currently
some people use Bitbucket pull requests or to a lesser extent send
patches to the mailing list, I have been using this method and so far
it worked fine. An open point here was how users would get access:
auto-registration with automatic acceptance, manual acceptance, or
admin-only sign-up ? I think this is something we should unblock and
continue with. As a result, Bitbucket PRs would no longer be used.

- issues: regardless of where they are stored, we currently have too
many open issues where no-one really looks at. Some of them are actual
issues, some are really suggestions for improvement. Since there are
only a few active contributors, the risk is that this list just keeps
growing without fixing any of them.
At some point I scanned over them, closed some that were no longer
relevant or got no response after querying, and marked some of the
open ones with tags, like 'documentation'. But it does not help in the
big picture if we don't actively work at them, or be more strict in
which type of issues we accept in the tracker: only bugs, or also
'suggestions'?
Regarding suggestions: how to decide whether it is a 'good'
suggestion? Sometimes a user 'suggests' a change but the core
developers don't think it fits in Kallithea as we see it. We need to
make sure that we have some guidelines on how we want Kallithea to be,
so we can refer to these guidelines in a more 'objective' way, and as
such avoid giving the impression that we don't welcome any suggestion.
In Buildroot, a project I have been active in before, one of the goals
is simplicity. Any suggestion or patch is checked against that goal.
If the added complexity is too large, we request a rework or plainly
reject the idea. I would say it works well, because the goals are
stated.

- Mads and I had some kind of disagreement on what to do with an issue
tracker: I was in favor of striving towards 0 issues, Mads said this
was unrealistic and maybe not even worth striving for (he may be right
on the first point :-) )

- Since Mads also preferred not using the issue tracker for
suggestions (and I kind of followed him there) I started using the
wiki a bit more for some specific stuff, like open tasks related to
pytest migration, turbogears migration, ...
Also, I pushed to getting more of a roadmap, rather than just
'wandering about'. In particular, I have some time to spare (albeit
little) that I can and want to dedicate to the project, but preferably
in a way that helps the project forward in a clear direction. Pytest,
Turbogears2, bootstrap were such items on the roadmap. I think it
really helped to put focus.

>
> I see multiple problems with this.
> 1. it makes it really hard to get an overview of the open tasks
> 2. it is impossible to search for particular tasks
> 3. tasks in the wiki can't be discussed
> 4. tasks in the wiki or the comments have no status
> 5. bitbucket issue tracker doesn't allow to split issues into (sub-)tasks
>
> I'm open to what software to use, but I strongly believe we need to get
> organized in this area.
>
> This is what I think the software should support.
> 1. Creating filters to list certain kinds of issues
> 2. Breakdown issues into (sub-)tasks
> 3. Allow to distinguish between reported bugs and features/'user stories'
>

I don't know if it is needed to have such an advanced task management
system for a project as small as Kallithea. I don't feel the need to
split out issues into subtasks; it may be useful for large teams where
different developers are working on such subtasks to cover one issue,
but since at the moment typically only 1-3 people are working on a
given issue, I think we can do with regular communication or comments
on the issue.
Being able to search issues based on keywords, and categorizing them,
is of course basic stuff that is always useful.

> My favorite issue tracker would be Jira, but since it is not open source, I
> guess there are little changes that we'll use it. (even though the bitbucket
> issue tracker is proprietary software as well :-/)

I don't like bitbucket at all, to be honest. For one because it does
not properly support mobile devices (I can't comment on commits from
my phone).

>
> A quick web search lead me to taiga.io. I don't know if anybody already
> knows it, but it seems it supports my requirements above and it is open
> source. It also has a simple wiki which would allow as to completely get rid
> of bitbucket. So we would be 100% open source.

I don't have experience with it but I'm open to it.

Regarding another point raised in the thread: I think that if we
switch to something new, we should switch completely. Working with
Bitbucket as well as something new, only means less organization than
more. So IMO, we should migrate existing issues, the existing wiki
info to the new thing. Repo hosting and PRs should move to our own
Kallithea.

Best regards,
Thomas